How does TSM handle open files?
The TSM clients do a good job of backing up all of your files; however, if your organization is concerned about a set of data changing while the backup is in progress, there are ways to ensure this data is captured in a very consistent manner. The client software can deal with files that are marked "read only" by an application and there are even ways to handle files that are not readable because of a lock. Also, newer clients support logical volume snapshots, to build a snapshot of your filesystem to a specific time. Or, if your data is in an application, database, or mail server, IBM provides some specific modules that will provide a consistent online backup of those applications' databases, see the next question for more information. More specific information for how to handle open files is available in this IBM Redbook.
What about support for software like Exchange or Oracle?
IBM has some specific software to cover applications like MS Exchange, Oracle, DB/2 and even ERP. If your organization needs to support any of these, please look at the URL's below, and then contact the Open Systems Group so we can discuss your specific application needs in further detail.
How do you ensure database consistency?
TSM relies on its database to know where data lives, if this database were to have a failure data could be lost forever. NERDC takes the following precautions to ensure that never happens:
The database lives on mirrored disks managed by TSM. At least two mirrors are kept during normal operation.
Logs for the database live on mirrored disks managed by TSM.
Each night a full backup of the database is made to tape, these copies are kept for six days.
Each night a full backup is made to an offsite location, these copies are kept for six days.
How do you generate the Status Mail?
The status mail reports are generated by taking your indivudial filesystem backup tolernaces, and comparing the time when an incremental was last completed against a given filespace. This is an estimate of "When was this last backed up".
This estimate is imprecise in many ways. For example, incrementals can take a long time. We idealize them as happening 'at a point', but of course this is not the case. An incremental competed at 2300, but begun at 1700, may or may not have caught a change someone made at 2000
Similarly, a file might be changing all the time. TSM's default behavior in this case is to attempt to get a copy three times, and then give up. It is possible to alter this in several different ways; you can arrange for more or fewer attempts to be made. You can arrange for the last, inconsistent copy to be saved anyway, in the hope that something useful might be made of it. A classic example of such activity is a current, live logfile, or a database container. The TSM log itself is one of the most commonly seen in this state.
Windows likes to respond to files in-use by forbidding any other process from reading the file. In this case, TSM can't even get hold of the file. It is possible to get around this restriction by use of a volume snapshot, but this is probably unwise: the file has been set off-limits, probably for a good reason.
Many boxes have one or another of these problems on a given night. The overwhelming majority of them are of no concern to the administrators in question. But you should periodically check the logs for a given machine, and verify this yourself. We don't have enough context centrally to decide wether a given file being locked is a problem to you.
Above all, and after all: TEST YOUR BACKUPS. Every report is a synthetic attempt to answer the question "Can we get it back"? You MUST satisfy yourself about this question. We can help you do it, but the judgement has to reside in your mind.
Is my data offsite?
In general, "yes".
We copy data up to our offsite facility in Atlanta every day. These copies proceed on an incremental basis, similarly to the way backups are prepared. Some of tonight's backups might not be in Atlanta by tomorrow morning, but most of them will, and the remainder will be picked up by a succeeding offsite process.