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.
If you are IT Support Staff, or are an advanced user and are confident reviewing and interpreting log files,
then please follow the suggestions below. You will need to open the file
dsmsched.log, whose location
on your machine is listed in table 1.
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
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.
- Browse to the appropriate location and open
- Once the log is open (this may take a while if it is large), scroll to the bottom of the log file: this is where the most recent information will be.
- Depending on your operating system, you now need to search through the log file. In Windows, select
CTRL+F) to bring up the search box.
- In the search box type
ANS, then select up and click
- Look for ANS entries that end in either an E or a W.
- Open your spreadsheet package.
- Click on
- In the box provided change Files of Type to be
- In the Look in: section browse to the appropriate location and then open
- Generally a box will appear giving you various import options - leave the defaults and select
- The log file will open, with each time-stamped entry from the log appearing on a separate line.
- Once there, select
CTRL+F) to bring up the search box.
- In the search box type
ANS, then select up and click
- Look for ANS entries that end in either an E or an W.
- 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 Optionsbutton 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.
For each ANS####E or ANS####W you need to review the text which follows the error code to determine whether this could have been a cause of the scheduled backup failure. You will most likely find the message "ANS1512E Scheduled event ... failed" and at least one other message as well. Examples of common messages that cause scheduled backup failures are listed below.
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, therefore, it is best to close all files and
programs before a backup runs. To locate the problem, first of all please check your
dsmerror.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:
30-01-2008 00:25:28 ANS1228E Sending of object '/var/log/test.log' failed 30-01-2008 00:25:28 ANS4037E Object '/var/log/test.log' changed during processing. Object skipped. 30-01-2008 00:25:31 ANS1802E Incremental backup of '/' finished with 1 failureAdditional information near the end of
dsmsched.logwill 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:
30-01-2008 00:26:04 --- SCHEDULEREC STATUS BEGIN 30-01-2008 00:26:04 Total number of objects inspected: 214,391 30-01-2008 00:26:04 Total number of objects backed up: 16 30-01-2008 00:26:04 Total number of objects updated: 0 30-01-2008 00:26:04 Total number of objects rebound: 0 30-01-2008 00:26:04 Total number of objects deleted: 0 30-01-2008 00:26:04 Total number of objects expired: 0 30-01-2008 00:26:04 Total number of objects failed: 1 30-01-2008 00:26:04 Total number of bytes transferred: 70.20 MB 30-01-2008 00:26:04 Data transfer time: 5.07 sec 30-01-2008 00:26:04 Network data transfer rate: 14,151.96 KB/sec 30-01-2008 00:26:04 Aggregate data transfer rate: 588.20 KB/sec 30-01-2008 00:26:04 Objects compressed by: 0% 30-01-2008 00:26:04 Elapsed processing time: 00:02:02 30-01-2008 00:26:04 --- SCHEDULEREC STATUS END 30-01-2008 00:26:04 --- SCHEDULEREC OBJECT END WEEKDAILY_OUCS 30-01-2008 00:00:00 30-01-2008 00:26:04 ANS1512E Scheduled event 'WEEKDAILY_OUCS' failed. Return code =12. 30-01-2008 00:26:04 Sending results for scheduled event 'WEEKDAILY_OUCS'. 30-01-2008 00:26:04 Results sent to server for scheduled event 'WEEKDAILY_OUCS'.
Note, however, that it is quite normal for a few files to fail to get backed up. If you find that the files that failed also failed on days when the schedule completed successfully, then those file failures are very unlikely to be what caused the schedule to fail as a whole.
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 log files and 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'
ANS1071E Invalid domain name entered: '/data/fred'
ANS1063E The specified path is not a valid file system or logical volume name
ANS1134E Drive is an invalid drive specification
- 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 analyse backup domain statements correctly.
- The listed domain entry does not exist as a drive or partition:
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/fredand so it deems that the schedule has failed. In this case,
/data/fredmust be a folder/directory that is part of the larger partition
/dataor 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).
- 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
- 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 backupbut you specified the incorrect
DOMAIN /data/fred backupinstead 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
[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 and Linux/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 and Linux/Solaris on how to do this.
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
or else correct it to point to an existing directory. Then check for the offending virtual mount point's
dsm.opt: if your domain is not set to
then you will need to remove or correct it there too. Lastly,
stop and restart the TSM scheduler, following the instructions for
setting up automatic backups on Linux.
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
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 --- SCHEDULEREC STATUS BEGIN 01-11-2007 16:27:42 Total number of objects inspected: 31,029 01-11-2007 16:27:42 Total number of objects backed up: 62 01-11-2007 16:27:42 Total number of objects updated: 0 01-11-2007 16:27:42 Total number of objects rebound: 0 01-11-2007 16:27:42 Total number of objects deleted: 0 01-11-2007 16:27:42 Total number of objects expired: 0 01-11-2007 16:27:42 Total number of objects failed: 0 01-11-2007 16:27:42 Total number of bytes transferred: 52.47 MB 01-11-2007 16:27:42 Data transfer time: 106.71 sec 01-11-2007 16:27:42 Network data transfer rate: 503.49 KB/sec 01-11-2007 16:27:42 Aggregate data transfer rate: 219.49 KB/sec 01-11-2007 16:27:42 Objects compressed by: 0% 01-11-2007 16:27:42 Elapsed processing time: 00:04:04 01-11-2007 16:27:42 --- SCHEDULEREC STATUS END 01-11-2007 16:27:42 --- SCHEDULEREC OBJECT END WEEKDAILY_OUCS 10-01-2008 10:00:00 01-11-2007 16:27:42 ANS1512E Scheduled event 'WEEKDAILY_OUCS' failed. Return code =12. 01-11-2007 16:27:42 Sending results for scheduled event 'WEEKDAILY_OUCS'. 01-11-2007 16:27:42 Results sent to server for scheduled event 'WEEKDAILY_OUCS'.In this case, TSM has inspected 31,029 files and has backed up 62 of them. The number of failed files is zero. The TSM client has experienced an error when signing-off from the server and has recorded this as a failure. However, it is clear that the scheduled backup itself has completed and the failure message can be ignored.
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.
ANS4047E There is a read error on '/var/log/test.log'. The file is skipped.
- In Windows, in My Computer, right-click on the offending drive (e.g. C:), and select
[Tools]. Then, under 'Error-checking', click on
Check Nowand tick the box marked 'Automatically fix file system errors', then
Yesto 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
[Disk Utility]; then, in the left-hand window, click on the relevant drive and, in the
[First Aid]tab click
Verify Diskor, if appropriate,
- In Unix/Linux, use the command
fsckto check your disk - please refer to your system documentation for the appropriate procedure.
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.
ANS1228E Sending of object '/home/xyz/Downloads/image.tar.gz' failed
ANS1310E Object too large for server limits
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:
20-11-2013 20:28:42 ANS5250E An unexpected error was encountered. TSM function name : baProcessRequest TSM function : VSS Create Local Backup failed TSM return code : 1 TSM file : incrdrv.cpp (6866)
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.
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?.