SCOUG-HELP Mailing List Archives

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

Date:	Sun, 20 Oct 2002 08:45:29 PST7
From:	"Info2SYNass.NET" <Info@SYNass.NET >
Reply-To:	scoug-help@scoug.com
To:	scoug-help@scoug.com
Subject:	SCOUG-Help: XCOPY failures (was: Using Infozip to backup)

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

Hi Peter
Thanks for your, once more, quick and interesting reply !
I do quote into your text again but I have to keep it short now
...
... some Sunday evening plights are calling soon ;-)

>> you seem to be up very early ...
>> ... or are you still up soo late ;-)
>
>Sleep is for the weak, Svobi !!! :)))

Weak ? I thought for tired folks ;-)

>> I only wonder about you backup with XCOPY !?
>> I am using Sytos Premium as my Backup SW and I also having
>> BA/2000 as a possible successor if Sytos starts to fail.
>
>I too have Back Again/2000 (server edition) but none of the
backup
>programs create what I want -- exact duplicates of my drives
which I
>could use instantly if one of my drives actually fails. I don't
want to
>restore from a backup, I just want to swap in the "good" drive.

It seems that I am in good company ;-))

>This is different from RAID drive arrays. Some of the RAID
setups have
>"parity" drives which allow the array to keep functioning with
no data
>loss if one (or more) drives fail. There are at least two
reasons why
>this isn't a perfect solution for disaster recovery:
>
>-- 1. Drives fail randomly as they reach end-of-life, but they
also can
>and do fail due to heat buildup. If your building air
conditioning
>fails on a hot day and the computer room gets hot, several
drives might
>fail and the data on the RAID array will be lost because the
number of
>failed drives exceeds the number of parity drives. I'm not
making this
>scenario up, it happens and I've read stories from several
different
>RAID users who lost two drives due to heat buildup on the same
day in a
>one-parity-drive RAID array.

I am not having practical experience with RAID.
Well the mobo (Abit KT7-Raid) of my first selfbuilt system
is having a RAID feature but I am using it as an activator
for the 2 more IDE sockets to provide UDMA100.
I could also activate some RAID but I assume it's not the
same RAID as you were telling !?

>-- 2. Theft and fire makes the RAID concept irrelevant. You
*must* have
>offsite backup.

That's TRUE and very important !
People do not realize this !!

>My eventual goal is offsite backup over the Internet (which is
slower
>than backup over a network since the bandwidth is lower unless
you're
>OC-12 or something) with the backup media being hard drive
"mirrors" of
>the backed-up drives. If I lose my main machines, I can run
from the
>backup machines and there's no time lost in "restoring" the data.

Your focus is very attractive and remembers me of my old times
with an airline operation center. Within 1 1/2 minutes we had
switched from a misbeavioring mainframe system to the twin
of this system.

>>Besides, disk drives are often cheaper than tape drives -- and
>>tapes are expensive.

That's true.
Just end of September I had a very bad experience with my backup
tapes.
My most important file of Lotus Notes ran into troubles ...
... and trying a restore from tapes I realized the unablilty
to read the tapes ;-(( I do not know what has happened ;-(((

>> With BA I am also experimenting with HCM's REXX scripts ;-))
>
>Harry has made a number of contributions to OS/2 users
everywhere. He
>has one trait that has always impressed me: he gets the job
done.

Currently I am not having the time to play more with BA
and HCM's REXX scripts. I will have to do later !
I appreciate HCM's efforts very much, exspecially
because I am not having the patience of programming.

>> I also know from my old experiences in the past that we needed
>> to stop the DB system (IBM IMS) for the time of its backup !!
>> For this time there was no online access to the DB system.
>> During backup time accesses were queued.
>> When the backup was done the DB system was released again and
>> the queued and further transaction were served normally again.
>
>
>Backing up large databases is problematic. If the database is
"hot"
>during the backup then your backup might be half way through the
>database when suddenly a transaction updates two database records
>simultaneously -- one near the beginning of the database and one
near
>the end. The resulting backup will only have one of the two
updated
>records.
>
>There are some programming methods to get around this. The user
>software can write to both the database *and* to a transaction
file, and
>the transaction file can later be matched against the database
to make
>sure the database is current. Or, the user software can
simultaneously
>update two duplicate databases on different drives -- if one
drive fails
>then you still have the other *and* you can "switch away" one of
the
>databases and fully back it up, then switch it back in for
writing only
>and either apply the transaction file to it or mirror all the
records
>from the always-hot database to it (with appropriate record
locking
>during the mirroring process, of course) which will result in it
being
>an exact duplicate once again. I'm sure there are other
solutions.
>
>Most or all of the files that we back up aren't large databases,
of
>course. The system administrator needs to decide if the database
>requires a special backup strategy.

Yes, this is also a very, very interesting topic.

>> OK, XCOPY is copying only of course ...
>> ... where dSync seem to be like replication !?
>> Interesting !
>
>Yes, it's like replication. The terms "replication" and
"mirroring" are
>similar -- I tend to use "replication" for copying groups of
files and
>"mirroring" for copying an entire partition.

I like your differencing of replication and mirroring !
You said it perfect !!

>> >I'll be dreaming of the balmy sun-soaked
>> >beaches of outer Mongolia,
>>
>> WOW, sounds like you found your corner in the paradise ;-)
>> Is there still a little free corner if I retire and migrate
>> my old bones to your balmy sun-soaked Pacific Coast ??
>
>And just how old are your old bones? It's rumored that the
balmy ocean
>breezes of San Diego cause a 90 degree phase shift in your brain
which
>stops the aging process.

My old bones are going to be 58 within a few months ;-)
Must be great to experience that rumoring of almy ocean breezes
;-))

Just finished answering I have to pen off now.
Enjoy your paradise !
svobi

************************************************************
*** >>> Say NO to HTML in Mail and News <<< ***
*** ++++++++++++++++++++++++++++++++++++++++++++++++ ***
*** >>> AGAINST TERROR +++ AGAINST WAR <<< ***
************************************************************

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

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 [ 20 | October | 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.