I need to generate long term retention backups...
How long are we need to keep the data?
If we are in need to keep the data for 10 years or longer, download the manual, save a copy of the OS and TSM/SP Server/Client, TDP, Domino, keep the necessary hardware and create a detail documentation from install, configuring and how to restore the Domino data.
Who knows how long IBM will have the manual on available on the public FTP site.
Do not expect the mirror site to have the information.
FTP site for TSM 7.1 Manuals
FTP site for SP 8.1 Manuals
Save the manual along with the TSM/SP Server (base code), B/A Client , TDP base code, and maintenance code. Also include a copy of the operating system and the HCL Domino.
Keep the hardware that support the OS, TSM/SP application.
Create a document with screen shots from how to install, configure the OS, HCL Domino, TSM/SP Server , B/A and TDP.
Of course detail steps on how to install, configure, and restore the data. Have this on multiple medias. Preferable on WORM media. Basically create a manual for someone, or yourself, to be able to restore the data.
10 years from now the technology will change.
... it is impossible to recover data from a TDP backup from a BackupSet.
The strange thing is that we are able to generate the backupset for the TDP application.
I would expect a message that we are attempting to generate a backupset for data that are backed up via the API. When you attempt a restore, that is when an error message is generated.
... specifically, I need to confirm if for Spectrum Protect version 8.1.8, this limitation is still present (the client I would use to restore the TDP data, would be 7.1.4).
From the manual, in the "new feature" section there is no indication that we can restore TDP data via backupset. Don't trust the manual, if you have a test system, generate a backupset for the TDP Domino and then attempt a restore. If it works and then later problems are encounter, IBM support will inform you that its not a supported process.
The only alternative I can imagine (but without the GUI support) is the EXPORT or generate the BACKUPSET taking the backup with the BA client, with the Domino stopped.
Correct.
Halt the HCL Domino, backup the data via the SP B/A Client.
I would perform the backup via the schedule, so that there are information recorded into the dsmsched.log.
If we issue dsmc incr /path/.../*.* > /path/Domino_backup.out <- We can redirect the out put into a file, there will be no date and time stamp for each message. If there is a problem, how would one match up the message in the dsmerror.log?
I would have the B/A Client within its own domain, in addition to the backup, would perform an archive. Set the archive retention to how long that the data need to be kept. 365 is the default setting for archive.
Reason: Archive does not
rebind like backup.
If someone makes a change with the backup copygroup setting(s), data will get rebound to the new settings. Few years from now, when we need to get the data back. Going to be wondering why we can not restore/retrieve the data, even though the backup/archive completed with success.
Also, to be sure that we are able to get the data, attempt a test restore/retrieve onto a test system at least twice a year. Have someone that is non-technical (or someone that is not familiar with the TSM/SP application) follow your documentation to perform the test.
If they can not perform the restore/retrieve, ask them why and update the documentation.
If error(s) are encounter, document the error message and the solution.
In addition to the backupset, perform an export, and have a copy group.
Also, backup the SP Server database ( db backup and snaphot, I would want to have multiple backup of the database), save a copy of the devconfig.out and the volhist.out
In the dsmserv.opt file can have up to three volhist and devconfig paths.
ie:
volhist /path/volhist.cfg
volhist /network/path/volhist.cfg
volhist /network2/path/volhist.cfg
devonfig /path/devonfig.cfg
devconfig /network/path/devconfig.cfg
devconfig /network2/path/devconfig.cfg
When there is a change in the dsmserv.opt file, the SP Server need to be stop and restarted so that the new update will be read. Would have one local path, two remote path to two different servers in that are in two different locations. And the two remote locations can not be within 5 miles of each other.
Good Luck,
Sias
