File exists File deleted
Policy Settings: verexist = 4; verdel = 2; retextra = 30; retonly = 45
File1 - 05/Jan
(verdel , retextra , & retonly)
File1
In our example, Figure 26 shows a scenario in which the last inactive backup copy of file1 will be kept up to March 9th, 2000.
Figure 26. RETEXTRA and RETONLY expiration processing
As a rule of thumb, VEREXIST should be greater than or equal to VERDELETED (VEREXIST >= VERDELETED) and RETONLY should be greater than or equal to RETEXTRA (RETONLY >= RETEXTRA).
2.4.7 Backup binding
Any object stored in the Tivoli Storage Manager server is controlled by specific criteria in such a way that the server knows how long that object must be kept. In other words, a backup file, directory and any other object stored in Tivoli Storage Manager has one management class reference that dictates how many copies can be kept, and how long a backup file must exist in the server. The link process between the file and the management class is called binding.
The binding process occurs when you perform an incremental backup. The Tivoli Storage Manager client checks both the server management classes and the client include-exclude list or client option files to perform the binding process.
Figure 27 shows an example of many files and their management class bindings.
In the example, files from the /home directory are bound to the PERSONAL management class. All files from the /public directory are bound to the SHARED management class. Because the include-exclude list does not reference any other specification for files, our /adsm directory is implicitly bound to the assigned default management class in the server. An object can only ever be bound to one management class.
File1 - 05/Jan
Last Inactive Copy File1 - 22/Jan/1999
expired (not accessible)
File1 - 15/Jan
(retonly)
Dates
22/Jan - file still active
23/Jan - file deleted ( enforce verdel=2 ) 24/Jan - server expire inventory ...
21/Feb - server expire inventory (delete 20/Jan file1 version) 23/Feb - server expire inventory (RETONLY control takeover) 24/Feb - RETONLY control
...
08/Mar - RETONLY last day control (23/Jan + 45 days) 09/Mar - server expire inventory
09/Mar - File1 Last Inactive Copy deleted.
Deleted file : Policy Settings: verexist = 4; verdel = 2; retextra = 30; retonly = 45
File1 - 20/Jan
Figure 27. Binding files to management classes
2.4.8 Rebinding
Because a file stays bound to one single management class, every time you run a new incremental backup operation, the server checks to see if the file still belongs to the same management class and changes the class if necessary. This process is transparent to the user and is called rebinding the file. A file or directory will be rebound in the following cases:
• Include-exclude list: If you change the management class for a file, this affects all previous backup versions of that file and all future backup operations for that file as well.
• Changes in the number of management classes: If you delete or rename a management class, the server rebinds the files to either a DEFAULT class or uses grace periods in the policy domain to control retention. In this case, the server controls data by retention and not by versions. This may not be desirable, since you do not have a management class controlling those files.
Although the rebinding process for this case was unsuccessful, Tivoli Storage Manager still controls the file by other means.
For further details on management classes and settings, see Chapter 3, “Data storage policy” on page 63.
2.4.9 Backup special considerations
The Tivoli Storage Manager incremental backup actually offers two options, completeanddate only. These are also known asfullandpartial incrementals, or full incrementalandincremental-by-date. Normally you would use the default, which is the complete or full incremental. This is the option described in 2.4.2,
“Incremental backup” on page 37. Many attributes of each file are examined to determine if it has changed and therefore needs to be backed up. In a partial incremental operation, the client only asks the server for the date and time of the last incremental backup. If a file’s last changed date and time is after that of the last backup, the file is backed up. Otherwise it is not, even if the file is new to the workstation. Because changes to ACL or file permissions do not change the last changed date and time attributes, a partial incremental would not detect this, so the file would not be backed up. A file which is copied or created on the client with an older date/time stamp than the date/time of the last backup would also not be sent. In a partial backup, deleted files from the client are not recognized, and no version expiry or rebinding takes place.
Because a partial incremental backup only performs a fraction of the processing of the normal full backup, it does not ensure that the files contained in the server storage exactly match the current state of the files on the client. For example, files that would normally be backed up during a full incremental might not be backed up during a partial incremental; and old files that should be deleted from the server might not be deleted. Since this is the case, why have the partial incremental possibility at all? The reason is that this operation takes less time to complete than the regular full backup. So, in some particular circumstances where there is a problem meeting a limited backup window, you might use a partial incremental operation. If you do this, you MUST remember to periodically run full incremental backups to bring the Tivoli Storage Manager server in line with your workstation's status. For example, if you have only a limited time during the week to perform backups, but have extra time on the weekend, you can use partial backups on the weekdays, and then use full incremental backups on the weekends. However, if there is not a problem with the backup window, then always run the full incremental option.
2.5 Archive
The Tivoli Storage Manager Archive function stores selected files unconditionally on the server, according to the applicable management class limits.
Unconditionally means that there is no version limit and they will be retained for the defined time period regardless of whether they are deleted on the client.
Archived files are useful if you want to take a snapshot of particular files, or if you want to delete files, freeing up space, yet still have the ability to retrieve them if required. It is very common to have a legislative requirement to archive business records for long periods of time, and the archive function is ideal for this purpose.
Figure 28 shows a schematic archive operation.
Figure 28. Archive in progress
2.5.1 Packages
Archive packages are groups of files archived together with a common
description. The system will automatically supply a description consisting of the time and date stamp, or you can override this with your own meaningful
description. This description is used later to allow easy searching and selection of archive packages to retrieve.
You can add to an existing package on a subsequent archive operation by supplying an existing archive package description.
You can either retrieve individual files within a package or delete files from a package. Figure 29 shows a summary of the packaging features.
Figure 29. Packaging files
2.5.2 Client space reduction
You can use archives to release storage space on your workstation and delete files as you archive them. This is useful when you know in advance that it is no longer necessary for a file to stay in the workstation, but it may still be important to keep the file for some time. You can archive and delete any file and use any retention period available in the archive management classes.
Tivoli Storage Manager
Figure 30 shows an example of an employee who has left the company. Because this employee had many files that may be needed, all files are saved for 30 days and deleted from the fileserver to make room for other users. The archive function includes an option to automatically delete the files after they are successfully received at the server.
Figure 30. Archiving unnecessary files
2.5.3 Retention
When you archive a file, you can select between the available management classes that your client machine has access to. This makes it possible for you to select the retention period (according to the retention period in days specified in the archive copygroup) for all the data you are archiving. Archiving is different from file backup in that the user may select from the available management classes to determine the retention. For file backup, the user may not control the management class to which the files are bound.
Typically, you might use archives to save information that has either a legal requirement (such as account information, annual reports, billing information, and annual customer reports) as shown in Figure 31, or even an internal audit requirement (to keep application logs, user activity information, employee files, and so on).
fileC
fileA fileB
Spreadsheets
mailbox files
Corporate Fileserver
Em ployee: LUCIA.
Personal files keep for 30 days
"delete from client"
Figure 31. Archiving long-term files
2.6 Logical volume backup
Tivoli Storage Manager enables you to backup a file system or raw logical volume as a single object from your client machine. The Tivoli Storage Manager client accomplishes this by dynamically loading an image plug-in utility which sends the object to the server using the Tivoli Storage Manager API. This capability is currently available for the AIX, HP-UX and Solaris clients and can be used on a logical volume whether or not there is an associated file system. This will ensure a clean backup. Figure 32 shows the operation of the image backup and restore operation as a single object.
Figure 32. Image backup and restore
Logical volume backup has the advantages of improved backup and restore speeds, and conserving server resource since the entire backup is treated as a single object and individual files are not processed during backup or restore.
Similar to the standard incremental and selective backup filtering options, you can include specific logical volumes and assign a Management Class to image