File Revisions vs. File Retention

You can adjust the File Revision limit and/or make File Retention rules on a per-Client basis to help manage the storage space used by a Client at the Data Repository.  Backup for Workgroups is designed to store all backup data in one location, without needing to manually clear out data from the hard drive storage device.

File Revisions:

The Backup for Workgroups incremental backup is on a whole file basis:  when the backup occurs and a changed file is detected, the entire file will be backed up again, creating a new revision of that file.  It is not just the portion of that particular file that has changed - it is the whole file again every time.  This way each revision stands on its own and can be restored on its own, without needing to apply any other revision of that file.

Backup for Workgroups stores the revisions of each file that changes on a per-file basis, where the most current version is stored first and then each revision back in time is stored up to the set limit (default limit = 25).  So initially, the original baseline backup on day 1 is the most current revision.  Over time, a file changes, it’s most current version is stored first, with the original baseline now being the oldest revision.  Each revision is stored so that they can be independently accessed without any dependency upon each other.  This means that Backup for Workgroups can restore any revision of a file without needing any of the other revisions.

The default revision limit of every backup set is 25.  This number can be changed to be as low as 1, as high as 999, or removed entirely.  For Clients that are backing up large files on a daily basis, lower the Revision Limit so fewer revisions are stored in the Data Repository.

Example # 1:  You have a Client that is performing a daily backup of a 5 GB Exchange Server database.  Every day a new revision of the Exchange Server database is sent to the Data Repository, which means that it is consuming an additional 5 GB of storage space every day.

Solution # 1:  You may decide that you are only interested in saving the last 2 weeks worth of Exchange backups, so you can change the Revision Limit for that Client to be 14.  When day 15 hits, the oldest revision will be dropped and purged from the Data Repository.  This means that only 70 GB (approx) of storage space is needed for the Exchange Database at any given time.

File Retention Rules:

When you delete a file from a Client computer and Backup for Workgroups performs a backup, the Client detects that the file has been deleted and it records that the file is no longer on the Client computer.  However, the deleted file contents are still retained in the Data Repository with the intent that you can restore it later.  By default, all files that are backed up and subsequently deleted will be retained forever.

If you do not want to ever restore a deleted file, then you can use a Retention Rule to purge the deleted files from the Data Repository on a scheduled basis.  When you set a Retention Rule, it defines the time to retain a deleted file in the Data Repository.  So when a backup occurs, it will compute the number of days since the file was deleted.  If the number of days exceeds the number defined by the rule, the Data Repository purges the deleted file.  At that point the file is no longer on the server or in the Data Repository, and cannot be restored.

Example # 2:  You have a Client that is backing up a transaction log file that is deleted from the server itself after it has been generated.

Solution # 2:  You can create a Retention Rule that will automatically delete these log files from the Data Repository after they have been there for more than 2 days, 3 days, etc.