My though was to have the backupset go to a storage pool and then I would copy it to a copy pool. Can I assign a backupset to a storage pool? Thanks in advance. Hi Nice question. Never think about backupsets before so i have to read some books about. A backupset is an independent copy of your data you can restore without the need of the TSM database server installed.
Diference between backupset and archive is that you need a copy of the TSM database, so you need to create the TSM db off. Hope this helps. Backupsets are created from yet done backups. Backupsets are a kind of export : You need to put some written words on the cartridge you will put offsite. Given your requirement to have a copy offline, you should have not implemented container pools OR obtain a tape library to perform a protect stgpool to tape.
With your current config, your hands are tied, you cannot have an offline copy. Oh, I got an idea. Keep your primary as-is. Configure a target for replication, on the target you use a file dedup pool instead of a container pool. From the target, you will be able to to exports and backupsets from the filepool. You must log in or register to reply here. Advertise at ADSM. ORG If you are reading this, so are your potential customer. ORG right now.
Sign-up here:. Votes: 20 Votes: 65 Let's be formal and just say Spectrum Protect Votes: 13 Other please comement Votes: 9 8. See comments…. In a disaster restore situation, you will normally restore the system files from an image backup or through normal OS installation. You CAN do this using a backupset, but if you want to restore only part of a backupset, you will have to run the complete retrieval process for each desired filesystem.
Each invokation of "restore backupset" can only hold one filespec and will require a full read of the entire backupset, even though you are restoring only a few Mbytes.
It may take several hours to run through a large backupset, so if you have to do this 10 times, because you want to restore 10 different filesystems, the time involved may be just too much! There are two solutions to this : 1.
When you generate the backupset, specify all the desired filesystems on the "generate backupset" command. This way you only get the filesystems you want and can restore them all in one restore pass.
BUT, it requires a lot of discipline to maintain the "generate backupset" commands. Whenever a server has a new filesystem added to it, you must go into your script or wherever you keep the generate command, and update it.
Can you be sure that you are always notified about the new filesystems added to your servers and can you be sure that the backupsets will really contain ALL the filesystems needed for disaster recovery? Logically split each server that you backup into two nodes.
Backup all the system files using one nodename nodeA and backup all other data using another nodename nodeB. The backupset will then contain all non-system files and can be restored in one pass. What can be done to improve the usability of backupsets?
Each backupset occupies a full volume. This way each backupset is considered an archive file on the target server and multiple backupsets can be stored on each physical volume. This requires the DRM feature, but could be an excellent solution if Tivoli made a few improvements. See appendix A for an example of how to do this.
Scheduling the generation of backupsets.
0コメント