Comprehensive data protection for all workloads
Post Reply
DrWhy
Enthusiast
Posts: 38
Liked: 3 times
Joined: May 12, 2015 7:05 pm
Full Name: Caleb
Contact:

Problems With a Single Backup Mechanism

Post by DrWhy »

Over the years, I've ran into various bugs that crop up in backup solutions that affect the integrity of backups. The problem is, these bugs often go unnoticed and undetected. VM's can still spin up and be tested and data can be read, so the backup software shows green and says everything is fine. However, maybe that one file or the folder of files somehow got corrupted and that wasn't being read during the test restore. Maybe this problem was introduced because of a bug in the CBT mechanism, or maybe in the VSS mechanism, or maybe the REFS file system, or maybe in the backup software. Sure, we have multiple backups but if the problem occurs in the backup mechanism itself, that means all downstream backups are bad. I really appreciate the rigorous mentally and stringent Q&A standards that Veeam takes in the development process, however, Veeam is still capable of making mistakes and shouldn't be considered above reproach, nor should any software vendor, especially your backup software vendor. And yes, these scenarios are relatively rare.... or are they? I've experienced a number of issues in my time and have developed a very skeptical view of using a single backup mechanism. All that being said, should we be using multiple backup mechanisms to insure data recovery. I' really love to be told I'm wrong or mistaken or that I'm missing something. Please, say I'm wrong! What are your thoughts?
TGacs
Enthusiast
Posts: 37
Liked: 8 times
Joined: Sep 27, 2016 6:59 pm
Contact:

Re: Problems With a Single Backup Mechanism

Post by TGacs » 1 person likes this post

To me, it depends on your particular scenario, with the associated risk tolerances, resources and budgets of your organization.

For a start, deepening the testing of restores would seem to pay the best dividends. I would think that leveraging SureBackup would be a way to verify backup integrity. To your point "maybe that one file or the folder of files somehow got corrupted and that wasn't being read during the test restore", perhaps using scripted file integrity monitoring software to scan a restored VM's files and compare them against pre-backup file hashes could be a way to provide that deeper level of assurance.

Adding a second backup method might make sense in some cases, but now you will have also doubled your need to test restores - one for each vendor backup solution. There is also extra load on the systems being backed up twice, and replication and disaster recovery procedures might get rather complicated.
Post Reply

Who is online

Users browsing this forum: Amazon [Bot], Google [Bot] and 78 guests