---
title: Kinsta Backup & Maintenance Workflow
type: article
created: '2026-02-04'
updated: '2026-02-04'
source_docs:
- raw/2026-02-04-mid-week-call-w-119821545.md
tags:
- kinsta
- wordpress
- infrastructure
- maintenance
- backup
- ssh
- workflow
layer: 2
client_source: null
industry_context: null
transferable: true
---

# Kinsta Backup & Maintenance Workflow

Best practices for safely performing maintenance on Kinsta-hosted WordPress sites. The core principle: **always confirm backups exist before touching anything.** Kinsta's automatic backup system makes this straightforward, but the steps below should be followed every time.

## Why This Matters

When working on a client site we don't host ourselves, we have no control over the server environment and limited visibility into what's been changed. A mistake without a restorable backup can be expensive and relationship-damaging. This workflow was formalized after scoping maintenance work on the [[wiki/clients/didion/_index|Didion]] site in February 2026.

---

## Pre-Work Checklist

### 1. Verify Backup Availability in Kinsta Dashboard

Before making any changes, log into the Kinsta dashboard and confirm automatic backups are enabled and recent.

**Navigation path:**
> Kinsta Dashboard → Sites → [Client Site] → Live → **Backups**

If backups are present and current, it is safe to proceed. If not, do not begin work until a manual backup is created or the client confirms their backup situation.

> **Note:** Kinsta's automatic backups are not always visible from within the WordPress admin panel itself (under Tools or elsewhere). You must check the Kinsta dashboard directly.

### 2. Confirm SSH / SFTP Access

Backend work (database cleanup, plugin fixes, SEO audits) requires more than WordPress admin access. Confirm you have one of the following:

- **SSH access** — preferred for efficient backend work (WP-CLI, direct file access)
- **SFTP access** — fallback for file transfers

**Where to find credentials:**
> Kinsta Dashboard → Sites → [Client Site] → **User Management** or **Info** tab

If SSH credentials are not already set up, you may need to create a new server user or request access from the client. Do not assume WordPress admin login is sufficient for backend operations.

### 3. Note the Hosting Environment Differences

Kinsta sites may use different plugins and configurations than WP Engine-hosted sites. Before running any automated tools or scripts, audit the active plugins:

- Caching plugins (Kinsta uses its own cache layer; third-party cache plugins may conflict)
- Security plugins
- Page builders (e.g., Divi requires extra care and significantly increases task time)

---

## Performing Maintenance

### Safe Sequence

1. **Log backup timestamp** — note the most recent automatic backup before starting
2. **Create a manual backup** if the most recent automatic backup is more than 24 hours old
3. **Work on staging first** if a staging environment exists (Kinsta provides one per site)
4. **Push to live** only after verifying changes on staging

### Common Maintenance Tasks

| Task | Access Required | Notes |
|---|---|---|
| SEO metadata fixes | WordPress admin | Can be done via plugin or bulk editor |
| Database cleanup (orphaned data, transients, autoload) | SSH / WP-CLI | Cannot be done reliably from WP admin alone |
| Broken link repair | WordPress admin | Use Ahrefs or similar to identify; fix in editor |
| Plugin updates | WordPress admin | Test on staging first |
| Image optimization | WordPress admin or SSH | Bulk tools require SSH for large sites |
| Cache clearing | Kinsta dashboard or admin bar | Kinsta cache must be purged from dashboard |

### What You Cannot Do Without Backend Access

If you only have WordPress admin login (no SSH, no hosting dashboard access), the following are not possible:

- PHP-level fixes and custom plugin deployment
- Direct database access (phpMyAdmin equivalent)
- DNS record management
- Automated monthly audit scripts

This is the same limitation encountered with [[wiki/clients/adovacare/_index|Adovacare]] after their unauthorized DNS migration — front-end login exists, but backend tooling is completely blocked.

---

## Authentication & Credential Management

Kinsta accounts typically require two-factor authentication (2FA). Ensure the following are stored in LastPass before starting a session:

- Kinsta dashboard login (email + password)
- TOTP authenticator entry for Kinsta 2FA
- WordPress admin credentials for the specific site
- SFTP/SSH credentials (if configured)

If a Kinsta account requires email verification as an additional step, coordinate with whoever owns the team email inbox before scheduling maintenance work.

---

## After Maintenance

- Verify the site loads correctly on both desktop and mobile
- Check Ahrefs (or equivalent) error count to confirm issues were resolved
- Clear Kinsta's server cache from the dashboard
- Log what was done and update the client's site documentation
- Note any issues that require SSH access that wasn't available, so they can be scoped separately

---

## Related

- [[wiki/clients/didion/_index|Didion]] — first site where this workflow was formalized; 169 Ahrefs errors identified, Divi builder in use
- [[wiki/clients/adovacare/_index|Adovacare]] — counterexample: DNS migration removed all backend access, illustrating what's lost without proper infrastructure control
- [[wiki/knowledge/website/dns-management-and-cloudflare|DNS Management & Cloudflare]] — how DNS configuration affects backend tool access
- [[wiki/knowledge/website/monthly-seo-audit-process|Monthly SEO Audit Process]] — the automated audit workflow that requires backend access to run