Phase 5 Encrypted Google Backup Rollout

ObjectiveCopy Anchor Link

Activate the prepared encrypted Google Drive delivery without exposing credentials or changing production timers before canary and scratch-restore validation succeeds.

Prepared repository componentsCopy Anchor Link

• Shared env, lock, rclone verification, and retention helpers.
• Swarm-aware WordPress backup with per-site destination registry.
• Swarm-aware database backup with optional encrypted delivery.
• Online PostgreSQL physical backup and guarded logical/physical restore tooling.
• Root-only config preparation, systemd installers, safe diagnostics, and stubbed tests.

The repository and production rollout are complete. Bootstrap, authorization, canaries, complete workflows, logical and physical restore validation, offsite flags, retention, and all three timer states passed on 2026-08-14.

PreconditionsCopy Anchor Link

• Explicit owner approval for the exact VPS execution window.
• Google Drive API enabled and an External OAuth app published to Production.
• Both OAuth Desktop client ID/secret pairs available for direct entry—not chat or Git.
• Destination Google account available for one-time browser consent.
• Crypt password and salt stored in an offline password manager.
• Current local Tier-1 backup and service/timer state captured before changes.

Approval-gated final VPS sequenceCopy Anchor Link

The bootstrap, credentials, canaries, and targeted logical restores are complete. For the final activation window:

1. Disable only wp-gdrive-backup.timer; leave weekly local database backups active.
2. Update /etc/contabo-backups/backup.env with the reviewed non-secret operational keys, keep both offsite flags false, and reinstall/validate the canonical weekly and WordPress units.
3. Run the four-site WordPress dry-run. Scope is dbskc.com, gorsistudio.com, store.gorsistudio.com, and wcblahore.pk; Nishat variants are excluded.
4. Run a complete PostgreSQL/MySQL/MongoDB logical backup with encrypted delivery and confirm globals plus every PostgreSQL database in the verified manifest.
5. Run the first PostgreSQL physical backup with --offsite and verify its encrypted upload.
6. Download through contabo_crypt and use postgres-restore.sh physical --execute to restore into an isolated scratch volume/container with no network or published port.
7. Validate native manifest, readiness, expected database count, and query; capture evidence, then explicitly clean up the scratch resources.
8. Run the real four-site WordPress workflow.
9. Set DB_OFFSITE_ENABLED=true, POSTGRES_PHYSICAL_OFFSITE_ENABLED=true, and DB_ENGINES=postgres,mysql,mongodb.
10. Reinstall/enable the corrected WordPress unit and install/enable the new physical timer. Retain the already active corrected weekly timer.
11. Confirm all three calculated schedules, unit status/results, Drive hierarchy, sliding retention, shared-lock behavior, and backup-diagnostics.sh output.
12. Record only sanitized commands/results and evidence paths in the change record and update the DR/operator/state documentation.

Acceptance criteriaCopy Anchor Link

• contabo_crypt:wordpress/<domain> holds verified encrypted WordPress archives.
• gorsistudio_crypt:wordpress/{gorsistudio.com,store.gorsistudio.com} holds only the explicitly assigned Gorsi archives.
• contabo_crypt:databases/tier1-<timestamp> holds a verified complete database set.
• Weekly sets contain PostgreSQL globals and one collision-safe custom dump for every connectable non-template database.
• contabo_crypt:databases/postgres-physical/postgres-physical-<timestamp> holds a verified online base backup with included WAL and native SHA-256 manifest.
• Underlying Drive contents are encrypted and readable only through the crypt remote.
• Scratch restores match their manifests.
• WordPress retains four remote archives per site.
• Databases retain twelve remote sets and three local sets.
• PostgreSQL physical snapshots retain four remote sets and two local sets.
• A forced upload failure leaves local artifacts intact and the unit failed.
• Logs and evidence contain no OAuth, database, or crypt secrets.

RollbackCopy Anchor Link

• Disable the WordPress and physical timers if newly enabled; leave the validated weekly local database timer active.
• Set both offsite flags false to preserve local-only behavior.
• Do not delete verified remote data during rollback.
• Repair OAuth/connectivity and repeat canary validation before re-enabling delivery.

Completion statusCopy Anchor Link

All acceptance criteria passed on 2026-08-14. The four-site WordPress workflow, complete active-engine logical set, physical snapshot/download/isolated restore, scratch cleanup, Drive hierarchy, retention bounds, diagnostics, and all three timers were verified. MSSQL remains intentionally 0/0 and excluded. Weekly logical backups still do not meet the documented one-hour RPO.