Professional Documents
Culture Documents
If you have received this message then some or all of your data will NOT have been backed up. Therefore it is
important both to resolve this issue as soon as possible to enable future scheduled backups to run; and also
to perform a manual backup to ensure that your current data is backed up and secure.
The basics
Within the email there will be one or more Nodenames listed. Since each node has its own unique account
name, password and installation of TSM, you will need to repeat this process for each of the nodes listed in
the email.
The email will state for each node whether the scheduled backup was MISSED, FAILED or SEVERED:
For each node, check which status has been given and chose from the following options to continue:
MISSED
FAILED
SEVERED
1. MISSED
You have a node whose scheduled backup is reported to have been MISSED.
Manual backup - If you already know why this scheduled backup was missed and then you may just wish to
run a manual backup.
To troubleshoot why your scheduled backup was missed proceed through the following steps.
In Windows:
In XP/2003, go to Start > ( Settings >) Control Panel > Power Options > Power Schemes (tab), and check
that System standby is set to Never. Then, if your machine is a laptop whose lid you close when you leave
it on for backup, click on Advanced (tab) and under When I close the lid of my portable
computer choose Do nothing.
In Vista/7, go to Start > Control Panel > Power Options > Change when the computer sleeps (tab), and
check that Put the computer to sleep is set to Never. Then click on the arrow to go back to Power
Options and also check that under Choose what the power button does (tab), When I press the power
button is not set to Sleep. On the same screen, if your machine is a laptop whose lid you close when you
leave it on for backup, check that When I close the lid is set to Do nothing.
On a Mac:
If you are running OS X 10.7 (Lion) or 10.8 (Mountain Lion), download the latest client for Mac OS X.
If not, go to System Preferences > Energy Saver and check that the computer (not the display) is set never
to go to sleep.
YES - if the machine was left on and power management is set correctly, proceed to the next step.
Was your machine left connected to the Oxford University network?
NO - if you were not connected to the network then the scheduled backup would not have started. You
must have a physical or VPN network connection to the Oxford University network for the scheduled
backups to run.
YES - if the machine was on and there was a physical connection to the Oxford University network, please
see our page on Checking the Client Scheduler for Windows, Mac, Linux or Solaris machines.
1.4. Summary
You should now have performed enough troubleshooting to ensure that you know why the scheduled backup
was missed and hopefully put corrective measures in place to ensure subsequent scheduled backups are
successful. If you have been unable to determine the likely cause of why the backups are being missed then
please follow the steps below for escalating failed backup reports to gsdsls@trt.com with the appropriate
amount of data.
If you have not already done so, we recommend that you run a manual backup.
To find out when your next scheduled backup is, please see the FAQ item When is my scheduled backup due
to run?.
NOTE:
For ‘Missed’ backups it’s a good idea to check that the scheduler is running on the TSM client. On
windows this is in the services.
In AIX, its run in the background and can be checked via “ps –ef | grep dsm”
2. FAILED
You have a node whose scheduled backup is reported to have FAILED.
A failed backup generally means that TSM was successful in starting a backup but that it was unable to
complete it successfully. Further investigation is required to determine how much of your data was backed
up - it could be some, all, or none of it that got sent to the HFS. Objects on a user's machine that may cause a
schedule to fail include:
Files that are exclusively locked open by another program and cannot be backed up, e.g. database files.
Files that are corrupt, making them unreadable.
Files that are excessively large, causing them to make the network connection time out.
Folder/File structures that breach TSM maximum file length restrictions.
Folder/File structures that create memory issues on the client machine, causing backup to fail.
Another possibility is that TSM is wrongly configured: if it is looking for a file system of partition that does not
exist then such a backup would be deemed a failure - e.g., if TSM is set to back up D: but there is no D: drive
present.
Troubleshooting FAILED scheduled backups
Once dsmsched.log is opened (on which, see below), you will need to search for ANS entries. These are in the
format of ANS####? - where the # represents a number, and the ? represents either
an E (Errors), W (Warnings) or I (Informational). Informational (ANS####I) messages will not indicate the
cause of a scheduled backup failing or being severed; rather, usually the problem is indicated by an error
(ANS####E) message. The relevant message could occur at any time during the failed backup, so it is
important to check what dsmsched.log lists for the whole of the night when the backup failed. The remainder
of this page explains how to view dsmsched.log; and it then lists the most commonly found error messages,
along with their solutions.
Searching tip
Excel users - In the search window you can enter ANS????E to search for Errors or ANS????W to search
for warnings.
Open Office users - In the search window click on the More Options button and tick the Regular
Expressions tick box; then you can search for ANS????E to search for Errors or ANS????W to search for
warnings.
TSM may send most of your data but ultimately report overall scheduled backup failure if other files are left
open. TSM only deems a schedule to have failed if one or more files have been prevented from backup in a
certain way. Not all file failures cause schedule failures but Windows in particular does sometimes lock open
files in such a way that it causes TSM to call a schedule failed when really only a small number of files failed
to get backed up.
In general it is best to try to close all files and programs before a backup runs. To locate the problem, first of
all please check yourdsmerror.log to see if any file failures were caused by one or more files being changed
while TSM was trying to back up. There may be lines like:
Additional information near the end of dsmsched.log will show the total number of failed files. In order to find
the relevant part of text it is usually easiest to go to the end of the document, and then scroll upwards until
you find an end-of-schedule report similar to the following example:
If you cannot close the file(s) that is/are causing the schedule failure before scheduled backup occurs, then
you should exclude them from backup. Files that are continually open, such as database files, would fall into
this latter category. See further our pages on excluding files and folders from backup and backing up open
files with TSM.
2.3.2. 'ANS1071E Invalid domain name entered' or 'ANS1063E The specified path is not
a valid file system or logical volume name' or 'ANS1134E Drive is an invalid drive
specification'
If TSM is configured to back up drives or partitions that it cannot see, then scheduled backups will fail with a
message like one of the following:
ANS1063E The specified path is not a valid file system or logical volume name
Either the error message itself, or a message preceding or following it, will state which drive or partition is
causing the problem.
If your machine is a Mac, then this could be due to a bug with early versions of TSM 6.1 for Mac, which
do not analyze backup domain statements correctly.
One reason for this could be that a folder/directory has been specified as a separate domain. The latter
will cause an error because only drives or partitions may normally be used as domains: hence TSM
cannot find the drive /data/fred and so it deems that the schedule has failed. In this case, /data/fred must
be a folder/directory that is part of the larger partition /data or part of the root partition /.
Alternatively it could be that a drive is listed as part of the backup domain but is no longer present on the
machine. Perhaps the drive has been removed; or perhaps (on Windows machines only) the TSM backup
domain contains references to UNC paths that are no longer valid (e.g. because the machine has been
renamed).
There is a space in the domain name - in this case quotation marks need to be used around the drive
name, because otherwise TSM will assume that you mean several domains. E.g. the above error message
would occur if you wanted to back up the drive /data/fred backup but you specified the incorrect DOMAIN
/data/fred backup instead of the correct DOMAIN "/data/fred backup".
If your machine is a Mac, ensure that you are running TSM 6.1.3 or higher - please check your TSM
version using our instructions under Which version of TSM am I running? - and if necessary upgrade TSM.
If this is not a Mac, or if it is but upgrading does resolve the problem, run TSM (Mac users must use [TSM
Tools for Administrators]) and go [Edit] > [(Client) Preferences] > [Backup] (tab) and correct your backup
domain. If you are running TSM 6.1 or higher, you now need to restart the TSM scheduler: see further
our instructions for Windows, Mac, Linux and Solaris on how to do this.
2.3.3. 'ANS1149E No domain is available for incremental backup. The domain may be
empty or all file systems in the domain are excluded.'
The error message 'ANS1149E No domain is available for incremental backup. The domain may be empty or
all file systems in the domain are excluded' indicates a problem similar to that described in the previous
section: however, rather than the backup domain having been set incorrectly, it has instead not been set at
all. This can be fixed by changing the backup domain so that it includes at least one valid drive or partition. To
do this, see our instructions on excluding drives and partitions from backup; but instead of excluding a drive,
ensure that at least one is included in the backup domain. If you are running TSM 6.1 or higher, you now need
to restart the TSM scheduler: see further our instructions for Windows, Mac, Linux and Solaris on how to do
this.
2.3.4. 'ANS1492S Invalid virtual mountpoint ...: File not found' (Linux/Unix only)
The error message 'ANS1492S Invalid virtual mountpoint ...: File not found' indicates a problem similar to that
described in the previous section. In this case, TSM could not find a directory that has been nominated
in dsm.sys as a virtual mount point. For more information on virtual mount points, see the relevant section of
our page on backing up machines which have high file counts.
To fix the problem, remove the line in dsm.sys or else correct it to point to an existing directory. Then check
for the offending virtual mount point's name in dsm.opt: if your domain is not set to ALL-LOCAL then you will
need to remove or correct it there too. Lastly, stop and restart the TSM scheduler, following the instructions
for restarting the TSM scheduler on Linux or Solaris.
2.3.5. 'ANS1512E Scheduled event ... failed' - but no other ANS warning/error messages
Sometimes TSM may think that the schedule has failed because of a communication problem with the HFS
server. In this case, you will be able to tell from the end of dsmerror.log and dsmsched.log that no files failed
during the backup. For example, you may see a report in the latter file like the following:
01-11-2007 16:27:42 ANS1512E Scheduled event 'WEEKDAILY_ITSERV' failed. Return code =12.
2.3.6. 'ANS1030E The operating system refused a TSM request for memory allocation'
This error can occur because the amount of memory (RAM) which the TSM scheduler uses can grow with
time, until it may reach a point where there is insufficient free memory for scheduled backups to be able to
run. To prevent this, it is recommended that TSM users stop and restart the TSM scheduler periodically:
however, if your machine is rebooted regularly then restarting the scheduler is unlikely to be necessary,
because the service is restarted every time you reboot.
It is possible, though very unusual, that your machine may run out of memory during a backup and then TSM
will cut out. This is most likely to happen on a Mac which is holding a very large number of files (over a
million) on one drive. If your backups on a Mac, both scheduled and manual, cut out without warning, please
see backups fail to complete.
2.3.8. 'ANS4023E Error processing ...: file input/output error' or 'ANS4046E There is an
error processing ... the object is corrupted and unreadable' or 'ANS4047E There is a read
error on .... The file is skipped.'
If TSM is having trouble reading certain files, then it could be because they are corrupted. If this is the case
then you will see error messages in your dsmerror.log about certain files being unreadable by TSM. For
example, they may take the form:
ANS4023E Error processing '/var/log/test.log': file input/output error.
ANS4046E There is an error processing '/var/log/test.log': the object is corrupted and unreadable.
If the fault is only software-related, then the problem can be fixed by checking the disk. Basic steps are as
follows, though you may want to do further research before implementing them.
In Windows, in My Computer, right-click on the offending drive (e.g. C:), and select [Properties] > [Tools].
Then, under 'Error-checking', click on Check Now and tick the box marked 'Automatically fix file system
errors', then Start . Click Yes to the question about running a disk check the next time the computer is
restarted. Any file system errors that are easily fixable will then be fixed on the next reboot.
On a Mac, in Finder, go [Applications] > [Utilities] > [Disk Utility]; then, in the left-hand window, click on
the relevant drive and, in the [First Aid] tab click Verify Disk or, if appropriate, Repair Disk .
In Linux or Solaris, use the command fsck to check your disk - please refer to your system documentation
for the appropriate procedure.
In the worst case scenario, if you have file errors despite trying to fix them, or if you are concerned that your
hard disk may have a fault, please see your local IT for advice.
There is a hard limit on the maximum size of file which you can back up. This limit is the same as the daily
limit in operation for your level of service (see How much data can I back up?). If, while traversing your local
storage, the TSM client finds a candidate file for backup that is larger than this limit, it will issue messages like
those below in both dsmsched.log and dsmerror.log. The backup will continue but the offending file(s) will
not be backed up and will be counted as failed in the summary statistics. Additionally, the scheduled backup
will complete with a return code of 12 and be listed as a 'FAILED' backup.
To remedy this, please exclude the large file(s) from backup using the steps outlined in our page on how to
exclude files, folders and drives from backup.
2.3.10. Windows VSS (Volume Shadow Copy Service) problem causes backup to fail
(Windows servers only)
By default, TSM is set to back up Windows system files (System State) for server accounts. It does this by
using the Windows VSS (Volume Shadow Copy Service). If your Windows server is failing its backups then this
may be caused by a problem related to the interaction of TSM with VSS.
If you find errors reported in dsmerror.log which mention System State or VSS then this is likely to be the
cause of the failed backups. For example:
If you do not need to back up System State data then you can work around this issue by excluding it from
backup. TSM effectively classes System State as a separate drive, meaning that you can exclude it from the
backup domain by using our instructions on how to exclude files, folders and drives from backup.
If you wish to back up System State, check that you have the latest version of TSM for your version of
Windows: recent versions fix certain issues with System State backup. You can download the latest HFS TSM
package from our page on downloading the TSM client for Windows.
If a TSM upgrade does not fix the problem, please proceed to 4. Logging calls with the HFS Team.
2.4. Summary
You should now have performed enough troubleshooting to ensure that you know why the scheduled backup
failed and hopefully put corrective measures in place to ensure subsequent scheduled backups are
successful. If you have been unable to determine the likely cause of why the backups are failing then please
follow the steps below for logging calls with the HFS Team with the appropriate amount of data.
If you have not already done so, we recommend that you run a manual backup.
To find out when your next scheduled backup is, please see the FAQ item When is my scheduled backup due
to run?.
3. SEVERED
You have a node whose scheduled backup is reported to have been SEVERED.
A SEVERED backup generally means a loss of communication between the TSM client on your machine and
the HFS TSM server, whilst the backup was in progress. Possible reasons include:
Intervention at the client (user) end - the user forcibly cancelled the backup/stopped TSM services, or
switched the machine off during the backup.
Intervention at the server end - the backup may have been cut off from the HFS server for exceeding a
daily limit.
Failure (e.g. crashing) of the client machine.
TSM client machine going into sleep mode/state of hibernation.
Several large files causing multiple connection timeouts between the server and client.
Dropped network connection either at the client end, or somewhere on the network between the client
and the server.
Firewall intervention prohibiting/delaying network traffic.
If you are aware of your machine crashing or the backup being forcibly cancelled then you may wish to simply
run a manual backup.
To troubleshoot why your backup was SEVERED please follow the above troubleshooting steps provided for
FAILED backups.
In order to provide effective support for this issue the Shift Lead need all of the following files (for the
appropriate operating system) attached to the email from the client machine affected:
For Windows users we have an automated way of sending us the required files - please see our page on log
file collection for Windows.
Once sent your email will be automatically passed to the HFS Team who will review and advise you of any
further action required.