How PIT Restores Work

TSM point-in-time (PIT) restores allow you to restore data as it was at a certain point in time. When you choose to do a PIT restore you specify a date and time, for example 12/01/2014 12:00. TSM will then allow you to restore only versions of files and directories that existed at that time.

Example: file1.txt has 3 versions stored in TSM.

Version	Backup Date
file1.txt  (current version)	12/15/2014 2:00
file1.txt (version 2)	11/28/2014 2:00
file1.txt (version 3)	10/01/2014 2:00

If you choose 12/01/2014 12:00 as your point-in-time then the version that was backed up on 11/28/2014 will be available to restore.

If you choose 09/01/2014 12:00 as your point-in-time then no version will be restored since no version from that time exists. The file may have existed at that time but TSM can’t restore it because it doesn’t have a relevant version.

The same situation is true of a directory. If a version of a directory doesn’t exist from that point-in-time, then TSM won’t let you restore any files or subdirectories contained in it. You can still restore the files using a normal, non-PIT restore.

In general, PIT restores are only reliable going back as far as the number of versions you keep. If you are using a 3 version policy then PIT restores work very well up to 3 days in the past. Be aware that your backup may have run after midnight so 3 versions only goes back 2 days (if today is the 18th and the backup ran at 2:00 AM, then I can do a PIT restore for the 17th or the 16th. The farther back you go the greater the chance of the PIT restore missing files due to aged out versions.

PIT Restores and Directories/Folders

Sometimes a PIT restore isn’t possible for directories where backup data still exists in TSM but the relevant directory versions have already aged out. Think of it like an island where the bridge was removed. If TSM can't traverse the bridge then it can't restore the data even though it has the data and it existed at the time specified in the PIT.

One reason this can happen is that TSM does not use the default management class for backing up directory objects, instead it chooses the management class with the longest retention period. It does that so that a directory version will always be available to restore if there are file versions still in it or a sub directory. In a normal, non-PIT restore, TSM just restores the most recent version of a directory, so directory versions don’t really matter as long as one still exists. There may not be a version of the directory that is the same age as the file but a version will exist. When TSM choses a management class for directories it only looks at the retention period and not the number of versions. So if it chose a management class with unlimited retention but only one version the PIT restore might only work to go back one day. You can have a case where a file version exists in a sub directory, but the TSM client can’t get to it because a directory in the path has changed a few times or has less versions and doesn’t have a version available from that time. You end up with a bunch of files on an island with no bridge to the perspective of the PIT restore. In this situation, you can still restore those files by doing a normal, non-PIT restore.

This is most often a problem for Windows because Windows updates the modified time on a directory whenever a file or directory is created or removed inside it. Linux/UNIX file systems do not update the modified time on a directory when files or directories are created or removed inside it, so directories change much less frequently in the UNIX world.

Closing the Gap

To prevent the PIT island from forming, TSM has a client option that solves the problem by forcing directories to bind to a specific management class. To enable it, add a line like this to your dsm.opt/dsm.sys file:

DIRMC                  MANAGEMENT_CLASS

That will cause all directories to be rebound to the specified management class the next time a backup runs. In most policy domains we recommend using the management class called FOLDER_PIT. FOLDER_PIT has 3651 versions for 3651 days so it should be able to handle about 10 years of daily changes. Directory objects don’t count against your occupancy, so your billing should not be affected.