Having a backup process is only half of the picture; when was the last time you tested recovering files from a backup? Perhaps there has been an error in the backup process which no one is aware of or your backups haven’t been working for some time. The only sure way is to periodically restore some files to make sure that the backups are working correctly.
How often should you test backups? In an ideal world, a test should be scheduled after every backup to validate that the data has been successfully secured. This is not always practical, so there is a trade-off to be made between the impact and effort of recovery and having a degree of confidence in the restore.
As a minimum, there are four options:
1. As part of a regular cycle (for example, monthly). Schedule a restore test for each application on a regular interval.
2. When an application changes significantly (patches, upgrades, for instance). Schedule a (more comprehensive) restore test when significant changes have been made to an application, such as upgrading to a new software release or when installing a major patch package or operating system change.
3. When application data changes significantly. If an application has a regular import of data from an external source, for example, performing a test restore can help validate timings for data recovery.
4. When a new application is built. This means testing the restore of a new VM or server when first created. This may seem excessive, but it makes sense to ensure that the server/VM has been added to the backup schedule.
The ability to test recovery can be significantly improved by the use of automation. At the most basic level, this can mean scripting the restore of individual files. But more complex testing can be done with the use of software tools, many of which are integrated into backup software products.
Read More @ https://ictaa.com.au/what-is-rmm