Restore BryanNet safely

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.

Restore safely on the same or a replacement machine

Advanced, data-replacing procedure. Confirm the intended recovery point and acceptable loss window. Preserve current readable data and configuration before replacement. Use a qualified operator and an isolated rehearsal where possible.

Establish the recovery set

Obtain the encrypted backup, its matching recovery key, the matching/compatible release payload and Docker prerequisites. Record backup time, app version and database revision. Protect any decrypted files because environment configuration contains secrets.

The revised standalone recovery utility supports verification, extraction, S3 retrieval and restore. It requires --yes for data replacement and supports a protected key file or masked prompt; prefer those over the legacy command-line key option, which can expose secrets in process listings or shell history. Windows Control also provides masked key entry and encrypted backup/restore for a compatible existing installation. Clean-host recovery uses the standalone utility, not the same-host Control dialog.

Linux Control creates encrypted backups through the installed application image and its configured inventory/retention policy. Its verification and restore commands delegate to the standalone utility, which requires host Python 3 with the cryptography package and Docker Compose. Missing recovery prerequisites must be resolved before any restore changes are made. Old Linux plaintext .tar.gz backups are retained but not extracted by the revised Control command; arrange an assisted, isolated migration rather than treating them as encrypted backups.

Same-machine recovery

Declare maintenance and stop normal application/worker writes using the approved release procedure.
Preserve current database and configuration, including evidence of the incident.
Verify/decrypt the backup and inspect its metadata.
Confirm the install root, Compose/environment, database credentials and volume identity agree.
Apply the supported restore procedure to the intended target.
Inspect health and data before reopening access.

Replacement-machine recovery

Prepare the release-supported OS, Docker and compatible images/files.
Recover the configuration and database using the backup contract.
Restore external prerequisites: DNS/ingress, VPN routes, provider connectivity and required host services.
Resolve licensing/deployment binding through the authorized transfer/recovery path.
Keep the old host isolated so two deployments do not simultaneously process payments or manage routers.
Complete the same post-restore checks before cutover.

The revised utility validates the archive and required local images before stopping writers, checks database identity/credentials before using existing volumes, and waits for database readiness. Same-host recovery captures a safety dump before importing the selected backup. It restores environment, Compose, available bootstrap/branding/report files and release metadata before restarting writers. It does not automatically roll back a failed import: keep writers stopped and use the preserved safety recovery point with qualified support.

Restored deployment configuration includes its recorded host ports and binding. Check availability on a replacement host before cutover; recovery does not automatically choose new ports or reconfigure DNS, tunnels or firewalls. Verify externally configured origins against the recovered configuration.

Practice recovery on an isolated replacement using a representative backup before relying on it for disaster recovery. A successful archive check does not by itself establish that the application, assets, licence binding and external connections have recovered.

Post-restore acceptance

Check schema/release compatibility, administrator login, license, worker activity, router synchronization, payment/subscription consistency and representative customer access. Reconcile external payments received after the recovery point without duplicating outcomes. Re-import/confirm the backup key and schedule: the inspected utility pauses scheduled backups after restore.

Account for transactions and usage after the backup time. Do not silently erase their economic consequences. Create and verify a new backup after recovery acceptance. Retain the recovery record, loss window and outstanding accounting issues.

Windows: existing-installation restore

Preserve readable data and identify the intended backup timestamp and matching release. Keep the old host isolated if a replacement is being prepared.
With the compatible installation still present, open BryanNet Control and select Restore. Choose the encrypted .brnbackup file.
Enter its key in the masked dialog and confirm the data-replacement warning.
Retain the safety-backup path. Control checks compatibility, saves a safety backup, stops writers, restores data/assets/configuration and checks API health.
If it fails, leave writers stopped and seek support. If it succeeds, complete the post-restore acceptance checks above before reopening access.

This dialog is not a bare-machine recovery wizard. If the deployment is gone or incompatible, use the standalone clean-host procedure instead.

Linux: existing-installation restore

Preserve readable data and confirm the target release and recovery point.
Confirm Docker Compose and host Python 3 with cryptography work. On Ubuntu/Debian install missing Python prerequisites with sudo apt-get install python3 python3-cryptography.
In an interactive terminal run:

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

Enter the recovery key privately when prompted; restore additionally asks you to type RESTORE. Retain the reported recovery-safety directory.
On failure, keep writers stopped and seek support. On success, complete the post-restore acceptance checks before reopening access.

Dead server: Windows replacement

Keep the old host offline. Obtain the independent encrypted backup, matching key and trusted compatible release/image archive. No independent backup or lost key means recovery is not assured.
Prepare supported Windows, Docker in Linux-container mode, the Compose plugin and Python 3. Extract the release into a working directory separate from the restore target; locate scripts/bryannet_recovery.py in its deployment payload.
In elevated PowerShell from that directory, prepare dependencies and load the image archive after checking it against trusted release integrity metadata:

   python -m venv .recovery-venv
   .\.recovery-venv\Scripts\python.exe -m pip install cryptography
   docker compose version
   docker load --input .\bryannet-images.tar
   .\.recovery-venv\Scripts\python.exe scripts/bryannet_recovery.py verify C:\Recovery\backup.brnbackup

Enter the key privately. Substitute actual archive/backup paths. Verify an isolated clean target and available saved ports; a different directory does not isolate conflicting Compose volumes. Do not delete volumes to bypass checks.
Restore to the intended installation root:

   .\.recovery-venv\Scripts\python.exe scripts/bryannet_recovery.py restore C:\Recovery\backup.brnbackup --install-root C:\BryanNet --yes

Enter the key again and complete post-restore acceptance. The utility restores data/deployment files, not Windows, Control shortcuts or tunnel configuration. Arrange host integrations through the matching release/support procedure.

Dead server: Linux replacement

Keep the old host offline. Obtain the independent backup, matching key and trusted compatible release/images. Prepare a supported Linux host with Docker Engine and Compose. On Ubuntu/Debian install Python prerequisites:

   sudo apt-get update
   sudo apt-get install python3 python3-cryptography
   sudo docker compose version

Extract the release into a separate working directory; locate its recovery script in the deployment payload and verify the image archive against trusted release metadata. From that directory, using actual paths, run:

   sudo docker load --input ./bryannet-images.tar
   python3 scripts/bryannet_recovery.py verify /path/to/backup.brnbackup

Enter the key privately. Confirm a clean isolated target, available saved ports and no conflicting deployment volumes. Restore:

   sudo python3 scripts/bryannet_recovery.py restore /path/to/backup.brnbackup --install-root /opt/bryannet --yes

Enter the key again. Complete post-restore acceptance. Host services, tunnels and the bryannet command wrapper are not installed by the utility; arrange those separately through the matching release/support procedure.

Off-site retrieval, cutover and failure handling

Download the .brnbackup object through the configured storage provider's console if the dashboard is gone. Provider credentials must be available separately from the failed database. The release-download bucket is not automatically a customer backup destination. The standalone S3 retrieval commands also require boto3. Use the recovery instructions supplied with the matching release, or request assistance if the original dashboard is unavailable.

Offline recovery requires preparing dependencies/images beforehand. The utility does not build images or recreate external DNS/firewall/VPN/ingress services. Check restored absolute storage paths and read-only bind prerequisites too.

There is no automatic rollback after a failed restore. Preserve logs, the original backup and safety files; leave writers stopped until the database is assessed. After success, verify health/accounts/data/assets/license/workers/router access, restore ingress and test payment callbacks. Reconcile transactions after the backup timestamp without duplicating payments. Re-import the recovery key, review destinations and re-enable the paused schedule, then create/verify a new backup. Retain protected safety copies until acceptance. Do not run both licensed hosts.

Complete a clean-host recovery drill for your operating system and workload before decommissioning the original installation. Retain the original backup and independent recovery material until application and data verification succeeds.