SCOUG-HELP Mailing List Archives

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

Date:	Sun, 20 Oct 2002 07:10:05 PST7
From:	Peter Skye <pskye@peterskye.com >
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.
=====================================================

Info2SYNass.NET wrote:
>
> you seem to be up very early ...
> ... or are you still up soo late ;-)

Sleep is for the weak, Svobi !!! :)))

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

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.

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

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.

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

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

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

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

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

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

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.