STANDARD Retention Policy
This will be the default retention policy for the UBI system.
Total versions kept: Unlimited
Inactive versions kept: Unlimited
Inactive versions kept for: 30 days
Last remaining version kept for: 30 days
You can select this retention policy by specifying the management class “STANDARD” in your include statements within the dsm.opt file. If no management class is specified, this will still be the retention policy used since it is the default.
In UBI, we will provide 1 active version and unlimited inactive versions for 30 days. Unlike the TSM backup service, the unlimited inactive versions allows you to restore a file from any point in time over those 30 days.
A new version of a file is added during the backup, if it is a new file, or if it is detected that the file has changed since the previous backup. Changes to a file will not be captured as a new version until the next backup has run.
The backup version that, at the time of the most recent backup, matches the state of the file present on your system, is called the “Active” version. Versions that are no longer present on your system are called “Inactive” versions. If a file changes, during the next backup the previous version is marked as “Inactive”, and a new “Active” version is stored.
A file that has been deleted from your system will only have “Inactive” backup versions following the next successful backup.
Active versions remain until a new backup causes them to become inactive, regardless of how much time elapses.
Inactive versions remain for 30 days from the time it became an inactive version.
There are no limit to the number of inactive versions you may have.
Example of STANDARD retention policy:
A user creates a file on March 1, 2017, and is backed up that night.
The following versions are now present on the server:
- 2017-03-01 (Active)
The user modifies the file every day for a month, and it is backed up nightly.
The following versions are now present on the server:
- 2017-03-31 (Active)
- 2017-03-30 (Inactive since 2017-03-31)
- 2017-03-29 (Inactive since 2017-03-30)
- 2017-03-28 (Inactive since 2017-03-29)
- 2017-03-27 (Inactive since 2017-03-28)
. . .
- 2017-03-05 (Inactive since 2017-03-06)
- 2017-03-04 (Inactive since 2017-03-05)
- 2017-03-03 (Inactive since 2017-03-04)
- 2017-03-02 (Inactive since 2017-03-03)
- 2017-03-01 (Inactive since 2017-03-02)
The user stops modifying the file.
On April 2, 2017, the version from March 1st expires (30 days after it became inactive).
On April 3, 2017, the version from March 2nd expires.
On April 4, 2017, the version from March 3rd expires.
and so on . . .
On April 29th the following versions remain:
- 2017-03-31 (Active)
- 2017-03-30 (Inactive since 2017-03-31)
- 2017-03-29 (Inactive since 2017-03-30)
The user deletes the file from the client system, and the nightly backup runs.
The active file becomes inactive, and there is no active file left. The following versions are now present on the server:
- 2017-03-31 (Inactive since 2017-04-30)
- 2017-03-30 (Inactive since 2017-03-31)
- 2017-03-29 (Inactive since 2017-03-30)
On April 30, 2017, the version from March 29th expires.
The following versions are now present on the server:
- 2017-03-31 (Inactive since 2017-04-30)
- 2017-03-30 (Inactive since 2017-03-31)
On May 1, 2017, the version from March 30th expires.
The following versions are now present on the server:
- 2017-03-31 (Inactive since 2017-04-30)
On May 30th, 2017, the last version from March 31st expires.
There are now no remaining backups of the file.
EXTENDED Retention Policy
Total versions kept: 5
Inactive versions kept: 4
Inactive versions kept for: 180 days
Last remaining version kept for: 365 days
You can select this retention policy by specifying the management class “EXTENDED” in your include statements within the dsm.opt file. If no management class is specified, the default (STANDARD) retention policy will be used.
Please note that even though the last version is kept for 365 days, since only 5 total versions of the file are kept, selecting this policy can often limit available restores for frequently changing files to only a few days.
A new version of a file is added during the backup if it is detected that the file has changed since the previous backup.
Changes that are made will not be captured as a new version until the backup runs.
The backup version that, at the time of the most recent backup, matches the state of the file present on the client system is called the “Active” version.
Versions that are no longer present on the client are called “Inactive” versions.
If a file changes, during the next backup, the previous version is marked as “Inactive”,
and a new “Active” version is stored.
A file that has been deleted will (after the next backup) have only “Inactive” backup versions.
We store a maximum of 1 active version plus 4 inactive versions.
Active versions remain until a new backup causes them to become inactive, regardless of how much time elapses.
We store inactive versions for 180 days after they become inactive, except:
We store the last remaining inactive version for 365 days after it became inactive.
Example of EXTENDED retention policy:
A user creates a file on March 1, 2017, and is backed up that night.
The following versions are now present on the server:
- 2017-03-01 (Active)
On the 2nd, 3rd, 4th, and 5th, the user modifies the file, and it is backed up.
The following versions are now present on the server:
- 2017-03-05 (Active)
- 2017-03-04 (Inactive since 2017-03-05)
- 2017-03-03 (Inactive since 2017-03-04)
- 2017-03-02 (Inactive since 2017-03-03)
- 2017-03-01 (Inactive since 2017-03-02)
On the 9th and 10th, the user again modifies the file, and it is backed up.
The following versions are now present on the server:
- 2017-03-10 (Active)
- 2017-03-09 (Inactive since 2017-03-10)
- 2017-03-05 (Inactive since 2017-03-09)
- 2017-03-04 (Inactive since 2017-03-05)
- 2017-03-03 (Inactive since 2017-03-04)
The user stops modifying the file.
On August 31, 2017, the version from March 3rd expires (180 days after it became inactive).
On September 1, 2017, the version from March 4th expires.
On September 2, 2017, the version from March 5th expires.
The following versions are now present on the server:
- 2017-03-10 (Active)
- 2017-03-09 (Inactive since 2017-03-10)
On September 3nd, the user deletes the file from the client system, and the nightly backup runs.
The following versions are now present on the server:
- 2017-03-10 (Inactive since 2017-09-03)
- 2017-03-09 (Inactive since 2017-03-10)
On September 6th, 2017, the version from March 9th expires.
The following versions are now present on the server:
- 2017-03-10 (Inactive since 2017-09-03)
On September 3th, 2018, the final version (from March 10th, 2017) expires.
There are now no remaining backups of the file.