Backups that survive a disaster
A copy becomes a recovery strategy only when it sits outside the same failure domain, preserves versions and passes verified restoration exercises.
A local copy solves very little
Duplicating files into another folder can help with accidental deletion, but it does not protect against disk failure, a compromised machine or an automated mistake that reaches both locations. The first step is to identify which events the copy needs to survive.
A failure domain is everything that can be lost in the same incident. Two copies on one volume share the disk. Two machines in one environment may share power, network, administrative credentials or a faulty automation routine. Without mapping these dependencies, counting copies suggests more protection than there is.
The recovery set is larger than the public folder
Restoring an application requires more than code and images. Persistent data, uploaded files, configuration, keys, scheduled tasks and operating instructions may all be needed to rebuild the service. The inventory needs to say what is essential, where it lives and how often it changes.
Consistency matters too. Copying files while related data is changing can produce a set that never existed as a valid state. The selected mechanism should create a recoverable point or record the sequence needed to reconstruct one.
Retention handles problems discovered late
One copy that is always overwritten only protects against issues noticed immediately. Silent corruption, improper deletion or a malicious change may be discovered days later. By then, the newest copy can contain the same defect.
A retention policy keeps recovery points at different levels of granularity: more recent versions and fewer older versions according to risk and volume. The period should not come from a generic number. It needs to reflect how long a problem may remain hidden and which obligations require data to be preserved or deleted.
Isolation includes identity and permission
Sending a copy somewhere else is not enough when the same production credential can delete it. Separate accounts, limited permissions and recorded operations reduce the chance that one incident reaches both the origin and its backup.
Immutability or deletion locks can improve resistance when retention and disposal are planned too. Encryption protects data at rest and in transit, but its keys need to be available during recovery. A copy that cannot be decrypted at the critical moment remains unavailable.
RPO and RTO turn expectations into decisions
The recovery point objective, RPO, describes how much data can be lost between the last valid copy and the incident. The recovery time objective, RTO, describes how long the service may take to return. Together they guide frequency, automation, capacity and restoration order.
More demanding objectives cost more and require more sophisticated mechanisms. They should therefore be selected according to business impact. A daily backup does not automatically meet the needs of an operation that cannot lose a day of data.
A restoration test closes the loop
A successful job log confirms that the routine wrote something. Completeness, integrity and usefulness only show up when restoring into a separate environment, starting the required components and checking essential data and functions.
Periodic exercises reveal forgotten dependencies, expired permissions, incomplete documentation and unrealistic timelines. The results update the recovery runbook. Backup is the cycle of copying, protecting, restoring and learning; the file produced overnight is its first stage.