This article is as much a discussion document as it is a summary of my existing backup strategy. My aim is to open the discussion up and see if together we can’t form a Best Practice for this type of scenario. So here it is, a simplified description of the backup strategy which I employ now.
|Job Name||Runs||Points to Keep||Result||Location|
|All VM’s||Weekly||4||1 Full per month & 3 incrementals||Site B|
|Important VM’s||Daily||7||1 Full per week & 6 incrementals||Local Site|
|Very Important VM’s||Hourly (8am-8pm)||12||1 Full per Day & 11 incrementals||Local Site|
Site B also runs this same scenario – so all company data is held in two locations. In addition, a 3rd backup repository has been built at Site A which gives a 3rd physical target – the long term archiving discussion below is aimed at this location. Finally a tape drive is also available, but is not part of this discussion – and may not feature in the plan due to capacity issues.
Why use a local target for my backup data? All my eggs in one basket I here you shout. The answer is recovery speed! If the backups were offsite, over a slow link, recovery time would be too long for the business to stand.
What the business wants..
To have Full backups available per week, month, quarter & annually (up to 10 years)
The obvious solution..
Run one Backup job, which executes once per week..
In turn, this calls a Copy Backup job, with weekly, monthly, quarterly & annual retention periods. As per this link
BUT the end result is..
At the end of the 1st year, 12 Full size Backups! This is too much data to hold. Each additional year only adds one more copy, but by this time the repository will be overflowing.
Weekly incrementals for the 1st Month
Monthly incrementals for the 1st Quarter
Quarterly incrementals for the 1st Year
Reoccurring Year end backup..