ADSM-L

Re: archive (gotta get it all)

1999-12-07 09:08:33
Subject: Re: archive (gotta get it all)
From: "Brian T. Huntley" <bth AT CLARKSON DOT EDU>
Date: Tue, 7 Dec 1999 09:08:33 -0500
 On Tue, 7 Dec 1999, Sanders, David wrote:

// Yeah Brian, I think that is the bottom line to this (include/exclude isn't
// used by archive).  So, I think that I could set up -MANY- schedules to
// select on filespace masking, but how would I from a high-level select on
// whatever each and every node has?
//
// Dave Sanders
// Sr. Technical Consultant
// MassMutual / The Blue Chip Company
// 1295 State St, E060, Springfield, MA 01111
// 413-744-5095
//

Dave:
To be honest, I really dunno.  We do a server-prompted archive of every
registered node twice a year (not surprisingly, the next one is in a
couple of weeks!;) and I've always just made separate schedules.

A pain the behind, most definitely, but I couldn't find any way in the
docs to do it more efficiently.

Generally, I put all of the nodes w/ common filesystems (our core servers,
for example, all have /, /usr, /usr/local, /home, /var and /tmp
filespaces, so they can all be run from a single schedule) together, and
just make custom schedules for the rest.

It would certainly be great if objects=* worked, thus causing an archive
of all filespaces in each node, but I don't think it does...

If there is a better way to do it, I'd love to hear about it!

Brian

+-----------------------------------------------------------------------+
| Brian T. Huntley                         Systems and Network Engineer |
| Campus Information Services, Clarkson University                      |
| Ph/FAX: 315.268-2292/6570                                             |
| bth AT clarkson DOT edu                                 www.clarkson.edu/cis |
+-----------------------------------------------------------------------+
 UNIX *is* user friendly. It's just selective about who its friends are.
        PGP Public Key available. finger bth AT clarkson DOT edu

// //
// // -----Original Message-----
// // From: Moir,Betsy [mailto:betsy.moir AT ABBOTT DOT COM]
// // Sent: Tuesday, December 07, 1999 8:16 AM
// // To: ADSM-L AT VM.MARIST DOT EDU
// // Subject: Re: archive (gotta get it all)
// //
// //
// // Instead of using the domain c: d: parameter or  the objects parameter in
// the
// // schedule, have you tried adding the line INCLUDE *:\...\* at the top of
// the
// // include/exclude list.  This would cause ADSM to backup everything on any
// // locally attached drive, i.e. if they had only a c: drive it would only
// back
// // that up, but if it had a c: and a d: drive it would back them both up.
// //
// //
// //
// //
// // ADSM-L AT vm.marist DOT edu on 12/07/99 05:59:10 AM
// // Please respond to ADSM-L AT vm.marist DOT edu @ INTERNET
// // To: ADSM-L AT vm.marist DOT edu @ INTERNET
// // cc:
// // Subject: Re: archive (gotta get it all)
// //
// // Betsy, thanks for that suggestion.  But, I don't seem to be able to do
// this
// // from my serve using the automated schedular.  I'm looking to do a generic
// // backup for all platforms with a customized 1-time schedule.  I've seen
// // references that say that to include "all stuff" you may have to create
// // seperate schedules for each platform.  I was willing to do that but, I
// can't
// // even get the Win95 one to "get it all".
// //
// // If I use "domain c: d:", that will work fine except for those
// workstations
// // that don't have a "d" drive.  So it gets marked as failed and then will
// try
// // to rerun and will redo the c: drive data over again.
// //
// // It looks like I will have to go thru the filespaces and have seperate
// // schedules for those that have "c only" drives and another one for "c &
// d"?
// //
// // BTW: we do realize how much potential data we will be pumping over the
// // network.  It's been raised as an issue and we are trying to determine how
// we
// // can ask our clients to stop processing for the length of time that we
// need
// // to do their quiesced backup.  Two opposing forces:  the client's need for
// // processing their data as normal (maybe more so before the Y2K rollover)
// vs.
// // the Insurance Commisioner request.
// //
// // Dave Sanders
// // Sr. Technical Consultant
// // MassMutual / The Blue Chip Company
// // 1295 State St, E060, Springfield, MA 01111
// // 413-744-5095
// //
// //
// //
// //
<Prev in Thread] Current Thread [Next in Thread>