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 [ 01 | August | 2002 ]

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


Date: Thu, 1 Aug 2002 04:25:52 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.
=====================================================

Steven,

I once tried to save 2 sequencial backups to the same *.DAT container.
On the second backup, Back Again 2000 stopped dead in its tracks. I
believe the problem was that the *.DAT file became 2.1GB somewhere on
the second backup and that was it. I did not investigate it thoroughly
to find out, but I think that's why. I stopped trying to use a single
*.DAT file for anything more than a single backup. No more problems
after that.

I believe that you are right and that Back Again 2000 I/O is faster than
XCOPY. Peter would be much better off using it. If Peter's system is so
large that a Back Again 2000 backup would result in a *.DAT file greater
than 2.1GB, even with compression enabled, then he will have to break up
the backup of his system into 2 or more individual ones. He can automate
almost 100% of the task by setting up BA 2000 backup catalogs, which
define which files and folders he wants to backup and what the name and
path of the backup file will be. Each time he performs a complete
backup, he will have to change the name and/or path of the backup file,
that's all. If he does not do so, BA 2000 will save that backup to the
same backup file as before (because he did not change that setup
information on the catalog). The result will be a growing backup file,
which will eventually stop the backup at 2.1GB.

Peter can automate by dropping his backup catalogs into the scheduler.
The scheduler will then start and complete his backups automatically,
per his schedule. THE ONLY THING HE'LL HAVE TO DO IS CHANGE THE CATALOGS
TO A DIFFERENT BACKUP FILE AND/OR PATH before the scheduler runs the
next time!

HCM
_____________________________________________________________________________

Steven Levine 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.
> =====================================================
>
> In <3D48C076.B1CE3508@attglobal.net>, on 07/31/02
> at 09:00 PM, Harry Chris Motin said:
>
> >Incidently, I do not understand your response, below. Compression should
> >do exactly the opposite of what you stated. In Back Again 2000 you use
> >compression during the backup to get more data in a smaller file. The
> >resulting backup file is smaller than what you backed up. Compression
> >takes longer to complete, however.
>
> I think what Peter meant is that the .DAT container could exceed 2GB.
> With XCOPY, this can't happen because there is no container.
>
> To me, it appears that BA2K does I/O much more effeciently than XCOPY, so
> even without compression, BA2K will be faster.
>
> 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.
>
> Steven
>
> --
> ---------------------------------------------------------------------
> "Steven Levine" MR2/ICE 2.31a #10183 Warp4/FP15/14.085_W4
> www.scoug.com irc.webbnet.org #scoug (Wed 7pm PST)
> ---------------------------------------------------------------------
>
> =====================================================
>
> 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".

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


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

Return to [ 01 | August | 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.