Multiple versions of files are useful when users continually update files and sometimes need to restore the original file from which they started. The most current backup version of a file is called the active version. All other versions are called inactive versions.
- Directly specifying the number of versions You specify the number of backup versions with two parameters:
- Versions Data Exists (number of versions to keep when the data still exists on the client node)
- Versions Data Deleted (number of versions to keep when the data no longer exists on the client node)
- Specifying the number of days to keep each backup version You specify the number of days to keep backup versions with two parameters:
- Retain Extra Versions (how many days to keep inactive backup versions; the days are counted from the day that the version became inactive)
- Retain Only Versions (how many days to keep the last backup version of a file that has been deleted)
- Specifying a combination of the number of versions and the days
to keep them
Use a combination of the four parameters: Versions Data Exists, Versions Data Deleted, Retain Extra Versions, and Retain Only Versions.
These parameters interact to determine the backup versions that the server retains. When the number of inactive backup versions exceeds the number of versions allowed (Versions Data Exists and Versions Data Deleted), the oldest version expires and the server deletes the file from the database the next time expiration processing runs. How many inactive versions the server keeps is also related to the parameter for how long inactive versions are kept (Retain Extra Versions). Inactive versions expire when the number of days that they have been inactive exceeds the value specified for retaining extra versions, even when the number of versions is not exceeded.
For example, see Table 1 and Figure 1. A client node has backed up the file REPORT.TXT four times in one month, from March 23 to April 23. The settings in the backup copy group of the management class to which REPORT.TXT is bound determine how the server treats these backup versions. Table 2 shows some examples of how different copy group settings would affect the versions. The examples show the effects as of April 24 (one day after the file was last backed up).
| Version | Date Created | Days the Version Has Been Inactive |
|---|---|---|
| Active | April 23 | (not applicable) |
| Inactive 1 | April 13 | 1 (since April 23) |
| Inactive 2 | March 31 | 11 (since April 13) |
| Inactive 3 | March 23 | 24 (since March 31) |
| Versions Data Exists | Versions Data Deleted | Retain Extra Versions | Retain Only Version | Results |
|---|---|---|---|---|
| 4 versions | 2 versions | 60 days | 180 days | Versions Data Exists and Retain
Extra Versions control the expiration of the versions.
The version created on March 23 is retained until the client node
backs up the file again (creating a fourth inactive version), or until
that version has been inactive for 60 days. If the user deletes the REPORT.TXT file from the client node, the server notes the deletion at the next full incremental backup of the client node. From that point, the Versions Data Deleted and Retain Only Version parameters also have an effect. All versions are now inactive. Two of the four versions expire immediately (the March 23 and March 31 versions expire). The April 13 version expires when it has been inactive for 60 days (on June 23). The server keeps the last remaining inactive version, the April 23 version, for 180 days after it becomes inactive. |
| NOLIMIT | 2 versions | 60 days | 180 days | Retain Extra Versions controls
expiration of the versions. The inactive versions (other than the
last remaining version) are expired when they have been inactive for
60 days. If the user deletes the REPORT.TXT file from the client node, the server notes the deletion at the next full incremental backup of the client node. From that point, the Versions Data Deleted and Retain Only Version parameters also have an effect. All versions are now inactive. Two of the four versions expire immediately (the March 23 and March 31 versions expire) because only two versions are allowed. The April 13 version expires when it has been inactive for 60 days (on June 22). The server keeps the last remaining inactive version, the April 23 version, for 180 days after it becomes inactive. |
| NOLIMIT | NOLIMIT | 60 days | 180 days | Retain Extra Versions controls
expiration of the versions. The server does not expire inactive versions
based on the maximum number of backup copies. The inactive versions
(other than the last remaining version) are expired when they have
been inactive for 60 days. If the user deletes the REPORT.TXT file from the client node, the server notes the deletion at the next full incremental backup of the client node. From that point, the Retain Only Version parameter also has an effect. All versions are now inactive. The three of four versions will expire after each of them has been inactive for 60 days. The server keeps the last remaining inactive version, the April 23 version, for 180 days after it becomes inactive. |
| 4 versions | 2 versions | NOLIMIT | NOLIMIT | Versions Data Exists controls
the expiration of the versions until a user deletes the file from
the client node. The server does not expire inactive versions based
on age. If the user deletes the REPORT.TXT file from the client node, the server notes the deletion at the next full incremental backup of the client node. From that point, the Versions Data Deleted parameter controls expiration. All versions are now inactive. Two of the four versions expire immediately (the March 23 and March 31 versions expire) because only two versions are allowed. The server keeps the two remaining inactive versions indefinitely. |
See Administrator's Reference for details about the parameters. The following list gives some tips on using the NOLIMIT value:
- Versions Data Exists
Setting the value to NOLIMIT may require increased storage, but that value may be needed for some situations. For example, to enable client nodes to restore files to a specific point in time, set the value for Versions Data Exists to NOLIMIT. Setting the value this high ensures that the server retains versions according to the Retain Extra Versions parameter for the copy group.
- Versions Data Deleted
Setting the value to NOLIMIT may require increased storage, but that value may be needed for some situations. For example, set the value for Versions Data Deleted to NOLIMIT to enable client nodes to restore files to a specific point in time. Setting the value this high ensures that the server retains versions according to the Retain Extra Versions parameter for the copy group.
- Retain Extra Versions
-
If NOLIMIT is specified, inactive backup versions are deleted based on the Versions Data Exists or Versions Data Deleted parameters.
To enable client nodes to restore files to a specific point in time, set the parameters Versions Data Exists or Versions Data Deleted to NOLIMIT. Set the value for Retain Extra Versions to the number of days that you expect clients may need versions of files available for possible point-in-time restoration. For example, to enable clients to restore files from a point in time 60 days in the past, set Retain Extra Versions to 60.
- Retain Only Version
-
If NOLIMIT is specified, the last version is retained forever unless a user or administrator deletes the file from server storage.