TSM Backups and Restores
- Journal Backups
- Image Backups
- TSM 7.1 and VMware
- TSM 6.4 and VMware
- Windows Cluster Backups
- VCS Cluster Backups
- LAN free backups
- TDP for MSSQL DBs
- TSM with DB2
- Oracle TDP Backups
File systems that contain millions of files cause a number of problems for TSM.
An image backup will copy any filespace as a single blob, no matter how many files it contains. The advantages are that backups and restores of the filespace are fast, and you just get one entry in the database. The disadvantage is that you cannot restore individual files, just the whole filespace.
There are two scenarios where image backups can assist with problem filespaces.
There's 2 kinds of image backups, static image and online image.
Static image requires exclusive use of a filespace, so it puts a lock on it at the start of the backup so no-one else can access it, and releases the lock at the end of the backup. This is pretty much unrealistic for any kind of production data, unless you can arrange a total outage while you run your backup.
Online Image backups use snapshot technology. There's lots of ways to take snapshots, using either hardware or software, but the simplest answer seemed to be to use Microsoft's VSS (volume shadow services) if it is enabled. This is software based copy-on-write technology that uses temporary space in the existing filespace. you can find more information on VSS here, and hardware snapshots here.
Online Image Backup configuration requires three steps.
And that's it. Run the schedule and you should see something like
If you want to bind your image backups to specific management classes, please be aware that wildcards do not work with image backups in the same way that they work with other include statements. You can assign all the image backups for this client to a management class with the statement
include.image * mgmtclass
However if you want image backups to have different management classes, you cannot pick them out with wildcards, you need to specify the full filespace like this
include.image /usr/filesystem1 mgmtclass1
include.image /var/filesystem2 mgmtclass2
OK so far, but what about a restore? An image restore from either a static or online image backup requires exclusive use of an empty file space. This should not be an issue if you are rebuilding a server, but if the unlikely happens and you just need to retrieve a couple of files from an old backup, then you need to get some temporary disk space allocated and you have to restore the whole image, or in other words, the whole filespace. Note that even though the backup above just copied 61.63GB, a restore needs the full 300GB.
Once the restore completes you can see the full filespace with all it's original files, so it would be easy to copy over any that were required.
So this process could work well for large file spaces that hardly ever need files restored but the question you need to answer is, is the saving in TSM database worth the effort involved if you ever need that restore?