I have ordered 2 1 Port 1GB Ethernet Cards for the server with the intention of teaming them for redundancy. I am going to try backups to a disk storage pool over the LAN first, and if that is poor I will probably go with image backup. If all else fails will probably have to put HP's Data Protector back on support for this server only.
-
-
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.
Backing up 50 Million+ Files
- Thread starter mkbowman
- Start date
Bartdo
ADSM.ORG Member
- Joined
- Dec 9, 2002
- Messages
- 49
- Reaction score
- 3
- Points
- 0
I would consider the Flashcopy option:
It may be interesting to note the SVC flashcopy pricing was cut in half last year: From the IBM Annoucement letter ZP08-0232 dated May 13, 2008.
>>Effective May 13, 2008, when ordering FlashCopy features, only the total site capacities for the FlashCopy sources,
>>versus both source and all targets as previously required, need to be licensed for configurations of
>>the FlashCopy function, including Incremental FlashCopy, Multiple Target FlashCopy, and Cascaded FlashCopy
I would be wary of Image Backup - I believe it is an all or nothing operation. If it fails, you have nothing.
Good luck
Bart D.
It may be interesting to note the SVC flashcopy pricing was cut in half last year: From the IBM Annoucement letter ZP08-0232 dated May 13, 2008.
>>Effective May 13, 2008, when ordering FlashCopy features, only the total site capacities for the FlashCopy sources,
>>versus both source and all targets as previously required, need to be licensed for configurations of
>>the FlashCopy function, including Incremental FlashCopy, Multiple Target FlashCopy, and Cascaded FlashCopy
I would be wary of Image Backup - I believe it is an all or nothing operation. If it fails, you have nothing.
Good luck
Bart D.
anorhoads
ADSM.ORG Member
- Joined
- May 17, 2005
- Messages
- 5
- Reaction score
- 0
- Points
- 0
- Location
- Southern California
- Website
- Visit site
You might also consider the dsmc INCRbydate option as in 'dsmc Incremental -INCRbydate'.
From the client docs (V5.5 for Windows):
Use the incrbydate option with the incremental command to back up new and changed files with a modification date later than the last incremental backup stored at the server, unless you exclude the file from backup. Files added at the client after the last incremental backup, but with a modification date earlier than the last incremental, are not backed up. Attention: Files that are modified or created after their respective directory was processed by the Tivoli Storage Manager client, but before the incremental-by-date backup completes, are not backed up and will not be backed up in future incremental-by-date backups, unless the files are modified again. For this reason, a regular incremental backup should be run periodically, without specifying the incrbydate option. An incremental-by-date updates the date and time of the last incremental at the server. If you perform an incremental-by-date on only part of a file system, the date of the last full incremental is not updated and the next incremental-by-date will back up these files again. Both full incrementals and incrementals-by-date back up new and changed files.
From the client docs (V5.5 for Windows):
Use the incrbydate option with the incremental command to back up new and changed files with a modification date later than the last incremental backup stored at the server, unless you exclude the file from backup. Files added at the client after the last incremental backup, but with a modification date earlier than the last incremental, are not backed up. Attention: Files that are modified or created after their respective directory was processed by the Tivoli Storage Manager client, but before the incremental-by-date backup completes, are not backed up and will not be backed up in future incremental-by-date backups, unless the files are modified again. For this reason, a regular incremental backup should be run periodically, without specifying the incrbydate option. An incremental-by-date updates the date and time of the last incremental at the server. If you perform an incremental-by-date on only part of a file system, the date of the last full incremental is not updated and the next incremental-by-date will back up these files again. Both full incrementals and incrementals-by-date back up new and changed files.
rore
ADSM.ORG Senior Member
Well, this changes almost nothing. You have to run a regular incremental backup anyways and that's the issue being discussed.
Rudy
caldwem01
ADSM.ORG Member
It is not a good idea to backu the FastBack repository with TSM. Since the cleanup on Fastback moves blocks around, TSM will do a full backup of the repository evey time. Best way to protect the repository is to replicate the data to another fastback server. Or use the mount utility to mount the client snapshot, and then backup (progressive incremental) that with TSM. You can use the snapshotroot and asnode parameter when doing this. This allows you to put a BA client on the computer (the production computer which was backed-up with FastBack client) and directly resote data using BA client.
Update:-
Resorted to backing up the server via HP Data Protector - Full backup takes around 40 hours, Incremental a mere 6.
Decided to give TSM a go and contacted IBM about possible options since I am still not able to upgrade application to newer hardware and os (due to internal reasons)
I am trying an option whereby a Windows 2003 64Bit Server with 16GB connects via network paths to the drives on the 2000 server.
Using TSM 6.2 client:-
To process one filesystem of 1.6million files it took 3 1/2 hrs. Not a network, cpu or ram issue just merely the time it takes for the client to compare with the tsm db.
We tried flashcopy and that didn't work with SVC 4.x code - we are upgrading to SVC v5 and with the newer options we are hoping that will still be an option for us.
Question for those who do backup 50+ million files with TSM - I assume you are using Journaling successfully even with SAN drives? What is the RAM you have in the client? Any improvements with Windows 2008 ? Just curious.
-Matthew
Resorted to backing up the server via HP Data Protector - Full backup takes around 40 hours, Incremental a mere 6.
Decided to give TSM a go and contacted IBM about possible options since I am still not able to upgrade application to newer hardware and os (due to internal reasons)
I am trying an option whereby a Windows 2003 64Bit Server with 16GB connects via network paths to the drives on the 2000 server.
Using TSM 6.2 client:-
To process one filesystem of 1.6million files it took 3 1/2 hrs. Not a network, cpu or ram issue just merely the time it takes for the client to compare with the tsm db.
We tried flashcopy and that didn't work with SVC 4.x code - we are upgrading to SVC v5 and with the newer options we are hoping that will still be an option for us.
Question for those who do backup 50+ million files with TSM - I assume you are using Journaling successfully even with SAN drives? What is the RAM you have in the client? Any improvements with Windows 2008 ? Just curious.
-Matthew
