ADSM-L

Re: Monthly Archives

1997-04-28 17:21:33
Subject: Re: Monthly Archives
From: "Prather, Wanda" <PrathW1 AT CENTRAL.SSD.JHUAPL DOT EDU>
Date: Mon, 28 Apr 1997 17:21:33 -0400
It probably depends on what kind of hardware you have and therefore how
fast you can copy tapes, but:
WHAT IF, on that weekend, you just declared a new COPY POOL and told
ADSM to copy everything from your primary pool to the new copy pool?

The next month, delete those tapes, and start again.

You would end up copying all the backup versions of the files on your
clients, instead of just the active one.  But,  unless you keep
unlimited backup versions, I'll bet that would be faster (since it's
just copying tapes) than pumping the data across the network again, or
using the restore/copy/delete process you describe.

And, it has the advantage that YOU can start the process and go home.


>----------
>From:  Griggs, James[SMTP:James_Griggs AT FREDDIEMAC DOT COM]
>Sent:  Thursday, April 24, 1997 11:46 AM
>To:    ADSM-L AT VM.MARIST DOT EDU
>Subject:       Monthly Archives
>
>A Business Requirement:  To create an Archive of all data across all
>platforms (UNIX, Novell, NT) after the close of business on the last
>business day of each month.  This is in addition to the normal daily
>incremental backup.
>
>Problem:  1.5 Tb of data -- inadequate time.  Is it "really" necessary to
>resend the data across the network when it already exists on tape (onsite
>backup and offsite copy)?
>
>Possible solution:  On a weekend (or other ADSM server low utilization
>window), restore data for one node to a given point in time onto DASD; write
>an archive tape from the restored DASD; delete restored data from DASD;
>repeat cycle until all nodes completed.
>
>Are there any other solutions or options?
>
>"Export Server" of data is not a viable option because exported files are
>not managed to ADSM and you must "Import Server" all files in order to
>restore a few to a given node.
>
>Solutions surrounding restoring the ADSM database to a prior point in time
>is not a viable option because it in effect brings the server down (it's
>used extensively) and is simply a lot of work, not to mention being messy.
>
<Prev in Thread] Current Thread [Next in Thread>