system backup
Richard Gliebe
what is the best way to make a system backup, (without supertar's) and
restore it after a systemcrash ?
My system: 3.2v5.0.5
Thanks
Richard
Tony Lawrence
> Hi there,
>
> what is the best way to make a system backup, (without supertar's) and
> restore it after a systemcrash ?
(sigh)
Just about everyone here who has a clue will strongly recommend that you
buy one of the Supertars. Ssomeone who doesn't even have enough basic
knowledge to make a simple system backup saying that they don't want to
use a supertar is, IMHO, somewhat incredible.
You (apparently) don't know the first thing about backing up your
system. Apparently you don't know how to make boot recovery disks, or
how to use them. My bet is that you wouldn't know where to begin after
the floppy booted.
Their are recipes you can follow- there's even some in the FAQ (
http://pcunix.com/SCOFAQ/ ). Possibly some misguided soul will post a
recipe in response to your request. Or some proud geek-wannabe will
present you with their home grown scripts. Does that make sense? Sure,
almost as much sense as me getting a booklet that tells me how to
replace my car's crankshaft should the need arise.
The Supertars are NOT expensive. They are immeasurably better than
ANYTHING that is likely to be offered here in response to your plea.
Moreover, with most of them, you get at least free email support just
for owning the product.
Now- in the event that your drive crashes, what do you REALLY want to
do? Screw around with stuff you don't comprehend, frustrating yourself
and wasting precious time, or use a professional product with years and
years of engineering and professional support behind it?
At the very least, before you make up your mind, download one or more of
the demos and TRY them.
--
Please note new phone number: (781) 784-7547
Tony Lawrence
SCO/Linux Support Tips, How-To's, Tests and more: http://pcunix.com
Free Unix/Linux Consultants list: http://pcunix.com/consultants.html
James Szabadics
Richard,
you may want to read the man pages on cpio. There are a myraid of
options - its at no extra cost but a bunch more complexity - sometimes
this challenge is enjoyable.
If you have a disaster recovery server as I have you will be able to
practice your recovery procedure and perfect it. I use a nightly tape
backup and rsync the database application we run our business on to
the DR server in a different building on site. It has smarts to use
compression and copy only changed files.
look up keywords - rsync and szabadics - to find the thread
I have a backup script that I would share with you if you were
interested contact me directly.
If you want to use a supertar - thats great too.
James
"Richard Gliebe" <rig...@gmx.at> wrote in message news:<3da3fad6$1...@eumel.hag.hilti.com>...
bill
James Szabadics wrote:
>
> Tony must be having a very bad day.
>
> Richard,
>
> you may want to read the man pages on cpio. There are a myraid of
> options - its at no extra cost but a bunch more complexity - sometimes
> this challenge is enjoyable.
>
> If you have a disaster recovery server as I have you will be able to
> practice your recovery procedure and perfect it. I use a nightly tape
> backup and rsync the database application we run our business on to
> the DR server in a different building on site. It has smarts to use
> compression and copy only changed files.
>
> look up keywords - rsync and szabadics - to find the thread
>
> I have a backup script that I would share with you if you were
> interested contact me directly.
>
> If you want to use a supertar - thats great too.
>
> James
>
I find I must agree with Tony. When you buy a SuperTar you are also
buying a ton of experience and support. We use Lone-Tar
(http://www.LoneTar.com/). With the LoneTar comes expert hand holding
24 x 7 because you don't want to be trying to restore to a different
type of disk (they don't make the other one any more) with the
customer/boss breathing down your neck and the husband/wife waiting for
you at home with the crying kids.
I am sure the other SuperTars are just as good.
Bob Meyers
"Tony Lawrence" <to...@pcunix.com> wrote in message
news:ao15nu$428$1...@pcls4.std.com...
> Does that make sense? Sure,
> almost as much sense as me getting a booklet that tells me how to
> replace my car's crankshaft should the need arise.
Uh, Tony, we want to see you do that with only a screw driver and pliers
from your glovebox, on a busy freeway at rush hour. We'll be watching.
Original poster, I agree 100% with Tony's recommendations on SuperTars. I
won't do a SCO box without one.
Bill Vermillion
>you may want to read the man pages on cpio. There are a myraid of
>options - its at no extra cost but a bunch more complexity - sometimes
>this challenge is enjoyable.
>If you have a disaster recovery server as I have you will be able to
>practice your recovery procedure and perfect it. I use a nightly tape
>backup and rsync the database application we run our business on to
>the DR server in a different building on site. It has smarts to use
>compression and copy only changed files.
What the supertar programs offer and can be done by users if you
ferret out the proper programs, is a rewind and bit-level verify of
the tape contents. 99% of the time there is no problem, but as
Murphy lies in wait you know that 1% of the time where the backup
is not good that will be the time you need it.
The nightly email of the verified backup [or failure] means things
can be corrected instantly.
Before the supertars started putting this in, I used a program
from alt.sources from a LONG LONG time ago called 'checktar' that
I'd run when backing up to floppies. I never made important backups
with something like that since then.
One of the nicer things on the supertars is the automatic creation
of the recovery disk. You do have the luxury of your backups
being in another building so you can recover from catastophic
failure - eg fire/flood/etc - that most people would need verified
off-site tapes for.
--
Bill Vermillion - bv @ wjv . com
Tony Lawrence
> Tony must be having a very bad day.
I don't know whether to laugh or what.
I'm not having a bad day.
Let me put it in coarser language: only the very brightest or the very
dumbest would use their own backup scripts instead of one of the supertars.
--
Stuart J. Browne
> James Szabadics wrote:
> > Tony must be having a very bad day.
>
> I don't know whether to laugh or what.
>
> I'm not having a bad day.
>
> Let me put it in coarser language: only the very brightest or the very
> dumbest would use their own backup scripts instead of one of the
supertars.
*blink*
*pout*
damnit.. fall in to the dumbest category *sniff*
bkxie
Tony Lawrence
I haven't a clue as to whether you are joking or not, but I meant what I
said.
If you are bright enough to do a better job than any of the Supertars
do, then my hat is off to you. I'm not near that smart, and my bet is
that the few people here who ARE that bright are mostly too lazy to bother.
If you can't write scripts that are better (hint: cpio/tar/dump don't
begin to cut the mustard) and you have data that is important to you,
and don't use a Supertar, then you are really being very foolish.
That's my opinion, of course. It's also the opinion of most of the
other people here who have opinions that other folk (like me) find
worthwhile.
Stuart J. Browne
> Stuart J. Browne wrote:
> > "Tony Lawrence" <to...@pcunix.com> wrote in message
> > news:aogufj$4hu$1...@pcls4.std.com...
> >
> >>James Szabadics wrote:
> >>
> >>>Tony must be having a very bad day.
> >>
> >>I don't know whether to laugh or what.
> >>
> >>I'm not having a bad day.
> >>
> >>Let me put it in coarser language: only the very brightest or the very
> >>dumbest would use their own backup scripts instead of one of the
> >
> > supertars.
> >
> > *blink*
> >
> > *pout*
> >
> > damnit.. fall in to the dumbest category *sniff*
>
> I haven't a clue as to whether you are joking or not, but I meant what I
> said.
somwhat of a joke.
> If you are bright enough to do a better job than any of the Supertars
> do, then my hat is off to you. I'm not near that smart, and my bet is
> that the few people here who ARE that bright are mostly too lazy to
bother.
>
> If you can't write scripts that are better (hint: cpio/tar/dump don't
> begin to cut the mustard) and you have data that is important to you,
> and don't use a Supertar, then you are really being very foolish.
>
> That's my opinion, of course. It's also the opinion of most of the
> other people here who have opinions that other folk (like me) find
> worthwhile.
We use combinations of supertar's as well as tried-and-true cpio for the
most part. The checksum routines we've written make me go pale at times,
but they work.
but *shrug*.
bkx
James Szabadics
my point is that the post went beyond the valid advice to consider the
supertar. You used language to belittle the poster rather than just
guide him/her. I guessed you were having a bad day but maybe you are
like that all the time.
Its more important to have good backups and tested recovery
procedures. If it works dont knock it - especially if you havenst
seen it and arent familiar with the details. We have appropriate
sized media, rotation strategy, archival process, fireproof media
storage, offsite archive.
It would be foolish to badmouth a successful/free method without
knowing the full details. Supertars dont make you smart. If you are
stupid it probably doesnt matter if you have a supertar or not.
You contribute much valuable knowledge - please try not to insult
people when you impart it.
James
Pat Welch
You may "have appropriate sized media, rotation strategy, archival
process, fireproof media storage, offsite archive.", but 10 copies of
crap is still 10 copies of crap.
cpio or tar can NOT do bit level verifies by themselves. And if you've
written custom C code to do verification you've spent a lot more $$ than
one of the Supertars cost - without even touching the one-button bare
metal restores offered by a Supertar product.
--
----------------------------------------------------
Pat Welch, UBB Computer Services, a WCS Affiliate
Caldera Authorized Partner
Unix/Linux/Windows/Hardware Sales/Support
(209) 745-1401 Fax: (413) 714-2833
Nationwide pager: (800) 608-7122
E-mail: pat...@inreach.com
Tell the Frelling idiots at Scifi to Save Farscape!!
----------------------------------------------------
Tony Lawrence
> Tony,
>
> my point is that the post went beyond the valid advice to consider the
> supertar. You used language to belittle the poster rather than just
> guide him/her. I guessed you were having a bad day but maybe you are
> like that all the time.
Gawd I am so sick of this modern pussy footing can't say anything lest
we offend someone crapola.
Look: the original poster is self-admittedly not even familiar with
basic cpio- probably not familiar with unix at all. A person with so
little knowledge should not be depending on recipes posted here. BTW,
did you happen to notice that no one but you pointed him to recipes?
Everyone else who responded re-echoed the advice to use a supertar.
>
> Its more important to have good backups and tested recovery
> procedures. If it works dont knock it - especially if you havenst
> seen it and arent familiar with the details. We have appropriate
> sized media, rotation strategy, archival process, fireproof media
> storage, offsite archive.
Right. And in another thread you are having problems with a tape drive.
Notice that one of the folks giving you advice on that is the
President of Microlite, one of the Supertars. Notice that other folks
have recommended employing tools like edge.tape from that same company.
Oops, never mind: had you momentarily confused with Stuart Browne. The
point is still valid though.
>
> It would be foolish to badmouth a successful/free method without
> knowing the full details.
I guess you feel bad-mouthed. I'll say it again: if your method matches
the ease and reliability of the supertars, then my hat is off in
respect. I'm not that smart, and in all the years I've been in this
business (that's 21 now) and in all the years I have been in this
newsgroup (11 ?) I haven't seen one yet. But yours may be exactly what
the world has been looking for. Since the original poster is not in a
position to distinguish between crap and the beautiful system you claim
to have, my advice to him was to ignore postings like yours and stick
with things we know are good.
When I see the rest of the long term posters here saying "Gee, I looked
at Jame's system and I really recommend it" I'll change my tone. For
myself, I'm sorry to say that long experience tells me it's not even
worth my time to take a peek at it.
BTW, does your script come with support? :-)
>Supertars dont make you smart.
No, but they eliminate the necessity. And that was the point.
>If you are
> stupid it probably doesnt matter if you have a supertar or not.
Yes, it does. BTW, as is so common by "don't insult people" folk, you
are confusing a stupid act with a stupid person. We all do stupid
things now and then. Nothing the original poster said indicates general
stupidity, and nothing I said paints him as such. But for him not to
use a Supertar is, IMHO, a stupid act. That's the same comment I'd make
to anyone coming here seeking backup recipes.
Note that I'm not saying that YOUR methods are stupid. My private bet
with myself is that they probably are, but I certainly could be wrong,
so I won't say that. You might be much smarter and have much more
experience than all the engineers at Microlite, Lonetar, and Ctar.
After all, it's only backup- how smart do you have to be?
OK, that was unnecessarily caustic, and I admit it. I'll apologize in
advance: I don't know what you do and it could be just as good. I'm not
smart enough to do that myself and probably not smart enough to look at
what you've done and judge it intelligently so I shouldn't be such a
wise-ass. Sorry.
>
> You contribute much valuable knowledge - please try not to insult
> people when you impart it.
If you ARE doing something stupid (and every one of us does that), it
isn't insulting for someone else to say so.
BTW, I object a bit to your fretting about someone else's feelings. If
the original poster had his ego bruised by my response, he never said so.
Why do you feel the need to be the guardian of political correctness here?
Oh, well. Go in peace. I hope your backup scheme always works for you.
James Szabadics
I agree that most people with a single server and tape backup would be
best served by a supertar over cpio, tar etc.
if you read the earlier post - we use rsync to an identical hardware
DR server in a remote building as one method of backup - which is a
useable and verifyable backup, not a hope the tapes OK system. This
should mean we dont need to revert to tape for hardware issues. We
switch hosts. Its not failover clustering but its very useful.
Your bit level verify may give you confidence that the tape matched
the data but it doesnt mean it will restore successfully. There are
no 100% foolproof solutions. If your tape didnt write correctly the
log will tell you - if your sysadmin cares to read it - but if the
failure occured before you did the next backup...
And if you actually read carefully we do DR testing - ie the archive
tapes are "verified" by restoring to the DR server and the system is
tested.
Dont get me wrong - Supertars are great. Other ways are useful and
valid too. I'd rather put my money on the useable redundant hardware
and syncronised database than the bit level verify software to get me
back up as soon as possible after a disaster. Both will work.
I could happily fit a supertar into my setup. But its not a priority
as long as I have backups that demonstrably recover the data to the DR
server. I believe that they are useful and a great tool and I commend
you for recommending them.
regards
James
Pat Welch <pat...@inreach.com> wrote in message news:<0hwr9.75402$NW3.19077@sccrnsc03>...
Bill Vermillion
Pat Welch <pat...@inreach.com> wrote:
>James Szabadics wrote:
>> my point is that the post went beyond the valid advice to consider the
>> supertar. You used language to belittle the poster rather than just
>> guide him/her. I guessed you were having a bad day but maybe you are
>> like that all the time.
>>
>> Its more important to have good backups and tested recovery
>> procedures. If it works dont knock it - especially if you havenst
>> seen it and arent familiar with the details. We have appropriate
>> sized media, rotation strategy, archival process, fireproof media
>> storage, offsite archive.
>>
>> It would be foolish to badmouth a successful/free method without
>> knowing the full details. Supertars dont make you smart. If you are
>> stupid it probably doesnt matter if you have a supertar or not.
>>
>> You contribute much valuable knowledge - please try not to insult
>> people when you impart it.
>You may "have appropriate sized media, rotation strategy, archival
>process, fireproof media storage, offsite archive.", but 10 copies of
>crap is still 10 copies of crap.
>cpio or tar can NOT do bit level verifies by themselves. And if you've
>written custom C code to do verification you've spent a lot more $$ than
>one of the Supertars cost - without even touching the one-button bare
>metal restores offered by a Supertar product.
I have old C code that does bit-level verification and I didn't
write a bit of it. It took a few minutes back in the 1200BPS modem
days to get it however. :-) Warren Tucker wrote it and put in on
alt.sources back in the fall of 1990. I'm looking at it now and I
had it archived from an old Unixware 1.3 [the Red Box edition] but
I had originally had on my old Esix system.
I don't think there was a commercial version then, and I always
wondered if Warren's code inspired Steve to put it in Ctar. where I
first saw it. The post is dated November 9, 1990. But it
certainly was not as convenient as the one-button in the supertars,
and it certainly didn't mail you verification information.
I don't know why more people don't try the supertars since they all
have working downloadable demos.
Bill
Bill Vermillion
>Your bit level verify may give you confidence that the tape matched
>the data but it doesnt mean it will restore successfully.
Since the tape is rewond and read after the backup, the only way it
would not restore successfully is if the tape was damaged after the
backup or if the system had problems that prevented a restore. Why
do you say it wont restore successfully.
>There are no 100% foolproof solutions. If your tape didnt write
>correctly the log will tell you - if your sysadmin cares to
>read it - but if the failure occured before you did the next
>backup...
No need to read logs. All the supertars have email and print
utility configurations so you make sure the information gets to
the person responsible with no effort on their part. A long time
ago I had a site that would only get printouts and they changed
personel, and the new person was not aware the system should be
printing out a report each night. They went for months with no
good or verified backups. I just cc the mail to me in case the
local user doesn't read their mail.
Having these emails nightly allowed me to confirm it was a drive
problem on a machine about 1000 miles away and I arranged for a
new drive to be shipped to them - external so I could trust they
did it correctly.
Just checking on that machine I see the last failure was on
October 31, 2001. It's been chugging along for 448 days now.
The email is a system setup and you don't have to depend on a
sysadmin reading it. I send email to myself, the local person,
and the person who originally sold them that system. At least
two of the three [all of us in different geographical locations]
will act on problems immediately and we never have to worry about
someone forgetting to read a log file.
>And if you actually read carefully we do DR testing - ie the archive
>tapes are "verified" by restoring to the DR server and the system is
>tested.
How much work does that entail. And if a bit or two were flipped,
does your system check every record for accurate data? I'm curious
on this point. I can envision scenarios where some data in a record
could be corrupt and not be found unless you perform some summing
routine on each record? This is a question of curiosity - not a
criticism.
>Dont get me wrong - Supertars are great.
On the bit level verify, when restoring a system from a backup you
can also uses these to verify that the contents of the disk match
what was on the tape. I see no more than about 1/year on a tape
not-matching the HD. This can happen if a bit gets flipped/corrupted
in transit from the HD to the tape drive. At that point the CRC
written to tape will be computed for bad data so just reading a
tape at a non-bit-level mode wouldn't show an error.
On a restore you run the reverse. Make sure that the drive
contents are correct. I've not seen this error but have talked
with those who have.
>Other ways are useful and valid too. I'd rather put my money on
>the useable redundant hardware and syncronised database than the
>bit level verify software to get me back up as soon as possible
>after a disaster. Both will work.
The nice thing about the supertars is that they have recovery disks
with all the needed tools to get you running without having to
reload an OS. On a drive replacement for example, you are
typically reloading data to the drive in under 5 minutes.
>I could happily fit a supertar into my setup. But its not a priority
>as long as I have backups that demonstrably recover the data to the DR
>server. I believe that they are useful and a great tool and I commend
>you for recommending them.
Can your redundant system reload the OS to the first system, or
do you have to load the OS and then the backups. Again this is
just a question not a criticism. I had one client who was not
sure about the $300 for the supertar product, but they bought it
because I insisted. Then when working on a problem [which turned
out to be a flaky controlled] he was how much time was saved
being able to build a new filesystem and just start loading in a
few minutes. I think I reloaded the OS three times that night.
[Bad system design at the HW level with daughter boards that
weren't reliable]
Before I insisted he had that he did watch me take quite a bit of
time one other night reloading the OS just to be able to configure a
tape drive for restoration.
I only have one site where I have the luxury of backup machine, and
I do have rsync on that handling data for 3 different servers.
>
>Pat Welch <pat...@inreach.com> wrote in message news:<0hwr9.75402$NW3.19077@sccrnsc03>...
>> > James
>>
>> You may "have appropriate sized media, rotation strategy, archival
>> process, fireproof media storage, offsite archive.", but 10 copies of
>> crap is still 10 copies of crap.
>>
>> cpio or tar can NOT do bit level verifies by themselves. And if you've
>> written custom C code to do verification you've spent a lot more $$ than
>> one of the Supertars cost - without even touching the one-button bare
>> metal restores offered by a Supertar product.
>>
>> --
>> ----------------------------------------------------
>> Pat Welch, UBB Computer Services, a WCS Affiliate
>> Caldera Authorized Partner
>> Unix/Linux/Windows/Hardware Sales/Support
>> (209) 745-1401 Fax: (413) 714-2833
>> Nationwide pager: (800) 608-7122
>> E-mail: pat...@inreach.com
>> Tell the Frelling idiots at Scifi to Save Farscape!!
>> ----------------------------------------------------
D. Thomas Podnar
being perceived as biased in some way. Oh, wait, I AM biased in some
way, as I'm the owner of one of the products being mentioned.
I'm placing my comments here since Bill has a very good understanding
of the uses of professional, third party products as part of an
overall protection strategy, and my intent is to build on that vision.
Bit Level Verify is, as many point out, a wonderful feature. However
you get to use it, I'd point out that we consider it to be very
valuable, but only a small part of the overall picture.
Rsync is great, and a recommended addition to any strategy if the
resources are available.
What professional products bring to the table is not simply the
simple ACTION of creating or verfifying a backup, but the entire
PROCESS of managing system data, from a full or partial system
backup, to fast access to individual files when needed, even old
files, to a comprehensive, supportable disaster recovery strategy.
We're quite aware that we'll never change the minds of people who
are convinced that a few shell scripts and cpio are an OK stragegy,
so I won't try. For those who are only periphally aware of what a
product like ours can do, I'll simply make two observations.
1 There is a Reveiwer's Guide for our products available as a direct
link from our home page, or from this link...
ftp://ftp.microlite.com/pub/whitepapers/BackupEDGE_SS_ReviewersGuide.pdf
I would urge you to take a look to get a better understanding of
the
total strategy behind our product, and what it really encompasses
beyond simply writing files on to a tape.
2 Below is a short ;-) numbered list of most of the steps we go
through
to make a "standard" nightly backup.
Does your current backup methodology miss any of these steps? Hmmm.
Can you duplicate this if you spend enough time / money writing shell
scripts? Partially.
Can you duplicate it well enough to be "good enough"?
Maybe. It's not for me to make that decision.
Basic BackupEDGE SS procedures for doing a backup.
1 Gather information about the Resources to be used for the backup.
2 Make sure no other processes processes are running which require
the attention of the Resources (tape, CD, DVD, changer, file).
3 Determine whether the backup is to be a Master Backup,
Differential
Backup, or Incremental Backup.
4 Execute any user created pre-backup scripts.
5 Insert the proper tape in the tape drive, if changer support
is enabled.*
6 Check the device(s) to make sure that media is inserted.*
7 Check to make sure that the media are not write protected.*
8 Automatically blank and/or size any optical media requiring it.
9 Check for any queued TapeAlert messages.*
10 Check the hardware compression, hardware block size, and current
partition of the device and media.*
11 If and only if one of the above is not set to the resource
specification, adjust it.*
12 Read the label from the current media, increment it, store the
database name.
12 Print and mail a warning if last night's media is going to be
over-written.
13 Promote the backup if called for by the promotion strategy and
inserted media.
14 Rewind the media.*
15 Check for files to be included, excluded, treated as virtual,
ignored during verify, etc.
16 Begin the backup, prepending disaster recovery files if it is
to be a "Bootable Backup(tm)".
17 If more than one piece of media is required, and changer support
is enabled, insert the next piece of media and continue.
Otherwise,
notify an operator.
18 Rewind the media.*
19 Prompt for or automatically re-insert Volume One as required.
20 Check for any queued TapeAlert messages.*
21 Verify the media and index it for Fast File Restore or Instant
File Restore(tm) if requested by the scheduler.
22 If more than one piece of media is required, and changer support
is enabled, insert the next piece of media and continue.
Otherwise,
notify an operator.
23 Rewind the media.*
24 Check for any queued TapeAlert messages.*
25 Reset all device parameters back the way they were found,
if necessary.*
26 Generate a detailed Backup Report and print it to as many printers
as are defined.
27 Generate detailed mail message, in text, MIME-Encoded HTML, alpha
pager / cell phone and numeric pager formats, and send them to as
many users as are defined.
28 If an error or warning occurred, and separate lists of people and
printers are defined to receive errors and warning only, mail or
print messages to those lists.
29 Update the LogFile.
30 Execute any user created post-backup (backup passed) or
post-backup
(backup failed) scripts.
31 Remove any on-line databases for the tape overwritten by the
backup.
32 Check for and highly compress any databases over the default age
threshold (these are automatically un-compressed if accessed).
33 If changer support is enabled, return the media to its proper
storage slot.
34 If an eject strategy is enabled, eject the media as a further
confirmation that the task is complete.
35 Exit.
* BackupEDGE SS has a "dumb tape drive" mode and will resort to old
fashioned behavior when dealing with legacy devices or disk file
archives.
The noted steps are ignored.
PS For all you Compaq users out there, we're adding support for Compaq
DRTape compatible drives to our bootable media disaster recovery
capabilities (which currently include OBDR tape, CD-R/RW and
DVD[-RAM,-R,+R,+RW]).
We're currently looking for beta testers. If you'd like to
participate in the testing, visit our home page and contact me
privately.
Regards,
Tom
---
D. Thomas Podnar - President t...@microlite.com
Microlite Corporation 724-375-6711 Voice
2315 Mill Street 724-375-6908 Fax
Aliquippa PA 15001-2228 888-257-3343 Toll Free Sales
+-----------------------------------------------------------+
| Makers of |
| BackupEDGE SS - Data Archiving Software For UNIX & Linux |
| RecoverEDGE - Network-Enabled Smart Disaster Recovery |
| for Linux, Open UNIX 8, UnixWare 7.1, |
| and OpenServer 5.0.x. |
|http://www.microlite.com ftp://ftp.microlite.com|
|Now Supporting: |
| Tape, Changer, CD-R/RW, DVD-RAM, DVD-R, DVD+R, and DVD+RW |
+-----------------------------------------------------------+
James Szabadics
>
> >Your bit level verify may give you confidence that the tape matched
> >the data but it doesnt mean it will restore successfully.
>
> Since the tape is rewond and read after the backup, the only way it
> would not restore successfully is if the tape was damaged after the
> backup or if the system had problems that prevented a restore. Why
> do you say it wont restore successfully.
Im not saying it wont restore I am saying it might not for the reasons
you outlined - media problems, drive problems etc.
> Just checking on that machine I see the last failure was on
> October 31, 2001. It's been chugging along for 448 days now.
> The email is a system setup and you don't have to depend on a
> sysadmin reading it. I send email to myself, the local person,
> and the person who originally sold them that system. At least
> two of the three [all of us in different geographical locations]
> will act on problems immediately and we never have to worry about
> someone forgetting to read a log file.
Now that kind of shared responsibility is unusual. I wish our
contractors were as interested in their customers. Operational
reliability and backups are basically up to the system owner here
unless you go with IBM Global services or EDS in an outsourced IT type
scenario.
> >And if you actually read carefully we do DR testing - ie the archive
> >tapes are "verified" by restoring to the DR server and the system is
> >tested.
>
> How much work does that entail.
We verify tape contents (list and count) each backup automatically and
the results are e-mailed.
The DR tests take about 2 hours every Monday. The DR server is used
for ODBC query load sharing for the rest of the week - updates daily
via rsync.
> And if a bit or two were flipped,
> does your system check every record for accurate data? I'm curious
> on this point. I can envision scenarios where some data in a record
> could be corrupt and not be found unless you perform some summing
> routine on each record? This is a question of curiosity - not a
> criticism.
Good point - that might be a problem. The risk is probably small but
still exists.
> Can your redundant system reload the OS to the first system, or
> do you have to load the OS and then the backups. Again this is
> just a question not a criticism. I had one client who was not
> sure about the $300 for the supertar product, but they bought it
> because I insisted. Then when working on a problem [which turned
> out to be a flaky controlled] he was how much time was saved
> being able to build a new filesystem and just start loading in a
> few minutes. I think I reloaded the OS three times that night.
> [Bad system design at the HW level with daughter boards that
> weren't reliable]
No I dont think rsync can restore the OS - mind you with all the
hassle of changing hostnames in Openserver etc I dont know that it
wouldnt be quicker to install OS fresh while the system is running on
the DR hardware. I would load OS (1.5 hours) and then use rsync from
Dr server to repaired server to restore the database - that part takes
just over 20 mins on the gigabit fibre. Total of 2 hours.
> Before I insisted he had that he did watch me take quite a bit of
> time one other night reloading the OS just to be able to configure a
> tape drive for restoration.
>
> I only have one site where I have the luxury of backup machine, and
> I do have rsync on that handling data for 3 different servers.
I reckon rsync is a very usefull tool!
James Szabadics
>
> >
> > You contribute much valuable knowledge - please try not to insult
> > people when you impart it.
>
> If you ARE doing something stupid (and every one of us does that), it
> isn't insulting for someone else to say so.
>
> BTW, I object a bit to your fretting about someone else's feelings. If
> the original poster had his ego bruised by my response, he never said so.
>
> Why do you feel the need to be the guardian of political correctness here?
>
> Oh, well. Go in peace. I hope your backup scheme always works for you.
Tony,
just for the record.
I am NOT and do not want to be the guardian of PC here - I made a
one-line comment that you must be having a bad day because the
original post had a tone of intolerance. When you didnt understand
the comment and verbalised further without adding to the original
advice to use a supertar I explained my comment. Supertars are a good
thing. Better than my scripts I'll admit. Is my data safe enough - I
believe the risk is acceptably small.
Yes you did confuse me with someone else (with a totally disimilar
name) re tape drives thread - I didnt understand what was your point
regarding my setup?
You dont need to be sorry I havent taken any offence. Just relax a
little.
Your advice re supertars is accurate and useful. Harping on at length
about how you feel about the poster is superflous BS. My advice re
tone of your posting is just that advice - dont take it personally.
Regards
James
Tony Lawrence
> b...@wjv.comREMOVE (Bill Vermillion) wrote in message news:<H44wp...@wjv.com>...
>>And if a bit or two were flipped,
>>does your system check every record for accurate data? I'm curious
>>on this point. I can envision scenarios where some data in a record
>>could be corrupt and not be found unless you perform some summing
>>routine on each record? This is a question of curiosity - not a
>>criticism.
>
>
> Good point - that might be a problem. The risk is probably small but
> still exists.
You'd probably be surprised how often a bit level verify proves useful.
As Bill does, I receive backup status email for several of my clients,
so I can tell you that bit-level verification "failures" ( failure of
one or more files to match the hard drive- not a complete backup
failure) are not all that uncommon. Once in a while it's due to
incipient tape failure, and it's very helpful to see a problem
developing before it gets serious- if we're lucky the really important
files aren't the ones the tape had trouble with.
Quite often the failure is due to unexpected activity on the system
during the backup. Usually it's explainable, but a couple of times in
my long history it has been an employee up to no good after hours and
the bit-level verify helped show what they were doing.
Once or twice the bit-level verify has alerted us to incipient hard
drive failures. Those usually would have been spotted by other means
too, but it never hurts to have multiple channels of alerts. As someone
said, if it's REALLY important that you get up at 4:00 AM tomorrow, you
set two alarm clocks AND have the hotel desk call you.
Now and then we get "cosmic ray" failures. It's probably really just a
wayward piece of dust finding its way to the tape, but the point is that
one file fails to verify and we can't see any reason why. We always get
suspicious of the tape of course, but sometimes it just goes away and
the tape continues on for months. Just because of the odds, such
failures are usually an unimportant or easily recreated file, but once
in a great while it hits something very important, and that's when we're
very happy to have the knowledge that, if we should need it, Tuesday's
tape is NOT suitable for restoration because that important file is
suspect. The point here of course is the KNOWLEDGE: we KNOW there is a
problem on this tape. We probably don't need the tape (not planning on
trashing the system today) but if we DID need it, we know that it has a
problem.
And yes, we often do other things too. For convenience and redundancy I
often have rsync or similar things tucking important bits of data here
and there around the network. On really important systems we have more
than one system that does tape or dvdram backup and lots of cross
pollenization between the systems- it doesn't cost a lot to do this kind
of thing and the peace of mind is much improved.
But always I have Supertars. Don't leave home without it. Whenever I
pick up a new customer, I insist on it. I wish I had it for NT systems!
Bill Vermillion
>> >Your bit level verify may give you confidence that the tape matched
>> >the data but it doesnt mean it will restore successfully.
>> Since the tape is rewond and read after the backup, the only way it
>> would not restore successfully is if the tape was damaged after the
>> backup or if the system had problems that prevented a restore. Why
>> do you say it wont restore successfully.
>Im not saying it wont restore I am saying it might not for the reasons
>you outlined - media problems, drive problems etc.
Well if you use standard based machines you can always replace the
tape drive. If it's an HD problem, drop in a new HD, use the
supertar utilites to set your drive to the same file systems layout
you had before and load the OS from tape - all taking about 5
minutes. Until you have to do it, you really can appreciate how
good these tools are.
>> Just checking on that machine I see the last failure was on
>> October 31, 2001. It's been chugging along for 448 days now.
>> The email is a system setup and you don't have to depend on a
>> sysadmin reading it. I send email to myself, the local person,
>> and the person who originally sold them that system. At least
>> two of the three [all of us in different geographical locations]
>> will act on problems immediately and we never have to worry about
>> someone forgetting to read a log file.
>Now that kind of shared responsibility is unusual. I wish our
>contractors were as interested in their customers. Operational
>reliability and backups are basically up to the system owner here
>unless you go with IBM Global services or EDS in an outsourced IT type
>scenario.
Not unusual considering the backgrounds of all involved. We're in
the running to be the worlds smallest ISP - but the data leaving
the servers that I maintain locally and the data can't travel more
than about 500 feet before it's on a 10GB global tier 1 network.
So we pulled a major standards organization site from a major
provider because we could do things others seemed not to be able to
do. [The ftp structure has a strange looking hierarchy at first
glance with what appear to be inverted permissions - but it works
as they wanted it to, where others couldn't make it work that way]
All of us [the clients and those who run the site] are all
ex-broadcasters. You never get a chance to do anything again and
often 1 second late is too late.
>> >And if you actually read carefully we do DR testing - ie the archive
>> >tapes are "verified" by restoring to the DR server and the system is
>> >tested.
>> How much work does that entail.
>We verify tape contents (list and count) each backup automatically and
>the results are e-mailed.
>The DR tests take about 2 hours every Monday. The DR server is used
>for ODBC query load sharing for the rest of the week - updates daily
>via rsync.
Make sense.
>> And if a bit or two were flipped,
>> does your system check every record for accurate data? I'm curious
>> on this point. I can envision scenarios where some data in a record
>> could be corrupt and not be found unless you perform some summing
>> routine on each record? This is a question of curiosity - not a
>> criticism.
>Good point - that might be a problem. The risk is probably small but
>still exists.
It's always those small improbabilites that get us in the end, no
matter what we are involved with.
>> Can your redundant system reload the OS to the first system, or
>> do you have to load the OS and then the backups. Again this is
>> just a question not a criticism. I had one client who was not
>> sure about the $300 for the supertar product, but they bought it
>> because I insisted. Then when working on a problem [which turned
>> out to be a flaky controlled] he was how much time was saved
>> being able to build a new filesystem and just start loading in a
>> few minutes. I think I reloaded the OS three times that night.
>> [Bad system design at the HW level with daughter boards that
>> weren't reliable]
>No I dont think rsync can restore the OS - mind you with all the
>hassle of changing hostnames in Openserver etc I dont know that it
>wouldnt be quicker to install OS fresh while the system is running on
>the DR hardware. I would load OS (1.5 hours) and then use rsync from
>Dr server to repaired server to restore the database - that part takes
>just over 20 mins on the gigabit fibre. Total of 2 hours.
Hm. I can envision you being able to user a supertar in this
mix. Use it to get the base system up and running - as I said
before it's about 5 minutes. When I'd do work on a client system
I'd unmount all except the OS and make a backup. That way if
something went wrong [ usually a vendor driver did it - and at
times would nuke a system ] I'd just put in the boot floppy, and
reload the OS from the DAT drive. That took about 10 minutes
after remaking the / filesystem and I knew I was at a known
point.
Do that with a supertar on your system and you could be rsyncing the
data back to the server in only about 10 minutes instead of 1.5
hours. That might be a combination strategy to look into.
The ability to completely reload an OS with all the drivers, tape
config, etc, just as it was to start with , in just minutes is
someting you appreciate the first time you don't have to spend 1.5
hours reloading the OS, and configiruing the NICs and tape drives.
>> I only have one site where I have the luxury of backup machine, and
>> I do have rsync on that handling data for 3 different servers.
>I reckon rsync is a very usefull tool!
And often overlooked. I've run across more than one person who
says "I tar up the file and ftp it to another machine" or "I just
backup to another machine" - and in most of those cases about 95%
of the data already exists. That's the joy of rsync, you only move
data that has changed. [You know that but in case someone else
reading this is not familiar with is why I mention it]
Thanks for the info.
Bill
James Szabadics
This discussion has proved somewhat enlightening.
I think I have to consider one of the supertars more closely. I will
download a couple if there are demos and give it a workout on the DR
box. I want to try the OS reload. The ability to discover impending
tape failure and the bit level error checking is the weakness in our
current system.
I will report back for the record.
james
b...@wjv.comREMOVE (Bill Vermillion) wrote in message news:<H476u...@wjv.com>...
Tony Lawrence
> Wow - thanks to both Tony and bill on your latest postings....
>
> This discussion has proved somewhat enlightening.
>
> I think I have to consider one of the supertars more closely. I will
> download a couple if there are demos and give it a workout on the DR
> box. I want to try the OS reload. The ability to discover impending
> tape failure and the bit level error checking is the weakness in our
> current system.
>
> I will report back for the record.
I had a bad one yesterday. Compaq server drive failure. They've used
Microlite Edge for some time, but this year I had upgraded them to DVDRAM.
The DVDRAM wouldn't boot. Naturally, they called me :-)
I didn't remember any boot sequence settings in the bios, but I had them
look just the same and they couldn't see anything. These telephone
support calls are apt to be frustrating- I want to put my hands on the
darn thing and can't. Anyway, no luck there, so we went over the
possibilities: had they perhaps shut off the instruction to create the
bootable dvd? No, and to prove that they still had the original dvd I
had created when I installed and tested it. That wouldn't boot either.
As this is a well equipped place, I then asked them to move the
(external fortunately) dvdram to another macbhine. It booted there, so
now we knew the problem was back at the Compaq.
As it happens, a Compaq service rep lives nearby and they have a
friendly relationship and were able to get him to pop over to take a
look. He did, and we talked a bit, but he couldn't get it to boot on
the Compaq either.
So at this point I suggested doing an reinstall of SCO, a reinstall of
Microlite Edge and then restoring the DVD. Not a great way to proceed,
as it's very time consuming and this is a system that collects real time
data.
However, the client found a set of older (pre dvdram) Edge boot disks.
I wouldn't have expected these to work, but I forgot that for reading, a
dvdram is treated just like a cdrom, so it's a good thing that he just
went ahead and tried them without asking me. I probably would have told
him not to bother, but since he didn't have the benefit of my temporary
stupidity, he went ahead and used the floppies and got a successful
restore very quickly.
Another Supertar success story!
Bill Vermillion
James Szabadics <jm...@wespine.com.au> wrote:
>Wow - thanks to both Tony and bill on your latest postings....
You are welcome.
>This discussion has proved somewhat enlightening.
>I think I have to consider one of the supertars more closely. I will
>download a couple if there are demos and give it a workout on the DR
>box. I want to try the OS reload. The ability to discover impending
>tape failure and the bit level error checking is the weakness in our
>current system.
There are working useable demos at both www.microlite.com [For
BackupEdge and related programs] and www.cactus.com [For Lone-Tar
and all it's tools].
Between those two programs you'll be hard pressed to find a Unix or
Unix-like system that isn't supported.
Try them both and see what one works best for you.