SCOUG-HELP Mailing List Archives
Return to [ 01 |
August |
2002 ]
<< Previous Message <<
>> Next Message >>
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,
CDS has now solved this with their release of version 3.00A. Now you can
backup your system to CD's and span multiple CD's. I do not know if they
solved it, if you want to continue to use your tapes.
One caveat: I was not able to restore from a crash recovery, using
multiple CD's (see my discuss of this in other responses). However, CDS
said that I was the first one with this problem. You could try Back
Again 2000 3.00A and CD's as your backup media. You will need RSJ for
this. See if that works for you. Test it out, including restoring from
crash recovery.
If it does not work, backup to the hard drive the way I previously
discussed. Backing up to tapes has got to be the slowest. Backing up to
CD's is much faster. Backing up to the hard drive beats everything
speed-wise
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".
=====================================================
<< 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.
|