Hot Diggety! Koen Willems was rumored to have written: > > Maybe that the access state is "unavaileble" try "q vol f=d" > look at the access state if it is not in a readw state use > "update vol XXXX access=readwrite" > Then do a move data on the volume to see if the remaining data moves > Do a del vol and or a checkout if you want to lose the volume.
Apparently, it was bad tapes. > Compression is automaticaly used when using format is drives. Interesting. Guess that makes sense. > (Do not use client compression) Nah, wasn't planning to. The backups are fast enough that we wouldn't have any real benefit to doing client compression. > Storage pools give a beter restore performance on file data if the contain > less volumes ( this cuts on mount and search times ) Ahh, makes sense. > Make a pool for priority restore nodes ( if possible with collocation ) > Make a pool foor non priority nodes without collocation > Make a pool for every type of TDP you install. > > ( colloction will cost you tapespace but will speed up restores ) > ( the less volumes an uncollocated storage pool will have the faster the > restores ) > ( TDP pools have a beter restore performance because op the large > sequentiall backups that kan stream back when restoring) Makes sense. Good tip about TDP pools, thanks. Definitely will keep these separate. > Do not leave data on your diskpool longer then necessary. > Further more one does not want to have backup data on a diskpool for longer > than one backup cycle. after backup sessions do a: > > update stg diskpool hi=0 lo=0 and move data to tape and then offsite. Sounds good. ;) I'm looking to concentrate all client backups in a specific window, then have the scheduler fire off a daily job to do the migrations (disk->tape, tape->offsite copypool) with some basic error checking, and also do other things such as expire inventory, dbbackup, etc. -Dan