Monte,
I echo everything that Juraj and Joe suggest, stressing the importance of
nailing down your customers'/business' recovery requirements, and then
designing a backup solution around those, rather than the other way around.
I trust that when you say 'NT' servers, you mean Win2K and above, otherwise TSM
Journalling Engine isn't going to work for you. In the event of a 'disaster,
would you really be required to restore *all* of the data, or would the server
be rebuilt from the OS/image upwards, and only key data need to be recovered. I
commonly ask the question 'do we really need to have 1000's versions of
notepad.exe in our TSM server'. Look at the main recovery scenarios that you
are putting in a backup solution for: single file corruption/deletion should be
possible in a short amount of time. Directory deletion again should be fine for
any moderately sized directories. Otherwise, just work out the maths and ask
the business if they can wait x hours for a full 40GB restore. Assuming 33%
compression and a real-life average of just above 15KB/s (might be more if
you're lucky) over your 256Kb line, you're looking at a maximum of 80MB/hour
restore rate. If your 40GB server happens to be at the end of this one, you
have a little over 20 days to get back your 40GB! Or perhaps my maths is a
little skewed here...
Rgds,
David McClelland
Tivoli Storage Manager Certified Consultant
Operations Backup and Recovery Projects
Shared Infrastructure Development
Reuters
85 Fleet Street
London EC4P 4AJ
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Salak Juraj
Sent: 24 November 2004 16:51
To: ADSM-L AT VM.MARIST DOT EDU
Subject: AW: Remote Backups....
perfect!
in addition to this points, do make some planning & tests for restore.
Basically, your problem is full restore.
Either you can afford to wait long enoung to restore over remote line,
(learning about "restart restore" may be important) or produce backup sets and
send them per post to the remote location.
best regards
Juraj
> -----Ursprüngliche Nachricht-----
> Von: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] Im Auftrag
> von Joe Crnjanski
> Gesendet: Mittwoch, 24. November 2004 17:25
> An: ADSM-L AT VM.MARIST DOT EDU
> Betreff: Re: Remote Backups....
>
> -Use compression
>
> -Use sub-file backup. (doesn't work on files larger than 2GB;
> otherwise enormous improvements)
>
> -Encryption doesn't hurt if you are moving the data over public
> network
> (Internet)- will be improved in TSM 5.3
>
> -Don't backup system object every day (around 200MB-300MB).
> Make additional schedule for system object and C drive (maybe on
> weekends)
>
> -Choose carefully what you need to backup (include/exclude)
>
> Regards,
> Joe C.
>
>
> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf
> Of Michael, Monte
> Sent: Tuesday, November 23, 2004 3:32 PM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Remote Backups....
>
> Fellow TSM administrators:
>
> My company is currently looking at backing up approximately 40 NT
> servers at our remote locations, back to our local data center. Each
> location has around 10gb - 40gb of storage, and very minimal daily
> change activity on the files. Some of the locations are 256k data
> lines, and some are t1 lines.
>
> Does anyone have a list of best practices? What are some of the
> options that you have found to improve the process of remote backups
> via TSM to a central location. Any help and input that you can
> provide is much appreciated.
>
> > Thank You,
> >
> > Monte Michael
>
>
> This communication is for use by the intended recipient and contains
> information that may be privileged, confidential or copyrighted under
> applicable law. If you are not the intended recipient, you are hereby
> formally notified that any use, copying or distribution of this
> e-mail, in whole or in part, is strictly prohibited. Please notify
> the sender by return e-mail and delete this e-mail from your system.
> Unless explicitly and conspicuously designated as "E-Contract
> Intended", this e-mail does not constitute a contract offer, a
> contract amendment, or an acceptance of a contract offer.
> This e-mail does not constitute a consent to the use of sender's
> contact information for direct marketing purposes or for transfers of
> data to third parties.
>
> Francais Deutsch Italiano Espanol Portugues Japanese Chinese
> Korean
>
> http://www.DuPont.com/corp/email_disclaimer.html
>
-----------------------------------------------------------------
Visit our Internet site at http://www.reuters.com
Get closer to the financial markets with Reuters Messaging - for more
information and to register, visit http://www.reuters.com/messaging
Any views expressed in this message are those of the individual
sender, except where the sender specifically states them to be
the views of Reuters Ltd.
|
