Backup, Snapshot and Replication Playbook

Snapshot

A snapshot is a point-in-time state on a storage platform. It can make rollback very fast, but it normally depends on the source storage system and therefore should not be treated as the only copy of important data.

Backup

A backup should be independently recoverable from the production system. The important proof is a restore test, not a green "backup complete" icon.

Replication

Replication moves data or snapshots to another system/site. It improves recovery options but can also replicate corruption or unwanted changes depending on retention and implementation.

RPO and RTO

• RPO: how much recent data loss the business can tolerate.
• RTO: how long the service can remain unavailable.

These are business requirements. They should drive backup frequency, retention and recovery architecture.

Integrity checks

Synology documents a Hyper Backup "Restore Only" state when backup integrity is corrupted and recommends investigating hardware, shutdown and storage consistency. This illustrates why backup integrity must be monitored, not assumed.

Restore drill

1. Select a representative file and a representative application dataset.
2. Restore to an alternate test location.
3. Verify content opens and application consistency is acceptable.
4. Record restore time and steps.
5. Update the runbook.

Client benefit

The client knows which failures can be rolled back quickly, which require backup restore, and what happens if the primary storage system is completely lost.

Retention is part of recovery design

Keep enough restore points to survive the time between corruption starting and being discovered. A fast ransomware event and a slow unnoticed database corruption are different retention problems.

Off-site and offline considerations

At least one recovery path should survive loss of the production site or credentials where the business requirement demands it. Whether that is offline, immutable, cloud or another site depends on the platform and risk model.

Application consistency

Crash-consistent snapshots may be acceptable for some workloads but not all applications. Databases and transactional systems can require application-aware quiescing or backup agents. Follow the application vendor's supported method.

Restore documentation

Document not only where backups are stored but how to restore when the original server, NAS or credentials are unavailable. Recovery instructions should survive the failure they are meant to solve.

3-2-1 as a planning concept

A common data-protection planning idea is multiple copies on different media or systems with at least one copy separated from the primary site or failure domain. The exact implementation depends on business requirements, regulations and platform capabilities.

Immutability

Where supported, immutable or write-protected backup copies can reduce the risk that compromised administrator credentials delete every recovery point. Verify how retention locking works and who can change it.

Encryption keys

Encrypted backups are only recoverable if the required keys, passwords or certificates survive the incident. Store recovery secrets in an approved secure location separate from the backup system itself.

Bandwidth planning for replication

Initial seeding and daily change rate can exceed WAN capacity. Measure changed data volume and available replication window. Compression and deduplication may help on supported platforms, but plan from measured transfer behaviour.

Recovery order

Document which systems must return first: identity/DNS, firewall/VPN, storage, application databases, file services and user-facing applications. Recovery sequencing matters because later services may depend on earlier infrastructure.