- When is a file moved from the Data area to Retention?Answer) A file is moved from Data area to the Retention when it is modified or removed on the source machine.
- How long will the file(s) be kept in the Retention?Answer) Retention policies define what files in Retention area should be kept, retained files no longer covered by the Retention policy will be deleted from Retention area and the corresponding file versions will no longer be recoverable. In other words, a 7 day, 5 week, 13 month, 5 year policy does not mean creating 30 copies of the backup data.
- Can you tell us more on how Retention Policy works?Answer) Yes, let’s look at some examples here:Assuming the following retention policy is set: 7 day, 5 week, 13 month, 5 year retention policy
- A file that has not been changed for 5 years will remain in Data area and no copies will be made
- A file modified once in the 2nd year will have the current version stored in Data area and the previous version in Retention area after 5 years
- A file created and removed within a year, for example, it never exists in Data area during any of the year end jobs, thus is not covered by the 5 year policy, will be removed within 13 months, depending on how file is being covered by the monthly policy
- When performing a file backup, only new or modified files will be backed up. In other words, even if you set a full file backup to be run on a particular day, it will only pickup files that have deltas and are modified since the last backup.
- What about the “Remove retention files for overlap policy” option? Can you give us more details on this option?Answer) The “Remove retention files for overlap policy” option could be used if the user wants to further reduce the amount of required storage while complying with his backup policies. Let’s look at an example here:For instance, a company requires backups of its sales database at the end of each month, and once they got this month-end backup, those daily backups for that month would become redundant. i.e. Once they got the 30th Jun backup, all 29th Jun, 27th Jun, … 1st Jun backups are not longer needed. In this case, they could set a Daily retention policy of 31 days, plus a Monthy policy for the end of each month, and then enable the “Remove retention files for overlap policy” option. This would effectively remove the files retained by daily backups preceeding the end of month backup.
- Are there any recommendation on how the retention policy should be set?Answer) We would suggest that, the retention policy set should be longer that the typical frequency of use for the files in the backup source. In other words, if a particular set of file is only used once quarterly, then the backup data should be retained for more than a quarter.
Archive for December, 2008
FAQs regarding file retention policies
Friday, December 26th, 2008Best setup for Exchange store level backups
Friday, December 26th, 2008Many of you have asked, what is the most efficient manner in which to backup your exchange stores daily without ending up with a huge retention area or a ton of log file backups to replay?.
This really depends on what recovery windows are acceptable to you. For example if you need to run a backup every 1-2 hours and this is the longest you can be without a backup, the strategy outlined below is not going to be much help to you. No matter which way you cut it, you are going to have a large amount of incremental/log file backups in this scenario.
It also depends on your retention period. e.g. the last 30 days of backups or the last 6 months!.This will have a huge factor on how much data is stored in your retention area in relation to your exchange store.
However for the rest of us that are happy with a nightly backup of our exchange stores the we have found the following to be efficient in terms of backup time window, retention space and the ability to recover.
We are going to assume a thirty day retention policy. Changes of up to 50% are allowed in the priv and pub .edb files, before a new master backup is uploaded again.
Basically you do only a combination of Differential and incremental backups with the incremental running Mon-Fri and the Differentials running over the weekend or mid week as well depending on your recovery requirements. This allows you to recover from the last successful incremental or the last Successful differential, regardless of any incremental failures before that point. This offers you a window of safety over an incremental only strategy. You cannot restore prior to the last successfull incremental if the previous days incremental failed, this makes all of the older backups useless. By combining the Incremental and differential backups you are able to minimize upload times and retention area growth, plus you have the added advantage of being able to minimise the impact that an incremental backup failure will have on your backup set.
Continuous Data Protection option
Thursday, December 25th, 2008Folks
Many of you have been asking for this feature, we are proud to announce that we now support CDP for the windows platform for file data; this allows you near real-time backup jobs every five minutes to give you a very short backup window. This is especially suitable for file data as it is not subject to massive changes on a per minute basis.
For those of you wishing to utilize the CDP feature on your exchange and MSSQL backups we would urge you to setup a multi schedule log file backup running every five to ten minutes instead, this will have the same effect but with less of a load.
If anyone needs assistance or would like help wiith their setup please let us know.
