In that environment, then, what does it all mean? You never have all of your files backed up into any one location at any one time anyway! So it becomes a point-in-time thing: at this point in time, everything is as good as it can possibly be...
For Windows clients, try the journaling option. That might help you process the file spaces faster (by not needing to scan the file system). Any successive backup stg operation picks up the files that were missed during the last backup stg operation. Nothing can drop through the cracks. At some point you will have all the files in the copy pool. Except in your environment where files seem to be constantly arriving. In that case, I think you need to stop worrying about it as there is nothing you can do about it and it will only make you crazy anyway. And remember: if a file on one of your clients changes a second after you backed it up, you don't have a backup of it. Thanks, Kelly Kelly J. Lipp VP Manufacturing & CTO STORServer, Inc. 485-B Elkton Drive Colorado Springs, CO 80907 719-266-8777 [EMAIL PROTECTED] -----Original Message----- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Skylar Thompson Sent: Thursday, October 19, 2006 1:30 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Tivoli storage manager migration/backup Kelly Lipp wrote: > Skylar, > > In our systems, we backup stg first and then migrate so we know we > have one done before the other. In your case, you synchronize theses > processes (our STORServer Manager product does this for you) by > creating scripts. > > I guess I don't really worry too much about a tape failure before the > backup stg/migration processing completes. Worst case, you might have > a problem and lose client data. That's only a problem if you need the > data on the client at the same time that happens. Unlikely. In the > case where you lose client data on the TSM server (a very rare event), > the client will send it again (to the extent possible) the next time a > backup runs. So in most cases the problem is self healing. > > Now, if I were using poor tape technology I would be really worried. > But if I'm using something modern, like LTO3, then I worry less. > Our backup environment unfortunately tends towards the 24/7, because we have some client-initiated backups, and some systems that just have so many files (some with over 50 million in a directory) that it takes ages to just index. We can't really guarantee a quiet that we can safely backup and migrate files without having some fall through the cracks. I made the case to my boss that delaying clients due to a full disk cache is much more dangerous than doing tape-to-tape backups, and we're now going with the stock disk-disk-tape-tape solution, which gives us a lot more scheduling flexibility to boot. Yay! -- -- Skylar Thompson ([EMAIL PROTECTED]) -- Genome Sciences Department, System Administrator -- K324, (206)-685-7354 -- University of Washington Medical Center
