Should i verify backups

Many organisations invest in time, space, and cost to take and manage backups but, often neglect testing them. The reason for this is it takes time and requires extra space to restore and verify the completed backup.

Alternatively, if time and space are a constraint then you can opt to do a selective restore on certain files or tables. This, of course, is not comprehensive and would not be able to validate the accuracy of the backup. Testing a backup means you need to test the entire recovery process to minimize the operational downtime. This includes testing the backup devices on a system or over the network. Next, include the people who will be part of the recovery process, get them to pick the backup randomly and then restore some part of the data.

This simulation will allow the people in charge to run the recovery process, check the backup validity, and finally check and amend any recovery process documentation. A backup can be verified quickly using some of the files from the full backup. A quick way to check for the backup data validity is to restore selected files on an alternative location and check its contents against the original version. This would give a quick snapshot of the data validity. Of course, this is a test with selected files, therefore this does not guarantee the backup was done properly at the beginning or data validity of the entire backup.

Next is to restore the files from the backup onto a different environment. This test gives the assurance that if the system is down, the backup files can still be accessed in a different environment.

This function ensures that all the backed-up files are within a certain size range. Further to the ensuring that all the backed-up files fall within a certain size, the backup verification solution can identify files that deviate from the expected size range.

When this happens, the administrator is alerted so that further verification can be performed. While backing up files is essential, and it is also important to ensure that the files are backed up properly and are not damaged or corrupted during the transfer.

A good automated file backup verification solution can check the integrity of the files after the transmission. If any files have been affected the administrator is alerted and a second backup can be performed. File integrity should also be checked at regular intervals to ensure that the configuration backup is still usable even after an extended period of time.

An automated configuration backup verification solution can also verify keywords in the backup. The required keywords that need to be verified can be entered into the system, and the solution will ensure that the keywords have been backed up with the configuration. One of the most important functions of an automated configuration backup verification solution is to ensure that the backed-up files can be used for recovery when needed.

If the files get corrupted during the process of being backed up or before the backup, then they will not serve this purpose.

The backup verification solution is able to check if files are corrupted before or during the backup process and prevent them from being corrupted. This ensures that all the files that are backed-up will be accessible and usable as and when required.

Configuration files of security and network devices are backed up so that in case of any problem with the current system, the backup can be accessed and used. Having a backup is like having insurance for disaster recovery or any other time there is a system failure. Every organization should have a backup of their network configurations to reduce downtime and costs in a time of crisis. Our synthetic backup approach is a proven technology that we did not invent , simply refined.

We were actually doing research into how to provide functionality that our customers were asking for, namely application-item level recovery. Since we are doing image-level backups, how could we allow our customers to retrieve individual application items such as email, SQL, etc.? Some vendors recommend backing up data twice, once with an image-level product and again with a different agent based product with specific agents for each application.

This approach means 2 backup vendors not integrated , resource contention on hosts and almost double your backup space…we knew there had to be a better way. Building on our advanced file-level recovery capability we knew that if we could just start a recovered VM we could then start the application and pull out individual application items.

In the past this was done by restoring the entire VM in an isolated network, a process that can take a considerable amount of time and effort for just 1 email. What if we could just run the VM from the backup file without having to extract it? Sometimes in software development you start out to solve one problem and in the process realize that you can solve other problems, problems that no one ever thought could be solved.