Back up BryanNet and validate backups

Prerequisites and authority

Assign an operator and an authorized technical owner. Data-replacing recovery and updates require a maintenance window, preserved recovery point and known target.

Configure and validate encrypted backups

Use Settings → Backup & Recovery with appropriate authority. Recommend daily backups and configurable retention. Off-site copies are strongly recommended because a local disk/host failure can remove both the application and its local backups.

Generate/import the supported recovery key and store a separate protected copy.
Select local and/or off-site destinations.
Confirm the local path is on intended durable storage.
For S3-compatible storage, configure the supported endpoint, region, bucket, prefix and credentials.
Set retention for each destination and choose a schedule/timezone.
Run a manual backup and inspect each destination's availability.
Verify checksum, decryption and archive integrity through the supported action.
Schedule and record a restore drill using Restore BryanNet safely.

The inspected service retains backup counts separately for local/off-site storage; count-based retention is not necessarily a number of days. Multiple manual backups can shorten a calendar recovery window. Plan retention around discovery time, storage and recovery requirements.

Backups use encrypted .brnbackup files. The revised archive contract includes database, environment, Compose, SQL bootstrap files, release metadata, branding assets and supported report files. Older archives may not contain the newly added assets or bootstrap files. It is not a complete disk image: host services, VPN/tunnel configuration and Docker images require separate recovery arrangements.

This is not an atomic snapshot of the whole deployment. Application tables are captured in one database transaction; configuration and backup inventory are captured separately, and asset files are copied separately. For a recovery point requiring cross-file/configuration consistency, pause application writes and configuration changes during capture in an agreed maintenance window. Do not run database schema changes during a backup.

Local verification of the revised implementation includes archive/crypto checks and a disposable MySQL encrypted backup/SQL restore drill. This does not establish end-to-end Windows GUI restore or clean-host recovery acceptance; record those platform-specific drills before release sign-off.

A WARNING can mean off-site transfer failed while the local copy exists, or pruning failed. Do not report both destinations protected without checking. A file being nonzero is not enough evidence of recovery.

Key rotation does not make older backups decryptable with the new key. Preserve the key associated with each retained generation. Never keep the only recovery key inside the encrypted backup it must unlock.

Windows: manual backup and independent copy

Complete the dashboard configuration above, export the recovery key and keep it in protected storage outside the BryanNet host.
Open BryanNet Control and select Backup. Wait for completion and record the displayed encrypted archive path.
In Settings > Backup & Recovery, inspect the operation and use Verify on the resulting recovery point. Check local and off-site status independently.
Copy/download the .brnbackup file to independent storage. Keep the key separately; losing the host must not also lose your only key or backup.
Record backup timestamp, application version and database revision. Retain the matching trusted release and image archive for disaster recovery.

Control backup requires a working compatible deployment and configured backup settings. A warning is not proof that every enabled destination succeeded.

Linux: manual backup and independent copy

Complete the same dashboard configuration and key export.
From a terminal on the installed host, run:

   bryannet backup
   bryannet list-backups

Record the resulting archive path and verify the actual local file:

   bryannet verify-backup /path/to/backup.brnbackup

Enter the key at the private prompt. Verification requires host Python 3 and cryptography. On Ubuntu/Debian install missing prerequisites with sudo apt-get install python3 python3-cryptography.
Inspect each destination in the dashboard, keep an independent encrypted copy, and record its timestamp/version/schema and matching release package.

Old Linux plaintext .tar.gz backups are retained but not accepted by the revised verification/restore command. Preserve them and request assisted migration.

Prove that the backup is usable

A successful archive check is not a complete disaster-recovery drill. On an isolated Windows or Linux replacement, follow the restore guide using only the independent backup, separately stored key and matching release. Validate accounts, payments, assets, licensing and router connectivity, then make and verify a new backup. Record actual data loss/recovery time. The detailed command reference is the internal engineering runbook docs/backup-restore.md.