You should set the reusedelay and the number of daily database backups to the
same number and you set both based on your preference on how far back would you
want to go for any particular reason. (i.e. how many days might pass before you
notice there is a problem)
I've done restores for a number of reasons, not all were only for recovery
after some disk/filesystem problem. If you are large enough to have multiple
TSM admins, (perhaps a junior admin on the team) one might make a mistake and
might take a few days for the other admins to notice.
I keep a week's worth of backups around and 7 days on the reusedelay for the
offsite pool only. In case someone makes a "del fi" mistake, we have a week to
recover. Or we can restore to another instance and export the needed data.
Regards,
Shawn
________________________________
Shawn Drew
> -----Original Message-----
> From: ADSM-L AT VM.MARIST DOT EDU [mailto:ADSM-L AT VM.MARIST DOT EDU]
> Sent: Tuesday, February 18, 2014 4:00 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: [ADSM-L] Database Backup best practice
>
> Well, isn't it actually the other way around? You should set your
> REUSEDelay to the amount of days you keep your database backups.
> In case of a failure you will probably always want to restore the most
> recent database backup, but if that one fails too for some reason, you
> will have to fall back on older database backups. Of course this means
> losing backup information and it's for your shop to decide what is
> acceptable.
> We keep our database backups for 3 days (twice a day) and thus the
> REUSEDelay is set to 3 days. Since we don't use physical tape I think 3
> days (equals 6 backups) is long enough.
> Keeping database backups for a longer period of time means a higher
> REUSEDelay and thus requires more scratch volumes.
> Kind regards,
> Eric van Loon
> AF/KLM Storage Engineering
>
> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf
> Of
> Ehresman,David E.
> Sent: maandag 17 februari 2014 15:31
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: Database Backup best practice
>
> You should keep at least as many TSM DB backups as the largest REUSEDelay
> on your storagepools.
>
> David
>
> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf
> Of
> Tom Taylor
> Sent: Monday, February 17, 2014 9:27 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: [ADSM-L] Database Backup best practice
>
> Good morning
>
>
> Running TSM 6.3.4
>
>
>
>
> I have read the admin guide best practice section on backing up
> the database and I have also done some google searching but I cannot find
> a straight answer on this... How many backups of the database should I
> keep available? I always do a full backup, is there any reason to keep any
> of the older full backups if I have a recent good one?
>
>
>
>
>
>
>
>
> Thomas Taylor
> System Administrator
> Jos. A. Bank Clothiers
> Cell (443)-974-5768
> ********************************************************
> For information, services and offers, please visit our web site:
> http://www.klm.com. This e-mail and any attachment may contain
> confidential and privileged material intended for the addressee only. If
> you are not the addressee, you are notified that no part of the e-mail or
> any attachment may be disclosed, copied or distributed, and that any other
> action related to this e-mail or attachment is strictly prohibited, and
> may be unlawful. If you have received this e-mail by error, please notify
> the sender immediately by return e-mail, and delete this message.
>
> Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its
> employees shall not be liable for the incorrect or incomplete transmission
> of this e-mail or any attachments, nor responsible for any delay in
> receipt.
> Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch
> Airlines) is registered in Amstelveen, The Netherlands, with registered
> number 33014286
> ********************************************************
>
This message and any attachments (the "message") is intended solely for
the addressees and is confidential. If you receive this message in error,
please delete it and immediately notify the sender. Any use not in accord
with its purpose, any dissemination or disclosure, either whole or partial,
is prohibited except formal approval. The internet can not guarantee the
integrity of this message. BNP PARIBAS (and its subsidiaries) shall (will)
not therefore be liable for the message if modified. Please note that certain
functions and services for BNP Paribas may be performed by BNP Paribas RCC, Inc.
|
