Data cannot be archived indefinitely. We ask project applications to state a realistic lifetime for a project. Some projects have a natural conclusion whereas others may extend into the future due to regulatory requirments or simply because the data is of great value. Typically, projects are granted archival for 1-5 years. Where longer retention is desired, we advise that a further case for continued archival is made on every 5 year anniversary, this being not too onerous while ensuring the archive receives appropriate occasional consideration.
- Backup accounts
Archived data must not be backed up to the HFS backup service. Where a client machine is sending data to both the backup service and the archive service, the TSM client software must be configured in such a way that avoids sending the same data to both backup and archive. We can help with the setup of this configuration. In practice this normally requires a physical separation of the archive data from backup data on the client (for example into a separate partition or root folder-path).
Long-term projects, and those requiring large amounts of data (> 4TB) will probably be asked to contribute to the on-costs of archive storage (see the HFS Service Level Description). Externally-funded projects should have a defined element for data storage and will be expected to contribute to these costs.
There are limits to the amount of data the service can store. In practice a range of between 50GB and 50TB is acceptable. Requests at either end of those scales will, however, be subject to greater scrutiny and possibly additional restrictions. At the lower end we might ask why local storage cannot be used. Towards the upper end, we might ask for additional assurances on data curation, provenance and access. Projects above 50TB may be considered but additional storage charges above 4TB may make a local storage solution more of an economic proposition.
The configuration and use of the TSM archive / retrieve client software differs subtly from the TSM Backup / Restore client. For this reason you are strongly encouraged to read the following sections in order.
The TSM Archive client uses the same software as the TSM backup client. Consequently those archive clients which have already installed and are using the TSM software for backup, will just need to follow the additional configuration steps available from the links below, in order to use the HFS archive service.
There are some general considerations on archive and retrieve that apply to all TSM client users, irrespective of the client platform they are running. Please therefore read the next section before reading the platform specific pages on how to use the TSM archive / retrieve software.
Archiving is in some ways a completely separate concept to that of backup. Additionally, by its very nature, archive suggest an inherent value in the data to be secured. For these reasons it is advisable to start using the TSM archive software by setting up a test area within the project and exploring the capabilites and features of the TSM archive client in a test environment, before moving on to archive "live" project data.
Archive file identification
When using the TSM Backup Client, the location of a file - i.e. its directory / folder path - identifies that file. This is because there can at most be only two versions of the same file held on the backup server. In contrast the TSM Archive Client allows unlimited versions of the same file to be kept and then for the source files on the local machine to be deleted. (Archiving of multiple versions of the same file is not recommended unless the contents of files are different and required.) As such, the local directory / folder structure may provide little clue as to its archive contents and will certainly provide no information as to how versions of the same file differ.
Possible solutions to the above are to add a README or INDEX file in each directory folder, listing descriptions, dates and times of each file archived in that location. Alternatively and/or additionally, an entry in the
Descriptionfield may be used. By default TSM populates this field with the text "Archive Date: Date" which clearly becomes useless if you archive the same file twice on one day. We recommend that more descriptive entries in this field (max length 255 characters) be used for each file archived to group and distinguish archived files.
Multiple user accounts
It is also important to consider the account (or username) under which you are going to do the archiving. On a Linux/Unix system, only the user who archived a file can see it within the archive, and only that same user can retrieve it (except that as usual root can see all and do all). If you are archiving repeatedly related material, when you (or someone) comes to retrieve it, it will probably be simply confusing if the archiving has been performed under different usernames.
Symbolic file links (Linux/Unix)
Under Unix, when you name a symbolic link in an archive operation, the object pointed to by the link is archived, not the link data. This behaviour differs from that of backup, where the link data is backed up.
Local file deletion
The TSM archive client offers an option to delete the local files immediately on successful archival to the server. This option needs explicitly stating on the command line or setting in the Archive Options in the GUI and probably should not be used. The archive data is secured on the TSM Archive Server by making three copies to tape. This process occurs early each morning between 00:00 - 01:00 am. We therefore recommend that where Archive clients need to delete archived material from their local machines - for example for reasons of space - they should desist from doing so until the day following the archival process for any particular file and then do so through local operating system commands.
Archive file deletion
Unlike the TSM backup client, the TSM archive client allows the deletion of files archived on the server. Obviously care should be taken in use of this, as once deleted from the server, a file cannot later be retrieved.