-
-
Community Tip: Forum Rules (PLEASE CLICK HERE TO READ BEFORE POSTING)
Click the link above to access ADSM.ORG Acceptable Use Policy and forum rules which should be observed when using this website. Violators may be banned from this website. This notice will disappear after you have made at least 3 posts.
Yearly Backup
- Thread starter Quake
- Start date
Yearly Backups
Hello,
I need a solution for a yearly Backup. We must archive every year one full backup.
Backupsets are ok but I can not restore SQL or Exchange DB.
Any concept?
Thanks
Hello,
I need a solution for a yearly Backup. We must archive every year one full backup.
Backupsets are ok but I can not restore SQL or Exchange DB.
Any concept?
Thanks
Last edited by a moderator:
JohanW
ADSM.ORG Moderator
Export node.
Keep a db backup and install media of appropriate TSM server version as well, I suppose.
Keep a db backup and install media of appropriate TSM server version as well, I suppose.
heada
ADSM.ORG Moderator
Archives are a good solution to this type of problem but you'll have to create the archive from the client and not from the server like a backupset. This can take time and could cause your TSM DB to grow depending on the number of objects.
-Aaron
-Aaron
heada
ADSM.ORG Moderator
You could perform an archive as well. Archives are like backupsets but they're managed within the TSM database. They're also taken from the client's live data and not from the data within the TSM server. They're kept for a pre-determined period of time.
For a snapshot of a system that has to be kept for a longer period of time, I use archives.
-Aaron
For a snapshot of a system that has to be kept for a longer period of time, I use archives.
-Aaron
BBB
ADSM.ORG Moderator
You can use exports for TDP data. They're quite similar to a backupset for the purpose of a yearly backup and would suit your purpose. You just need to import the backup tape on another TSM server before trying to use it (or mess around renaming nodenames before and after the import).
BBB
ADSM.ORG Moderator
No you only need the export node, and the TSM software. You do not need to restore the db or keep a db backup tape. If you need to restore, you'll need to install tsm, setup a mostly blank db, and import the export into the db.
Thanks for your answer's.
Export Node: I have only one production TSM Server. How restore a export node on this? I can not install a blank DB!
But I have read that this solution excluded NAS Filers. We have a Filer with 6 TB
Is there no way to make a normal full backup of all node and after this I take the tapes offline. In the event of a restore I add the tapes to the Library and restore the content?
Export Node: I have only one production TSM Server. How restore a export node on this? I can not install a blank DB!
But I have read that this solution excluded NAS Filers. We have a Filer with 6 TB
Is there no way to make a normal full backup of all node and after this I take the tapes offline. In the event of a restore I add the tapes to the Library and restore the content?
Last edited:
JohanW
ADSM.ORG Moderator
Export data is not guaranteed to be importable in different versions of TSM. That's why you should keep the install version. You don't need the database, you can just import it, I was wrong there.
If you have a compatible version of TSM still running, you can import into that, but if you upgraded and the new version won't import the old data, you'll need a temporary server. You can install a blank db on that one. (It'll come with one even!)
Yes, you can checkout the tapes, but the data will be subject to expiration, possibly reclamation, and you'll need to move the data onto its own tapes by hand.
Archives put quite a strain on your database for stuff that's (almost) never used.
To me, it sounded like it would be most convenient to take the data out of your current TSM environment. But that way, you're not entirely futureproof for restores.
Choices, choices .. you'll have to weigh the costs and benefits for you.
(I think it's a **** shame you can't generate backupsets with TDP data, but it can't be helped. You might dump flatfiles?)
If you have a compatible version of TSM still running, you can import into that, but if you upgraded and the new version won't import the old data, you'll need a temporary server. You can install a blank db on that one. (It'll come with one even!)
Yes, you can checkout the tapes, but the data will be subject to expiration, possibly reclamation, and you'll need to move the data onto its own tapes by hand.
Archives put quite a strain on your database for stuff that's (almost) never used.
To me, it sounded like it would be most convenient to take the data out of your current TSM environment. But that way, you're not entirely futureproof for restores.
Choices, choices .. you'll have to weigh the costs and benefits for you.
(I think it's a **** shame you can't generate backupsets with TDP data, but it can't be helped. You might dump flatfiles?)
BBB
ADSM.ORG Moderator
As discussed on your other post (don't double post), you don't have to have a second tsm server. You can setup a second small DB on the same server, or you can even import into your original server, as long as you rename the original node first so it doesn't try to merge them.
djchopps0013
ADSM.ORG Senior Member
Or solution was to create another domain with the retention of 3650 days and use absolute mode that way it would contain full TDP data backups and baclient data and then we send those off once a month.
sebastian
ADSM.ORG Member
2 Questions:
- Do I have to concern about expiration on an exported node (on a tape) ?
- " retention ... and absoute mode" what does the mode mean ?
- Do I have to concern about expiration on an exported node (on a tape) ?
- " retention ... and absoute mode" what does the mode mean ?
djchopps0013
ADSM.ORG Senior Member
When you define a new copy group or update a current copy group you can change the retention settings.
VERExists Specifies the maximum number of backup versions to retain for files that are currently on the client file system. This parameter is optional. The default value is 2.
VERDeleted Specifies the maximum number of backup versions to retain for files that have been deleted from the client file system after being backed up using Tivoli Storage Manager. This parameter is optional. The default value is 1.
RETExtra Specifies the number of days to retain a backup version after that version becomes inactive.
RETOnly Specifies the number of days to retain the last backup version of a file that has been deleted from the client file system.
So if you want to retain a specific data for 10 years you could specify 10 for vere,and verd since you are doing this once a year. and something like nolimit on rete and reto. Depending on your situation and what your company requires your retention to be.
Mode:
The mode parameter specifies whether a file or directory must have been modified to be considered for backup during a full incremental backup process. IBM Tivoli Storage Manager does not check this attribute when a user requests a partial incremental backup, a selective backup for a file, or a backup of a logical volume.
You can select from two modes:
Modified A file is considered for full incremental backup only if it has changed since the last backup. A file is considered changed if any of the following items is different:
Date on which the file was last modified
File size
File owner
File permissions
Absolute A file is considered for full incremental backup regardless of whether it has changed since the last backup.
VERExists Specifies the maximum number of backup versions to retain for files that are currently on the client file system. This parameter is optional. The default value is 2.
VERDeleted Specifies the maximum number of backup versions to retain for files that have been deleted from the client file system after being backed up using Tivoli Storage Manager. This parameter is optional. The default value is 1.
RETExtra Specifies the number of days to retain a backup version after that version becomes inactive.
RETOnly Specifies the number of days to retain the last backup version of a file that has been deleted from the client file system.
So if you want to retain a specific data for 10 years you could specify 10 for vere,and verd since you are doing this once a year. and something like nolimit on rete and reto. Depending on your situation and what your company requires your retention to be.
Mode:
The mode parameter specifies whether a file or directory must have been modified to be considered for backup during a full incremental backup process. IBM Tivoli Storage Manager does not check this attribute when a user requests a partial incremental backup, a selective backup for a file, or a backup of a logical volume.
You can select from two modes:
Modified A file is considered for full incremental backup only if it has changed since the last backup. A file is considered changed if any of the following items is different:
Date on which the file was last modified
File size
File owner
File permissions
Absolute A file is considered for full incremental backup regardless of whether it has changed since the last backup.
