It should be known by now that backing up your data is a fundamental business requirement, but there are still those, often smaller businesses, who don’t comply. Imagine if you lost all of your financial documents or customer data; it’d be utterly disastrous if you didn’t have a backup copy to fall back on. Perhaps one reason businesses don’t backup is because they see it as too costly. One method to combat this is to use database snapshots as backups.
Although data duplication is usually carried out usually a disk-based solution, this is something that faces various issues as the amount of data produced globally continues to expand:
• The amount of data being produced is growing so rapidly that devices can’t be developed fast enough to store the capacity.
• The devices alone don’t provide information on how efficient the backups are.
• The need to have data available round the clock, at every hour, can cause complications on when backups are completed.
The above information was summarised by Wikibon, a group of technology and business system enthusiasts, who surveyed organisations to find out more about their recovery-time objectives. The result of the points above found that many businesses were struggling to meet their objectives for critical applications.
Their CEO and co-founder is David Vellante, a man who believes that these issues can be limited or even reduced altogether by using database snapshots. These snapshots take a capture of changes within a database at a set time. An initial first copy of the database is backed up and from then on snapshots are taken; if recovery is required, that snapshot is applied to the first copy.
One of the great benefits of this is that snapshots take hardly any space up – especially not as much as a full backup. Snapshots can also be spaced out to user-defined intervals, whether that’s every five minutes or every day.
However, Vallante notes that snapshots shouldn’t be taken all the time just because the facility is available. He believes this is a dangerous waste of resources. Instead, a recovery-point objective should be found for each database and this should be used to calculate how often snapshots should be taken.
On top of the database snapshots, it’s also useful to record exactly what data is being backed up. This is where something like a backup catalogue comes in. This tracks what data is backed up, where the backup is stored and any other relevant metadata. This information is then stored inside the appliance and is available for use by the system that created the backup.
This information can be used to automate recovery from database snapshots. For example, it can be determined when a database was made, if it has been copied and what the most recent version is. The system can automate the process to determine which data should be restored, eliminating the risk of data duplication or user error.
The full report from Wikibon can be found on their official website in a report titled ‘Thinking Beyond Backup: Getting More From Snapshot Technology’.
Using Database Snapshots to Reduce Backup Costs
No comments yet. Sign in to add the first!