SCOUG Logo


Next Meeting: Sat, TBD
Meeting Directions


Be a Member
Join SCOUG

Navigation:


Help with Searching

20 Most Recent Documents
Search Archives
Index by date, title, author, category.


Features:

Mr. Know-It-All
Ink
Download!










SCOUG:

Home

Email Lists

SIGs (Internet, General Interest, Programming, Network, more..)

Online Chats

Business

Past Presentations

Credits

Submissions

Contact SCOUG

Copyright SCOUG



warp expowest
Pictures from Sept. 1999

The views expressed in articles on this site are those of their authors.

warptech
SCOUG was there!


Copyright 1998-2024, Southern California OS/2 User Group. ALL RIGHTS RESERVED.

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.

The Southern California OS/2 User Group
USA

SCOUG-HELP Mailing List Archives

Return to [ 31 | July | 2002 ]

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


Date: Wed, 31 Jul 2002 22:58:50 PST7
From: Peter Skye <pskye@peterskye.com >
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.
=====================================================

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".

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


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

Return to [ 31 | July | 2002 ]



The Southern California OS/2 User Group
P.O. Box 26904
Santa Ana, CA 92799-6904, USA

Copyright 2001 the Southern California OS/2 User Group. ALL RIGHTS RESERVED.

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.