It is not possible to guarantee the integrity of files backed up to the HFS that are open when backup occurs. This is not a fault of TSM, but a problem for data backup in general. The results of open file backup are questionable because, if a file is altered during its backup, then it may be internally inconsistent. This will mean that a restored file would appear corrupt to the application that tries to use it. For this reason, we recommend that you close all files and applications before running a backup.
If you are not sure whether your files are being backed up successfully, please check your error and schedule logs,
dsmsched.log respectively (see further our page on How to Check That Backups Ran Successfully). We send e-mail alerts to all users whose scheduled backups fail; in some cases, however, a small number of individual files may fail to back up but the overall backup will be considered successful by TSM. This happens when one or more files are skipped - either because they were locked by a client application and so could not be accessed, or because they changed multiple times during backup. It is therefore vital that you check the log files for files that were skipped for these reasons. We would strongly recommend that, for important files that may be open during a backup, a test restore is occasionally carried out. In this way you can verify that a file's backup was complete and that it is readable by the appropriate application.
The following notes pertain to particular areas where closing files may be difficult.
2. Microsoft Outlook mailboxes
pst files cannot be backed up by TSM, because of the particular way in which Microsoft Outlook locks mailboxes while it is running. If you use Outlook, please make sure to close it while you are running a backup.
3. Virtual machines
In most cases, it is inappropriate to back up virtual machines externally; it is preferable to back them up internally, as individual TSM nodes separate from their host machines. On this please see further our page on backing up virtual machines/VMware with TSM.
However, if you have virtual machines that rarely change (such as a development machine), then you might want to back them up externally. In this case they would need, like databases, to be closed in order for a backup to be successful - see the aforementioned section about virtual machines for advice on how to achieve this.
4. Windows system files
TSM backs up the Windows system services and system state separately from other hard drive data. It composes its own consistent and coherent copy of the system files concerned, using an OS-appropriate method, and backs this up. The parts dealt with in this way include the Windows registry, system and boot files and the event log.
Backing up of the Windows system files is of limited use, however, since they are only likely to work on hardware identical to that from which they have been backed up. If you are restoring data to a new hard drive, we recommend that you first re-install Windows and all software from the original media, and then use TSM to retrieve your documents, browser bookmarks and other files peculiar to the machine being restored.