ADSM-L

Re: archive failure (continued)

2003-04-01 07:07:55
Subject: Re: archive failure (continued)
From: J M <jm_seattle AT HOTMAIL DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Tue, 1 Apr 2003 04:07:17 -0800
>On Mon, 31 Mar 2003 07:16 pm, it was written:
>>You could try running monthly incrementals under a
>>different nodename (ie: create another dsm.opt file
>>eg: dsmmthly.opt) to your TSM (same or even dedicated)
>>server.

BTW, running monthly incrementals will not facilitate your long-term
storage nearly as nicely as an archive will.

This is very true for our environment, since we will need to keep some data,
literally forever, and some data 1-10 years. So the vital records
retention/archive is definitely a requirement for us- and having accurate
snapshots will be key.

The original poster commented that he could not run archives and backups
off the same client; I'd be interested in seeing what is going on with
his TSM environment.

The problem is that some archive jobs are taking a very long time to finish,
and end up overlapping with daily backup processing jobs. Part of our issue
is likely DB I/O Disk Contention (70 GB TSM DB AIX on 3 36 GB SCSI disks!).

From: Steven Pemberton [mailto:stevep AT IBK.COM DOT AU]
>Have you considered creating a monthly BackupSet tape for
>each of your file servers?
>
>BackupSets have several advantages over a "full archive"
>for monthly retention:
>
>1/ The file server doesn't need to send any additional data
>for the "monthly" retention. There is no need for a
>"special" monthly backup. The backupset is
>created from existing incremental backup data already in the
>TSM server.
>
>2/ The BackupSet contents are indexed on the backupset tapes,
>and not in the TSM database. Therefore your database doesn't
>need to grow as you retain the monthly backupsets.

As big a fan of backupsets as I am, I feel the need to point out the
disadvantage of backupsets: you can't browse through them if you don't
the name of a desired file or its directory location. You can run Q
BACKUPSETCONTENTS, but then you'll have to grep through a *very* long
output.
In our environment, a backupset would be ideal to keep our TSM DB from
growing constantly due to archives, except for the fact we are limited in
the number of tape drives available to process the backupset data migration
tape-tape. Any ideas to circumvent this physical limitation would be much
appreciated-

Many Thanks-- John

_________________________________________________________________
The new MSN 8: smart spam protection and 2 months FREE*
http://join.msn.com/?page=features/junkmail

<Prev in Thread] Current Thread [Next in Thread>