A department can have several copies of its files and still be unable to resume work. The copies may share the same compromised account, omit a required database, or need a key that is available only through the failed system. Counting copies is a starting point, not the recovery test.
What makes a copy recoverable?
Recovery depends on more than how many copies exist.
Ask the application owner what must be recovered, how much recent work could be lost, and how long the service can be unavailable. Those answers determine the protection and operating effort required.
Include the information needed to use the copy
List the records, applications, configuration, identities, keys, licenses, and provider assistance the service depends on. Confirm which systems and cloud applications are actually covered. A backup product installed on a server does not establish that every new workload was added correctly.
Choose a schedule and history suited to the work and requirements. A daily copy may leave more loss than a department can accept; a frequent copy may still offer too little history to recover from an older unnoticed problem.
The backup and recovery guide connects these choices with evidence and ownership. Keep records preservation and legal holds in the retention process. A backup arrangement and an archive for long-term records serve related but different purposes.
Protect against the failure you are planning for
CISA's ransomware guidance recommends protected backup arrangements and recovery testing. Consider who can alter or delete copies, how administrative access is separated, and which copies remain available if production accounts are compromised.
Offline, offsite, immutable, and separately administered copies describe different protections. Verify their actual configuration and limits. A cloud location does not automatically remove provider, account, regional, or connectivity dependencies.
Protect sensitive backup information during transport and storage. Establish key custody and a tested recovery route through the encryption arrangement. A securely encrypted copy is not useful if the authorized recovery team cannot obtain the necessary key.
Assign responsibility for job failures, capacity problems, expiring credentials, and a change in the protected scope. A reassuring notification is useful only when the expected information was included and exceptions are acted on.
Restore a representative service
Use a controlled test location and an agreed scope. Check that records open correctly, permissions suit the intended users, and the application can complete representative work. Avoid reconnecting an old recovered system to production without considering identities, addresses, and security consequences.
Record the restore point, elapsed time, missing dependencies, and work still required. Have the operational owner assess whether that result meets the need. Retest appropriate parts after material changes to applications, storage, security, or providers.
Keep instructions and essential contacts reachable during an outage. The continuity guide addresses how work proceeds while technical recovery is underway, including temporary records and their later reconciliation.
End each test with assigned actions and a follow-up check. The organization should be able to explain what can be recovered, who can do it, and under which conditions. That is a firmer basis for planning than assuming that a successful backup job guarantees a complete recovery.