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
lipp AT storserver DOT com
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Skylar Thompson
Sent: Thursday, October 19, 2006 1:30 PM
To: ADSM-L AT VM.MARIST DOT 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 (skylar2 AT u.washington DOT edu)
-- Genome Sciences Department, System Administrator
-- K324, (206)-685-7354
-- University of Washington Medical Center
|
