Backups support recovery after data loss or corruption. The 3-2-1 approach separates risks through multiple copies, different media and an off-site copy. Practical reliability depends on isolation, freshness and verified restoration.
Start with recovery requirements
Identify critical data and acceptable loss over time. Separately agree required service recovery time. Saving a file does not prove an application can start from it in the required environment.
For example, a database and attachments are stored separately. Restore them consistently with configuration. Encryption keys also need protection and recovery arrangements.
Separate access and storage locations
A copy on the same disk does not protect against disk failure. A writable network share may be affected alongside live data. Check actual permissions and copy independence.
Object immutability can restrict deletion during configured retention. Modes and permissions matter; this does not protect against every loss cause. Align retention with needs and requirements.
Monitor backup success
Check schedules, failures, capacity and freshness. Notify an owner who knows the next action. Missing email must not automatically mean success.
Databases need an agreed consistency-aware backup method. Copying open files without validation can produce unusable data. Choose methods for the specific system.
Restore before an incident occurs
Restore in an isolated environment. Check data, startup and required business operations. Record actual time and differences from production.
Before this ALL IT Agency local sprint, a separate file copy was verified with SHA-256. This establishes file integrity, not recovery of every database or a universal service-restoration time.
Sources and further reading
