Backup strategy

Define recoverable data and recovery objectives before scheduling jobs or deleting generations. A selected-directory archive is not a full machine image; a successful upload or gzip check is not an application restore test.

Establish the plan

• Identify required files, application databases, secrets, ownership/ACLs, recovery point and recovery time objectives, retention, encryption key custody, and an independent destination.
• Arrange database consistency and a schema-stable window. Do not copy live database data files into a generic tar archive and call it consistent.
• Specify how both file and database artifacts reach remote storage. Use scoped credentials and retention/versioning/immutability appropriate to the incident model; remote storage can still be deleted through compromised credentials.
• Treat configuration, scheduling, uploads, remote policy changes and retention deletion as distinct authorized actions. Reuse authorization already given for the applicable action; an audit alone does not authorize them.

Read references/backup-locations.md for storage decisions, failure handling, schedules and safe restoration.

Create file and database artifacts

The helpers preview by default, require explicit inputs, create private output and checksum files, serialize jobs in a backup directory, and publish only verified results. Optional GPG encryption uses an already-provisioned public key; failed encryption retains the verified compressed source as a protected pending file.

Preview file backups: