How do I get keys to generate my API token?¶
- Login at the BaaS portal, https://portal.cloud.sunet.se/, goto "Backup" and then select "Keys" and press "Create key".
This will get you the access-key and secret-key that can be used to create your access token.
Where can I fetch IBM TSM client software?¶
- See our TSM installation guide
How do I install TBMR (Bare machine recovery for TSM)¶
- See our TBMR installation guide
When will Operating System X version Y be fully supported by TSM?¶
IBMs official stance on the issue is that they will have a working client "within 6 months of the release", but it usually is faster than that.
What ports need to be opened in the firewall?¶
During the installation, platforms with TBMR will want to make a https call to get a license for TBMR, so tcp/443 needs to be open until the installation is done, then during backups and schedule calls, only tcp/1600 outwards. All TSM communication is always initiated by the client to our server, no inbound ports need to be configured, so installation and operations behind NAT are ok.
What known issues are there with the clients and the services on top of TSM?¶
You currently can't take backups of files with dates outside 1970-Jan-1 00:00 and 2105-Feb-07. TSM uses 0 to represent both the date 1970-Jan-1 00:00 but also to mark expired files in the inventory, so files before that have undefined date stamps.
We have a case where TSM up to the release 126.96.36.199 can fail to restore some files on Solaris x86. We have pre-release binaries one can test in case your Solaris box gives you strange errors (ANS4042E, which normally is related to locale settings like en_US and sv_SE) on large restores. Next patch release contains the fixed code for it.
MacOS X 10.11.x needs the TSM release 188.8.131.52 or newer, otherwise the Apple security framework will interfere with the backup client software locations and not allow you to install or use the backup client. If you update your MacOSX and TSM stops working, install the latest release on top of the old one. No need to change anything in the config files or certificate stores. The upgrade will not disturb those files either.
If you forcibly kill the client while doing restore, it will take close to 10 minutes for the server to recognise that the client is not coming back to make a "restartable restore". If you run the client again, it will error out with "Restore already in progress". If the client restore was broken due to network hiccups or similar in-transit issues, it will restart by itself from where it left off as long as the issue is resolved within 10 minutes. If you forcibly kill the client, it will forget that it had a session running and you will have to wait until 10 minutes pass before being able to start a new full restore. "dsmc cancel restore" may or may not speed up this timeout.
There is a known issue with the local deduplication cache if you run exactly Linux kernel 2.6.32 and TSM client version 184.108.40.206. If you have this combination, either upgrade the client (preferred, this is verified to help as a single action), or increase the DEDUPCACHESIZE in dsm.sys (which may workaround the problem).
The 220.127.116.11 TSM client (not 18.104.22.168 or later) will fail if you have 1400+ directories in a single directory. The error will be something like this: "ANS6718E The path contains too many nested subdirectories. The maximum number of nested directories is 1400". The solution is to either upgrade to 22.214.171.124 or later, or edit the dsm.opt to include this line: "TESTFLAGS threadstacksize:2048" if you can't upgrade.