SCOUG-HELP Mailing List Archives

<< Previous Message << >> Next Message >>

Date:	Sat, 3 Aug 2002 08:05:47 PST7
From:	Harry Chris Motin <hmotin@attglobal.net >
Reply-To:	scoug-help@scoug.com
To:	scoug-help@scoug.com
Subject:	SCOUG-Help: Re: Drive Image Backups

Content Type: text/plain

=====================================================
If you are responding to someone asking for help who
may not be a member of this list, be sure to use the
REPLY TO ALL feature of your email program.
=====================================================

Peter,

I'm trying to respond to your backup issues, because I really think
there's a better/faster way for you that would be satisfactory and
waaaay less time than 3.5 hours to complete and another 3.5 hours to
compare and verify.

I think that XCOPY is not the way. But before I go there, I really did
not understand your comments about < = > functionally and root
directories. By root directory do you mean the first level of
directories on a particular drive? So, for example, your C:\ drive might
have:

DRIVE ROOT DIRECTORIES

C:
Acrobat3
BlueCad
BonusPak
BubbleLaunchPad
...,
...,
OS/2
...,
MPTN
...,

as the first level of subdirectories (or root directories) under it. Is
that what you mean by "root directories"?

If I could get an idea of what your setup is, what your backup
requirements are and what you don't want to tolerate in performing
backups, etc., then I might be of help. Steven's idea of writing a REXX
script to do the scheduling work might be just the ticket. I might be
able to do it.

7.0 hours per day devoted to backing up is obscene!! There's got to be a
better/faster way!

HCM

_____________________________________________________________________________

Peter Skye wrote:
>
> =====================================================
> If you are responding to someone asking for help who
> may not be a member of this list, be sure to use the
> REPLY TO ALL feature of your email program.
> =====================================================
>
> Steven Levine wrote:
> >
> > I think what Peter meant is that the .DAT container
> > could exceed 2GB. With XCOPY, this can't happen
> > because there is no container.
>
> Oh, is that what he was asking. Yes, that's correct. I thought he was
> asking about throughput speed.
>
> > If I had Peter's 2GB problem, what I would do is write
> > some REXX code to build the .set files on the fly. This
> > could ensure that the container did not exceed 2GB.
>
> I pestered CDS (the Back Again people) quite a bit with this problem.
>
> -- They promised that spanned archive volumes would be forthcoming in a
> future release (don't know if that was ever done). Thus, a 5 GB
> "container" file could be "spanned" into three files of 2 GB, 2 GB and 1
> GB which would all be HPFS-compatible.
>
> -- I also asked for <, =, > functionality to include a range of root
> directories so that I could, for example, do a backup of all files in
> all root directories up to but not including \Mirrors\, then do a second
> backup of my \Mirrors\ directory, then do a third final backup of all
> files in root directories that were after \Mirrors\. That way I could
> manually figure out how to keep from hitting the 2 GB limit and backup
> accordingly. Didn't get very far with that request. Steven is
> correct that I could write a program which would analyze the root
> directory's subdirectories and appropriately create backup sets -- but
> what a pain to have to do it this way.
>
> Finally I just gave up on BA/2K. The 2 GB limitation is the real killer
> for anything making one big file (compressed or not) out of lots of
> smaller files, so I switched to XCOPY. It gets the job done. I suppose
> I could make my backup drive JFS and then go back to compressing the
> files into one large archive file. (PKZip allows spanning but the OS/2
> version has a rather small maximum number of files that it will put in
> one .zip file. Zip doesn't have spanning.)
>
> Backup is done for two reasons: archival storage (Quick! Reload the
> January data! The IRS is here for an audit!) and disaster recovery
> (Hello, police? Somebody stole our computers!). Ray Davison has the
> right idea when he pulls his backup drives out of his machines and puts
> them in a fire safe. I used to store mine off-site but I've gotten lazy
> and don't do so any more. Still, you also need the archival storage
> which a daily hard drive backup doesn't give you (I once had to recover
> a scrambled file that I hadn't accessed in six months, and luckily had
> it on an old archive). My drives are too big to consider CD or DVD
> backup.
>
> I've looked at backing up over the Internet to an off-site backup server
> but my DSL transmission speed would make this a 24x7 project (it would
> take more than 24 hours to backup my data *and* I like to backup every
> day -- I would have no bandwidth left for anything else!). Mirroring
> over the Internet would thus be a better way to go; only the changed
> files would be sent to the backup server. The difference between
> mirroring and a typical update backup is that, with mirroring, files
> which you have deleted on your workstation drive are then deleted from
> the backup drive by the backup program. The backup programs that I know
> of won't delete such files (and files which you've renamed are then in
> the backup with both the old and new names). Back Again/2000 Server, as
> far as I know, doesn't do mirroring.
>
> - Peter
>
> =====================================================
>
> To unsubscribe from this list, send an email message
> to "steward@scoug.com". In the body of the message,
> put the command "unsubscribe scoug-help".
>
> For problems, contact the list owner at
> "rollin@scoug.com".
>
> =====================================================

=====================================================

To unsubscribe from this list, send an email message
to "steward@scoug.com". In the body of the message,
put the command "unsubscribe scoug-help".

For problems, contact the list owner at
"rollin@scoug.com".

=====================================================

Return to [ 03 | August | 2002 ]

SCOUG, Warp Expo West, and Warpfest are trademarks of the Southern California OS/2 User Group. OS/2, Workplace Shell, and IBM are registered trademarks of International Business Machines Corporation. All other trademarks remain the property of their respective owners.