Backups and Restoration

A backup is useful only when it contains the required data, survives the original failure, and can be restored within the project's recovery goal.

Define What Must Be Rebuilt

Inventory each layer:

Layer	Backup or reconstruction source
Domain registration	Account ownership and renewal records
DNS	Zone export and nameserver inventory
Website source	Version control repository
Built website	Reproducible build or artifact archive
Web server	Reviewed configuration backup
Certificates	Normally reissued; protect private keys if backed up
Application data	Database-aware backup
Uploaded files	File backup with ownership and metadata
Secrets	Secret manager and recovery process
Operations	Runbooks, contacts, and monitoring configuration

Do not assume a server snapshot replaces application-consistent database backups or independent source control.

Recovery Objectives

Recovery Point Objective

The maximum acceptable amount of recent data loss. A daily backup implies that almost a day of changes could be lost.

Recovery Time Objective

The target time to restore service. A backup on slow offline media may satisfy retention but not a short recovery time.

Write both objectives before selecting backup frequency and storage.

The 3-2-1 Pattern

A common baseline is:

• Three copies of important data
• On two different storage types or systems
• With one copy separated from the primary environment

The exact architecture depends on risk, but a copy in another directory on the same server is not protection from server loss.

Back Up a Static Site

Source control is the primary history for text files, but create a deployable archive when the build depends on tools or generated assets:

tar -C /var/www -czf example-site-$(date -u +%Y%m%dT%H%M%SZ).tar.gz example.dpdns.org

Check the archive without extracting over production:

tar -tzf example-site-20260716T120000Z.tar.gz | sed -n '1,80p'

Use the actual generated filename. Store the archive on a separate protected system.

Back Up Configuration

Important configuration may include:

/etc/nginx/
/etc/systemd/system/
/etc/ssh/
firewall rules
scheduled tasks
application environment definitions

Configuration backups can contain internal paths, hostnames, usernames, and secrets. Encrypt and restrict them appropriately.

Database-Aware Backups

Copying live database files can produce an inconsistent backup. Use the database's supported dump, snapshot, or replication procedure and record the server version required for restoration.

Test:

• Schema restoration
• Data row counts or checksums where appropriate
• Required extensions
• User and permission reconstruction
• Application migration compatibility

Encrypt and Protect Backups

Backups often contain more sensitive data than production views because they combine historical records.

• Encrypt in transit and at rest.
• Limit operators and service accounts.
• Separate backup deletion permission from normal application permission when possible.
• Monitor backup failures and unexpected deletion.
• Define retention and secure disposal.

Do not place the only decryption key inside the system being backed up.

Restoration Drill

At a scheduled interval:

1. Select a known backup.
2. Create an isolated restore environment.
3. Verify archive integrity.
4. Restore configuration and data without overwriting production.
5. Start the service on a private address or alternate port.
6. Run HTTP and application checks.
7. Measure restoration time.
8. Record missing steps and update the runbook.
9. Destroy the isolated copy securely when finished.

A successful drill is stronger evidence than a green backup job.

DNS and Domain Recovery Packet

Keep a protected, current record of:

• Registration account owner
• Recovery contact
• Domain expiration date
• Authoritative nameservers
• Exported DNS zone
• Web server addresses
• Certificate hostnames
• Mail providers and DKIM selectors
• Incident contacts

Do not include raw passwords or API tokens in a printable recovery packet.

Backup Failure Exercise

Assume the production server is permanently lost. Write the exact sequence required to:

1. Obtain a replacement server.
2. Restore website files.
3. Restore web server configuration.
4. Reissue HTTPS certificates.
5. Change DNS safely.
6. Validate the website.
7. Communicate the incident.

Any step that depends on memory or the missing server is a documentation gap.

Continue to Monitoring and Incident Response.