A Successful Backup Is Not the Same as a Successful Recovery
Why backup status is not enough, what restore testing reveals, and how recovery dependencies should be documented before an outage.
The archive contains a very practical failure
In the original recovery story, regular Windows Server Backup jobs to locally attached USB disks appeared healthy. During a real server move, the recovery environment could not reliably enumerate the backups. The files were present, yet the planned restore path did not behave as expected.
Green backup logs do not validate the restore environment
The key lesson is independent of the old Windows version: backup creation and disaster recovery are different workflows. Boot media, drivers, network access, storage visibility, credentials and the recovery interface can all fail even when the backup job itself is green.
Test the same path you would use during an outage
A useful recovery test should reproduce the actual dependencies: how the replacement system boots, how it reaches the backup, which credentials are required, how networking is configured and what has to be changed after restoration.
Document the awkward details
The original article is valuable because it records small operational details that only appear during a restore. Those details belong in the recovery runbook. A plan that says only “restore from backup” is not a recovery procedure.
Measure recovery, not backup activity
The practical outcome to care about is whether the service can be returned to a usable state within the time the organization can tolerate. Backup frequency is only one input into that outcome.
Questions that usually come next
Does this mean USB backups are bad?
No. The source describes a specific recovery failure and uses it to argue for testing. The broader lesson is not to assume any medium or backup method is recoverable until the intended restore path has been exercised.
How often should recovery be tested?
The archive does not prescribe one universal frequency. It argues for planned restore testing and documentation appropriate to the importance of the systems involved.
Use the evidence, then choose the tool
Scantide Guides explains the problem. Use Online for outside-in public evidence, Auditor for authorized internal visibility, Observe for browser-visible behavior and Guard for active server protection.
All Scantide GuidesScantide ProductsPractical depth: examples, failure modes and what to verify
Field experience from the archive
1998 - 2007 BackupCentralen/Guardian IT / Sungard Availability Services Disaster Recovery Specialist on Windows, NetWare, Linux and Solaris. Also management of the online-backup solution based on E-Vault (Owned by Carbonite these days). A lot of work was practical restore and disaster recovery test for clients to get systems and applications up and running and verify functionality Technical skills: Disaster Recovery management with virtually every backup-solution on the market (BackupExec, ArcServe, Legato, PureDisk, Tivoli, VytalVault etc)
Senior IT consultant with 25 plus years of experience in the business including server operations, DevOps, disaster recovery specialist, backup specialist and project management. Juha also has a keen interest in all aspects of IT security and was the initiator of Syspeace. He is also a Cloud Architect and has had a freelance contract as a teacher in Cloud Security.
A bit off topic but it has to do with BCP mentioned earlier. Be sure , please, be supersure even , you have adequate backups , containing multiple generations of data and have at least three or four of theses complete generations stored offisite in some way. Using an online backup service or just moving your tapes/disk manually out of the building. Test your DR Plan (Disaster Recovery plan (link in Swedish, sorry) at least once a year to verify that your backups contain all you need if something happens. Be sure o have an updated technical description of how to restore your entire environment.
That's six quite easy questions that sum up what that technical restore plan should contain. It should be able to be read even be outside consultants in case of your entire IT department got killed in a freak barbecue accident the night before. Keep it simple but detailed. Include all necessary background info such as server configurations, IP plans, passwords and where the data is stored. a Network map explaining dependencies might also be useful.
Install a good antivirus. This should go without saying , I like F Secure. Install a good backup solution and make sure to have at least 3 copies offsite. This too should go without saying. Big fan of VytalVault here or build your own with for instance Syncrify . Just be sure you're happy with WHERE your backups are stored and make sure to test the in terms of Disaster Recovery . I would also highly recommend using the built in VSS snapshots to be able to quickly recover files but , for the love of everything holy, do remember , VSS is NOT a substitute for backups.
Det är här jag kan erbjuda kompetens från flera sidor av saken, både från en molnleverantörs perspektiv men också som en kund som måste tänka igenom alla aspekter av en flytt till Molnet och som företagare kan jag tänka på de olika IT-strategiska konsekvenserna av det. Utan att vara partisk. JufCorp kan erbjuda Ert företag unik backupexpertis med över 10 års praktisk erfarenhet inom backup/restore och Disaster Recovery-området och återstartsplanering.
Practical review checklist
- 1998 - 2007 BackupCentralen/Guardian IT / Sungard Availability Services Disaster Recovery Specialist on Windows, NetWare, Linux and Solaris.
- A bit off topic but it has to do with BCP mentioned earlier.
- Senior IT consultant with 25 plus years of experience in the business including server operations, DevOps, disaster recovery specialist, backup specialist and project management.
- That's six quite easy questions that sum up what that technical restore plan should contain.