Please review the follow the instructions for registering for the backup service.
Oxford University backup services are available to all University staff, senior members and postgraduates. You will need to have a operating system that is currently supported and direct access to the university network.
No, IT Services do not have the resources to supply this service to all students. There may be a local service that is provided by your college or department: please speak to your local IT Support Team for further information.
- Desktop/laptop accounts represent the most common type of backup account. They should ideally be accessed via a direct connection to the university network, although it is also possible to do so via eduroam wireless or using VPN. Unless you have chosen otherwise when you registered your account (usually because you will only be backing up over VPN), there are automatic weekly backups one night per week, but it is not necessary to use these: you can also run a manual backup at any time. Choose this type of account if your machine is regularly connected to the Oxford network, either just in term-time or throughout the year, and then you will able to back up in university departments, colleges and libraries.
- Server accounts are intended for departmental and college servers which themselves provide services, software and/or storage space for other systems. You need to be IT Support Staff to register this type, so if that is not the case then ask your IT to register it for you, with your e-mail address as the contact for the account. The daily limit is higher than that for desktop/laptop accounts, and automatic scheduled backups run six days a week (every weekday and once at weekends). Before registering for this type of account, please also read our page on server node registration requirements.
- Large server
- Large server accounts are intended for machines that provide services and which have over 1.5TB to back up on their first backup and which may regularly experience daily incremental data change rates greater than 300GB. These figures are guidelines only and potential users of this service, who again must be IT staff, are asked to register an interest in this service on the registration pages. Registration for this service is thus not automatic. The daily limit is higher than that for server accounts, and again automatic scheduled backups run six days a week. Before registering for this type of account, please also read our page on server node registration requirements.
- Archive accounts are for the long-term storage of data which is considered to be of value to the university. Potential users of this service are asked to register an interest in this service via a web form - please see further our pages on the HFS archive service.
All accounts are available for backup and restore 24/7. For the limits on how much data you can send for the different accounts please see 9.11. How much data can I back up?.
Please note that it is possible for us to change one account type into another but that the process is not simple. If you register for the wrong type of account please do not de-register and then re-register, as this will schedule both your old and new accounts for deletion - instead please contact the HFS Team on firstname.lastname@example.org.
Maintaining support for legacy and diverse operating systems is time-consuming. Therefore IT Services no longer register nodes using Windows 2000 or earlier - some existing installations will continue to be supported if the machines cannot be upgraded to a later OS but these will be done on an individually agreed basis.
The answer to this question depends on whether you are IT Support Staff: please see further our page on TSM account management.
If you cannot download the TSM software, please verify that you were either directly connected to the Oxford University network, or connected via VPN, when you tried to download. TSM can only be downloaded, installed and run on machines that are within the physical Oxford University network or connected via VPN.
Maintaining operating system support for legacy and diverse OSes is time-consuming. Therefore IT Services no longer register nodes using Windows 2000 or earlier - some existing installations will continue to be supported if the machines cannot be upgraded to a later OS but these will be done on an individually agreed basis.
It is not practical for us always to be using the latest client software, and new versions often prove to have minor bugs. Also, unless there is a genuine reason to upgrade the client software we may not force clients to upgrade.
There are built-in checks during the installation that should prevent you from installing the wrong client software onto your machine - even if the wrong version were installed, the worst-case scenario is that the TSM Client would not work until the correct version were installed.
If your nodename and password combination aren't accepted, visit the Self Registration Page to double-check your registered nodename and to reset your password if necessary.
To upgrade TSM, you only need to install the latest version that is available for your operating system. Just install the new software as documented via the client-specific instructions linked from the clients page.
With the exception of Mac OS X 10.4.7+, only versions of these operating systems that can run TSM 5.5 or higher are supported. For a list of these supported versions, and instructions on how to download and install TSM on them, please see our clients page.
If you are running Mac OS X but unsure which exact version it is, you can check by clicking on
the Apple icon at the top left of your screen and selecting
[About This Mac] from the menu; the version of Mac OS X installed on your machine will be listed in
If you are not running any of the operating systems listed above, then you can still reconfigure your old version of TSM to make it secure - please see our page on bypassing the security vulnerability.
Please note that upgrading may not carry over any edits to the Domain option in your client configuration. If you have made edits to this, you will have to reapply them - please see our FAQ item ??. Windows users should also check their Exclude statements too, if they have edited them in the past - see further FAQ ?? and in general FAQ ??.
If you experience problems whilst updating the software, please look at our FAQ section on Installing TSM to see if there is a solution there.
This could be due to a number of reasons but is normally because the client has been de registered and then re registered by the owner. In order to ensure stability and availability of our services the Backups are spread across a number of servers. Therefore, when clients register they may not be placed on the same server - this is certainly the case if registrations are not at the same time even if it is for the same machine.
- The client has not communicated with the servers for a long period of time and have been removed from the servers and therefore forcing the client to be re registered. See FAQ
- An old
dsm.optwas already on the client and detected and used during the installation process
On this subject please see further our page on connecting to the HFS through a firewall.
You will need a TSM client for each operating system. Register separately for each of your two (or three) operating systems for HFS TSM Backup via the registration pages. This will give you TSM Client nodenames of the form username-text-department/college, e.g. abcd1234-windows-exeter and abcd1234-linux-exeter. You should then obtain and install the latest TSM Client software for each operating system, from the Getting Started link from the front page of the HFS web pages.
Please make sure to exclude each operating system's files from the other, so that e.g. your Windows partition does not back up your Linux files or vice versa, to ensure that the HFS does not receive your data twice. For instructions on this please see how to exclude files and folders from backup.
Please also note that TSM does not support cross-platform backup/restores, meaning that you should not attempt to back up data from two different operating systems in one account, nor to restore data backed up by one operating system to another.
TSM client passwords expire 372 days after being set. It is generally good security practice to change passwords regularly and this setting forces users to change their password at least once a year. It also provides a limited safeguard to backups of machines made by users who then leave.
However, by default, you will have the
PasswordAccess option in your TSM options file
Generate. In this case, the client and server will autonegotiate a new
and store it in encrypted form on the local client disk and you, the user, do
not have to do anything.
You can reset your TSM password by going to the Self Registration Page. On identifying yourself with your Oxford username you can choose the option to reset your TSM password(s). The change will take effect immediately.
The TSM password has a maximum length of 63 characters and is case-insensitive.
Valid characters are
[a-zA-Z0-9+.-_&] i.e. any
letter a-z upper or lower case, any number 0-9, plus, period, underscore, hyphen,
If, on starting the TSM client, you are prompted that your password has expired, or on inputting your password you receive a message 'Authentication failure' or 'ANS1051E: Invalid password', then you will need to reset your TSM password.
For how to do this please see the previous section, 4.2. How do I change my TSM password?.
Manual backups can be completed at any time to capture important changed data - between scheduled backups, after missing scheduled backups or even as an alternative to scheduled backups (ideal for laptop users who are unable to leave their machines on overnight for the scheduled backups).
Go to the Self Registration Page, select the node you wish to view the schedule for and select View client information from the drop-down box. The backup schedule associated with this client is provided in the on-screen information.
Go to the Self Registration Page, select the node you wish to view the schedule for and select Show client's recent activity from the drop-down box. The recent activity will be displayed for backups: look for activities labelled "BACKUP" and you will be able to see the start and end times and the amount of data in megabytes that was backed up.
The folders and files marked with barred red circles are excluded from backup and will not be backed up. The specific exclusions have been written for a number of reasons, the main one being that the backups are intended to be used for individual data and not for installation directories or system data, e.g. the Windows directory or Program Files.
It is possible to remove the exclusion and include a file or folder in your backup if the exclusion is performed on the client side. However, some exclusions are forced at a server level which will override any settings changed locally - please see Which files are omitted from backups which will go into the exclusions in more detail.
It is possible to change the time that your scheduled backup is set to, but not the day. Each college and department is allocated one night a week on which all its backup accounts have their schedule slots.
If your machine is not normally switched on at the time when your scheduled backup occurs, but it is left connected to the Oxford network, then you can configure it to switch on and off automatically for the backups (see 6.2. Do I need to leave my computer on all night in order to back up?). If this is not convenient then you can run a manual backup at any time: on how to do this, please see our instructions for Windows, Mac, Linux and Solaris.
However, it is possible to change the time of your backup, albeit within a limited number of slots during the evening and/or night (morning and afternoon slots are not possible). Please contact email@example.com if you would like the time of your scheduled backup changed.
No, that is not necessary. There are two alternatives to leaving your machine switched on. It can be configured to wake up at a specific time for the backup schedule to run, and also to shut off again when the backup has completed: please see further our page on setting a machine to switch on and off for scheduled backups. Alternatively, you can run a manual backup at any time: on how to do this, please see our instructions for Windows, Mac, Linux and Solaris.
Go to the IT Services Self-Registration page which gives
TSM client information
and select your TSM node to see your
Go to the IT Services Self-Registration page concerning
TSM scheduled backups
and select your TSM node to see your
scheduled start time. Please note that this time is not decided until the day after you register your TSM node.
6.4. How can I stop receiving the "TSM Scheduled Backup failure report" when I only back up manually?
You can't! The messages are generated as a batch for all TSM clients. As the message states, you can ignore this message if you only perform manual backups, or use it as an aide-de-memoire to run a manual backup on receipt of such a message.
- Your machine is never connected to the university network when the overnight schedules run, and so you do not need a scheduler running.
- You are running a series of initial manual backups in order to send a full copy of your data to the HFS, before later moving on to use the scheduled ones.
- You lost data and have as yet to restore it with TSM: in this case you should switch off TSM services to ensure that no further automatic backups run before or during your restore.
This means that a scheduled backup for a node registered to your email address has not completed. To resolve the issue or to understand why this happened please follow the Scheduled Backup Troubleshooting guide to resolve the issue.
If your scheduled backup does not run or failed to complete you will receive an automated email notification, indication whether a particular node MISSED the schedule, FAILED to backup or was SEVERED. Definitions for each of these can be found below:
- This means that the scheduled backup has not ran at all, it did not begin. There are a number of reasons this may have happened, please follow the Scheduled backup troubleshooting guide to resolve the issue. Example of why a scheduled backup may have not run are; Machine not being left on, machine not having physical connection to the Oxford University network.
- This means that the scheduled backup has started, but something has caused the backup to fail. There are a number of reasons this may have happened, please follow the Scheduled Backup Troubleshooting guide to resolve the issue. Examples of why a scheduled backup may have failed are: files skipped as they were in use by another application, files were explicitly locked, files could not be read due to hard disk error or file corruption
- This means that the scheduled backup has started, but something has caused the backup to fail or become disconnected. There are a number of reasons this may have happened, please follow the Scheduled Backup Troubleshooting guide to resolve the issue. Examples of why a scheduled backup may cause a SEVERED error are: network communication error, lack of memory causing connection or application to fail.
If you do not have the original machine, then please see our FAQ item 7.3. My machine has crashed - can I perform a system restore?.
The usual reason that files are not visible in the restore window
is that they are inactive; the default is for TSM only to show active files. For an explanation of active/inactive files, see
7.5. What are active and inactive files?. To view both active and inactive files, click on
[View] and then chose
[View Active/Inactive Files]: this should fix the problem.
If viewing inactive files does not help, and your machine is a Mac, please see our knowledgebase article KBMAC0003 - Files expected to be available for restore by TSM for Mac are not listed.
In the case of desktops and laptops, the backup service provided by IT Services is intended to provide data backups, not system backup and recovery: you should rebuild your system using original media and then install the TSM software to recover your data back onto your machine. For more details, please read our page on how to recover your entire system.
In Windows, if your machine has crashed and you are restoring data to a new machine, or if you have upgraded your machine and you are restoring data to a new machine, then you must specify an alternative location to which to restore. This is because when you restore to the original location the TSM client uses the UNC path which will contain the name of the old computer and not the new one. The old UNC path includes the name of the old machine: so unless your old and new your two Windows machines have identical names, the data restore would fail.
- If a file has been backed up previously and therefore exists on the TSM Backup Servers but is then deleted from the live environment, when the next backup runs (manual or scheduled) the file on the TSM Servers is marked as inactive - because it has no live equivalent
- If a file has been backed up previously and therefore exists on the TSM Backup Service but the file is then updated in the live environment,
when the next backup runs (manual or scheduled) the original file on the TSM Server is marked as inactive and the updated version of the file is added to the backup servers and becomes the active
backup of this file
- TSM only keeps one Version document as inactive and one live copy as active, i.e. a subsequent update to the file would see the current inactive file be deleted, the active file become inactive and a new copy of the updated file as the active version
- For as long as there is an Active file, the TSM Servers will continue to hold an Inactive Version
Can I use "Point in Time" restores? - Within Oxford University Point in Time restores are of little use as our policies are set to only store two copies of any given file - one active, and the previous version as inactive. For best results set the restore to view both active and inactive before following the normal instructions for restoring files and folders.
For more information on Point in Time restores please email the HFS Team
If you are leaving the university then we request that deregister your TSM nodes, to ensure that our systems work as effectively and efficiently as possible. If you do not deregister your node then our systems will notice that the node is not contacting our servers and will automatically send out various email notifications (missed backup notices and data deletion warnings) which results in significant administrative work on the part the HFS Team to determine whether the node is still present, and also in attempts made to contact the owner. Thus much work is prevented if you advise us that you are, or your machine is, leaving the university.
- There is a licensing implication: TSM licences are arranged for Oxford University members, and so the licence that you use is linked with your association with the university. When you leave, the license is no longer valid.
- Some older versions of TSM are subject to security vulnerabilities, and new vulnerabilities are occasionally discovered also. So, leaving TSM on your machine is a possible security risk - it is best uninstalled.
- Installations of TSM left installed will continue to try to contact the HFS servers if the TSM scheduler is left running (which is the case by default). Deregistered TSM installations try to contact the HFS dozens or even hundreds of times a day looking for the deleted TSM account, unnecessarily using up limited HFS resources.
msi.log. To find the directory where these files are located in Windows, do as follows:
Windows users can find the files via
My Computer. Additionally, there is an automated way of sending us the required files - please see our page on
log file collection for Windows.
Mac users can find the files via
Finder but may need to run
[Go to Folder...] and type or paste in the above-mentioned folder
name in order to locate the files. Please also note that the configuration files are in
/Library/Preferences/Tivoli Storage Manager, not
the (always empty) folder
/Users/<your-username>/Library/Preferences/Tivoli Storage Manager.
Backup is intended to provide a mechanism for securing your current, active files: that is files and data that are resident on your local disk and by implication actively in use. It enables you to recover your disk to its most current state in the event that it is lost (for example, hardware failure); it also enables you to recover a file or files that have been lost (for example, accidentally deleted).
Archive is for the long-term storage of data which is considered to be of value to the university. It is held independent of any files' continued existence on your local disk. Archived files may be removed from the local disk on your computer if required (for example, for space reasons).
Yes. The HFS supports VPN-based backup for systems that are registered for the desktop backup service. This allows the backup and restore of important University data from anywhere in the world using connections via the University's VPN service: please see further our page on VPN-based backups.
The reason for this is because the original deleted node was probably registered to a different server than the newly registered node. To resolve follow the instructions on removing and reinstalling the TSM Client.
Further Explanation: In order to spread the load of new registrations, the HFS team change the server on which new TSM nodes are registered. [Odd numbered HFS servers (OX_HFS_B1, OX_HFS_B3, OX_HFS_B5, OX_HFS_B7) are for desktops; even-numbered (OX_HFS_B2, OX_HFS_B4, OX_HFS_B6, OX_HFS_B8, OX_HFS_B10) are for servers.] One user may therefore have accounts spread over several different HFS servers. If a user de-registers an old account from, say, B3, and re-registers, then the new account may come out on, say, B7, if that is where new registrations go. When he/she tries to install, the TSM installer will pick up on all the old settings it finds in dsm.sys/dsm.opt and will try to contact only B3. But, as the user says in their question, we deleted that old B3 account, so the installer finds no account there. So the B7 account will be ignored by the installer and the user can’t run TSM.
Your TSM backup is unlikely to be affected if your machine is moved, even if it moves to a different part of the university network. However, if it is renamed and it is also running Windows, then it is likely that it will resend all its data, which may cause your account to be locked. Please see further our page on renaming TSM nodes.
For a discussion of the various aspects of this subject, please see our page on TSM security.
Filespaces within TSM are typically subsections of nodes that have previously been backed up. For example a node (desktop, laptop or server) may have several physical or logical disks contained with them - these would locally be seen to as c:\, d:\, e:\ etc. As the TSM Backup is required to run with some administrative privileges it backs up the data using Administrative shares that access directly into the root of each drive letter whilst using the UNC for the client, these are generally seen as \\testpc\c$, \\testpc\d$, \\testpc\e$, etc.
If you are using the Graphical User Interface (GUI) click on
About TSM. The screen will display the relevant information, such as Version 6, Release 4, Level 0.0. Click the screen to close it and return to the TSM hub window.
On a Mac, you can alternatively select
[Tivoli Storage Manager]>
[About Tivoli Storage Manager]from next to the Apple logo (i.e. at the top left corner of the screen). Please note that this does not always give correct results: if you do this after having run TSM Tools for Administrators (which is the recommended method of running TSM on a Mac) then you will be told that you have TSM 1.0; if you do not run TSM via TSM Tools for Administrators, then TSM 6.3 and 6.4 will mis-report that you are running TSM 6.2.
- If you are using the Command Line Interface (CLI) you should, on starting the client see the Version, Release and Level displayed above the tsm> prompt.
There are several ways to check that your backup was successful, whether you only back up manually, only use the automatic schedules, or both. Please see further our page on how to check that backups ran successfully.
|Backup Session Duration||10 Hours|
|Transfer Speed||Average of 10KB/sec over 2 hours|
|Maximum File Size||Same as Daily Limit (below)|
The HFS limits data uploads by imposing a daily quota. If you exceed this amount then your account will be locked out - this is necessary in order to ensure fair use of the HFS. The limits are as follows:
The total data backed up by a node in a 24 hour period is not allowed to exceed the daily backup quota. That 24 hour period is linked to the operation of the HFS service but typically starts in the early hours of the morning.
If you exceed the daily transfer limit then you will receive a mail headed "HFS backup cancellation report": if this occurs please see our section on HFS backup cancellation reports.
If you need to send more than the daily limit then you can stage your backups by limiting the amount that you send each day. If you need to do this, please see the FAQ item 9.12. How can I limit the amount of data that I'm backing up?.
Unfortunately we cannot accept more than the daily limit for each account. This is because of the way in which newly-received data is processed: it would delay our daily processes the next day if we were to receive an excessively large amount for a single account.
- Start a manual backup, using the appropriate instructions from our section on Using TSM Backup & Restore on your client platform.
- In the Task List window, click on
Report; this opens a Backup Report window that shows the running total (listed as
- When the total is approaching the limit, close the
Backup Report window and click on
Stopin the Task List window.
TSM will inspect your local hard drive(s) and any locally-attached external drives and by default will back up all the files that it finds there. However, for a variety of reasons, some files are excluded from backup. A list of excluded files can be found on the HFS Policy Pages.
The HFS keeps up to two copies of any one file that is backed up. For information on how long files are held for, please see section 9.18. How long do you keep data for?.
- New Files
- New files are backed up during the incremental backup and added to the backup set.
- Changed Files
- If a file that has been backed up once is then modified, then the original file is retained in the backup but marked as inactive, and the modified version is backed up and marked as active; only the currently version and the previous version are retained in the backup.
- Deleted Files
- If a file that has been backed up once is then deleted from your file system, then the file is flagged as inactive during the backup process. This file will still be held in the backup dataset for 90 days, at which point it will be removed and no longer be available to restore.
If you do not back up for four weeks then you will receive a warning mail headed 'Old data on the HFS'. Another will be sent after ten weeks of inactivity, warning you that your data will be deleted in four weeks' time. After that point, if we have received no response, then the filespaces/accounts listed in the second e-mail will be deleted. More information about these mails is to be found in our pages on Standard TSM emails: old data on the HFS and deletion policy.
Perhaps, however, you are unable to run a backup because e.g. you are out of Oxford or away on leave. If that is the case and you cannot run a backup for more than two months, please contact firstname.lastname@example.org and let us know the reason, and also the date when you will be able to back up again. We will then put your data on hold until that date.
Generally, the HFS service is available 24/7. However, as with all systems there is from time to time a requirement to update the software and device firmware that underpins the service. Where this requires limiting access to some or all elements of the HFS Service, such interruptions will be advertised to the itss-announce maillist and on the IT Services Status Page, where real-time availability of all IT services can be checked.
The answer to this question falls into two parts. Data that has been backed up to the HFS is, if it still exists on the local disk, retained as long as the drive/partition that sent it continues to back up to the HFS. Data from drives that have ceased backing up for 90 days is subject to deletion, in accordance with our deletion policy; up to three warning e-mails are sent before such deletion occurs.
- Desktop/laptop backup policy
- Server backup policy
All data covered by the Nexus groupware solution - including e-mail, calendars and SharePoint data - is backed up automatically to the HFS, directly from the Nexus servers. There is therefore no need for Nexus users to back up such data using TSM.
For details on the backup and restore of data held on Nexus, see the Nexus (Exchange) service level description.