------ script start --------
#/bin/bash
# Backup script.
echo "" > /var/log/backup.txt
echo "Backup logg for `date` on ITGOSLO Tourplan server" >>
/var/log/backup.txt
echo " " >> /var/log/backup.txt
echo "Enabling Compression on tape drive" >> /var/log/backup.txt
echo " " >> /var/log/backup.txt
tape -a 3 setcomp /dev/rct0 >> /var/log/backup.txt
tape getcomp /dev/rct0 >> /var/log/backup.txt
sleep 3
tape erase >> /var/log/backup.txt
echo "Getting status of backup, if this does not exists, backup has not
run!" >> /var/log/backup.txt
echo " " >> /var/log/backup.txt
tape status >> /var/log/backup.txt
echo " " >> /var/log/backup.txt
echo "Starting backup of server (Complete)..."
sleep 3
find /app -depth -print | cpio -ovcuB -O /dev/rct0
sleep 3
echo "Backup Complete if Tape Status exists, else failed" >>
/var/log/backup.txt
mailx -s "Backuplog from ITG" fre...@mymaildomain.no < /var/log/backup.txt
-------------- end of script -------------
This script tells me nothing of the backup has run as it should, therefor i
would like to do like a "ls" ore something on the tape, read whats on the
tape and add it to my backup logg.
Anyone have some tips for me, changes i should do, better sollutions etc..
please come with it :-)
Cheers!
/Ulven
FAR better solution: http://aplawrence.com/Reviews/supertars.html
My suspicion is that you got that script from someone else. I say that
because if you knew enough to write that, you would know how to list the
tape at least, but you don't.
So you are using a script you really don't understand. Frankly, it's a
crappy script.
Do you understand that it is NOT backing up your server but only one
directory?
Do you understand that the "tape erase" is probably unnecessary and a
waste of time?
How about that the "setcomp" is done on the wrong device?
Do you understand that the "Backup Complete if Tape Status exists, else
failed" message is absolutely untrue? You backup could fail in all
sorts of ways that this script would never catch.
Do you understand that even the listing you requested WOULD NOT
guarantee the integrity of the backup at all?
So.. do you REALLY want to trust backup to this sort of scripting?
BTW, I'm not trying to beat up on you for not knowing this stuff.
That's OK- every one of us started out not knowing anything, and most of
us still have tremendous gaps in our knowledge. My purpose in asking
these questions is not to embarass you, but to show you the defects of
the script.
Most of us here are capable of writing scripts that would work far
better than that rather pathetic thing. Yet, we don't. Just about
every qualified person here uses one of the supertar products for their
important servers. Why? Because we ARE NOT capable of doing anything
half as good as what the professionals do.
Let me tell you how important it is. Because I'm rather well known and
publish reviews of this stuff, and resell the products, I can (and do)
get free copies of these things for my internal use. IN SPITE OF THAT I
PURCHASE MY OWN. I use the review copies for reviews and test boxes,
but having good backup is so important to me that I pay for what I also
get free. My wife thinks I am nuts, and probably the Supertar folks
do too, but it does tell you something, doesn't it?
IF YOUR DATA HAS VALUE IT IS WORTH SPENDING MONEY TO PROTECT IT.
There are many thousands of engineering man hours put in by the various
supertar vendors to test and perfect their products They think about
problems that you and I have never seen. The products have been refined
for years and years now, getting better with each iteration. These
things have as much relationship to that script as a Model T Ford has to
a modern Ferrari. There's no exaggeration there either.
Yep, this is turning into a rant :-)
Not picking on you now, but I am SO tired of people coming here looking
for backup scripts. THERE'S NO SUCH THING AS A REALLY GOOD BACKUP
SCRIPT! You really CANNOT do it with shell scripting, tar and cpio.
You MIGHT be able to come close to what the supertars do by clobbering
together some other open source stuff, but if you had the necessary
expertise to do that well, you wouldn't need to come here and ask
questions about it.
I trust my backups to professionals. Most and maybe all of the
knowledgeable folk here on the ng do the same. Again, you come here
looking for advice from knowledgeable people, but we DON'T use that kind
of scripting for important backups, we use the supertars. If you are
not as knowledgeable as the regular posters here, shouldn't you do the
same? Yes, you should.
Oh, one more thing Do you really think that mail harvesting bots are
too stupid to automatically remove "REMOVESPAM" from
fre...@REMOVESPAMulven.com ? Such techniques are completely useless and
serve no purpose other than to annoy humans who want to reply to you. I
can absolutely guarantee that every harvesting bot out there does the
equivalent of Perl s/REMOVESPAN//i and other obvious cleanups. I
personally see no value to such obfuscation at all, but if you think you
have to doit, more cleverness (and thus more annoyance for humans) is
needed. How about "notfredbu...@ulven.com". or
"betterto...@ulven.com". Those might work for a while. You also
really shouldn't mess with the domain because it causes wasted dns
lookups.
--
Please note new phone number: (781) 784-7547
Tony Lawrence
Unix/Linux Support Tips, How-To's, Tests and more: http://aplawrence.com
Free Unix/Linux Consultants list: http://aplawrence.com/consultants.html
Ron
The reasen for me to ask here is to get some help and tips from someone that
can tell a better sollution, so i am greatful for the tips that you come
with here to use supertar insted of cpio.
My skills on unix is LOW, but i'm the one in our business that knows most
about it becourse i'm having a linux server at home that i have set up and
configured(with some help yes).
The reasen for that we have this unix server is only becourse that app that
runs on it is only available for unix.. if it had'nt been for that we would
not be using unix.
All i want it to get a backup sollution to work.. i have been worked on it
for about one year or so without getting it to work.
My boss don't want to hire in someone to fix it, if so i'm the one that have
to pay for person if so. (long story, don't ask. hehe)
Therefor i'm trying to get it to work.
The script have i made myselfe, but i have taken the command "find
/ -depth -print | cpio -ovcuB -O /dev/rct0" from a tip i got from someone
here. It seems to run, it lists all up, and tape begings to spinn.
It says that folder "/app" is what to backup, in my script thats changed to
/ now, it was /app only for testing.
"Tony Lawrence" <to...@pcunix.com> wrote in message
news:3DD4F007...@pcunix.com...
>
> FAR better solution: http://aplawrence.com/Reviews/supertars.html
Thanks for that! i'll look into it!
> My suspicion is that you got that script from someone else. I say that
> because if you knew enough to write that, you would know how to list the
> tape at least, but you don't.
I know a little about scripting, by copy and paste.. adding my own values
etc.
> So you are using a script you really don't understand. Frankly, it's a
> crappy script.
Thanks!
> Do you understand that it is NOT backing up your server but only one
> directory?
Yes, for testing i changed it into /app only for reducing the time backup
uses.
> Do you understand that the "tape erase" is probably unnecessary and a
> waste of time?
Realy? I did'nt know that, from "man tape" i understood it as a command to
clean the tape for data.
> How about that the "setcomp" is done on the wrong device?
Its correct device!
> Do you understand that the "Backup Complete if Tape Status exists, else
> failed" message is absolutely untrue? You backup could fail in all
> sorts of ways that this script would never catch.
I know that, thaths only a text i added for putting in info.. the info is
sent to myselfe!
> Do you understand that even the listing you requested WOULD NOT
> guarantee the integrity of the backup at all?
i know, therefor i want to see whats on my tape!
> So.. do you REALLY want to trust backup to this sort of scripting?
If this works, thats what i need. if this does not work, i have to look for
something else!
> BTW, I'm not trying to beat up on you for not knowing this stuff.
> That's OK- every one of us started out not knowing anything, and most of
> us still have tremendous gaps in our knowledge. My purpose in asking
> these questions is not to embarass you, but to show you the defects of
> the script.
Well, you just did!
My knowledge in sco unix sux, (and probably my english wring to! *lol*)
but i'm trying to learn!
> Most of us here are capable of writing scripts that would work far
> better than that rather pathetic thing.
Thanks!
> Yet, we don't. Just about
> every qualified person here uses one of the supertar products for their
> important servers. Why? Because we ARE NOT capable of doing anything
> half as good as what the professionals do.
How much do you guys charge to write a script thats works, how much will it
cost?
> Let me tell you how important it is. Because I'm rather well known and
> publish reviews of this stuff, and resell the products, I can (and do)
> get free copies of these things for my internal use. IN SPITE OF THAT I
> PURCHASE MY OWN. I use the review copies for reviews and test boxes,
> but having good backup is so important to me that I pay for what I also
> get free. My wife thinks I am nuts, and probably the Supertar folks
> do too, but it does tell you something, doesn't it?
>
> IF YOUR DATA HAS VALUE IT IS WORTH SPENDING MONEY TO PROTECT IT.
Offcourse!
> There are many thousands of engineering man hours put in by the various
> supertar vendors to test and perfect their products They think about
> problems that you and I have never seen. The products have been refined
> for years and years now, getting better with each iteration. These
> things have as much relationship to that script as a Model T Ford has to
> a modern Ferrari. There's no exaggeration there either.
>
> Yep, this is turning into a rant :-)
:-)
> Not picking on you now, but I am SO tired of people coming here looking
> for backup scripts. THERE'S NO SUCH THING AS A REALLY GOOD BACKUP
> SCRIPT! You really CANNOT do it with shell scripting, tar and cpio.
> You MIGHT be able to come close to what the supertars do by clobbering
> together some other open source stuff, but if you had the necessary
> expertise to do that well, you wouldn't need to come here and ask
> questions about it.
I'm sorry for all the peoples that comes here and asks for backup scripts, i
tried to search for one, but did not find any.
Therefor i asked for some tips, and i got! thanks!
From your wrint i understand that i should by a backup software product, but
from others i was told that i can use cpio or tar, or dump to backup my
data. Then i thought "ok then" and starts looking for a script that works.
> I trust my backups to professionals. Most and maybe all of the
> knowledgeable folk here on the ng do the same. Again, you come here
> looking for advice from knowledgeable people, but we DON'T use that kind
> of scripting for important backups, we use the supertars. If you are
> not as knowledgeable as the regular posters here, shouldn't you do the
> same? Yes, you should.
On Windows NT/2000 servers, we ONLY use like BackupExec from Veritas, or
ArcServe to backup our data. And we have procedures to check the tapes
several times a week to verify that backup is OK for our customers.
But we do not know enough about unix server to do the same, but we should be
able to do it, therefor i have to learn how to take backup, restore data,
verify that backup is OK etc.
After reading your message i understand that i should stop trying with cpio
and tar etc, and go for a backup software sollution.
but, our default wendors for backup program, Veritas and CA does not sell
programs for unix, only found some agents for unix.
I someone here don't have any other sollutions i have to call them and ask
for products.
Or i can look into supertar, but i understood that this is not good enough
to... (or not the perfect sollutions).
> Oh, one more thing Do you really think that mail harvesting bots are
> too stupid to automatically remove "REMOVESPAM" from
> fre...@REMOVESPAMulven.com ? Such techniques are completely useless and
> serve no purpose other than to annoy humans who want to reply to you. I
> can absolutely guarantee that every harvesting bot out there does the
> equivalent of Perl s/REMOVESPAN//i and other obvious cleanups. I
> personally see no value to such obfuscation at all, but if you think you
> have to doit, more cleverness (and thus more annoyance for humans) is
> needed. How about "notfredbu...@ulven.com". or
> "betterto...@ulven.com". Those might work for a while. You also
> really shouldn't mess with the domain because it causes wasted dns
> lookups.
Well, just ignore that then, thats my problem! it works fine this far!
I'll change it, or don't put in my address at all later...
> --
>
> Please note new phone number: (781) 784-7547
>
> Tony Lawrence
> Unix/Linux Support Tips, How-To's, Tests and more: http://aplawrence.com
> Free Unix/Linux Consultants list: http://aplawrence.com/consultants.html
>
Best Regards,
Freddy Ulvseth
btw: I changed my script a little...
#################################################################
#
#
# Backup script by Ulven
#
#
#
# Version 1.0 (Sept. 2002)
#
# Created by: Freddy Ulvseth
#
#
#
#################################################################
#
# Variables to change server name, tape device, etc
TAPE=/dev/rct0
SERVER=ITGOSLO
LOG=/var/log/backup.txt
MAIL=ma...@address.no
#
# Cleaning backup log file and creating a new file with time and date.
echo "" > /var/log/backup.txt
echo "Backup logg for `date` on $SERVER Tourplan server \n \n" >>
/var/log/backup.txt
#
# Enabling compression option on tape drive, and enabling if not enabled
tape -a 3 setcomp /dev/rct0 >> /var/log/backup.txt
echo "Enabling Compression on tape drive\n Comp. status:\n" >>
/var/log/backup.txt
tape getcomp /dev/rct0 >> /var/log/backup.txt
sleep 3
#
# Erasing and retensioning the tape (Tape maintenence)
tape erase >> /var/log/backup.txt
#
# Checking status of tape drive and wring to log file
echo "Checking status of backup drive. \n \n" >> /var/log/backup.txt
tape xstatus $TAPE >> /var/log/backup.txt
tape getblk $tape >> $LOG
tape getpart $tape >> $LOG
#
# Running backup of content to tape
echo "Starting backup of server (Complete)... \n \n" >>
/var/log/backup.txt
find / -depth -print | cpio -ovcuB -O $TAPE
sleep 3
tape amount $TAPE >> $LOG
echo "Completed running cpio on $SERVER" >> /var/log/backup.txt
#
# Adding info to baclup log file
echo "Backup Completed at `time`. \n" >> /var/log/backup.txt
echo "To see if backup has completed as it should, look for the
following:" >> /var/log/backup.txt
echo "Tape status: should be Ready at beginning of tape" >>
/var/log/backup.txt
echo "Time between start and complete should take about 30-90minutes" >>
/var/log/backup.txt
#
# Sending mail log to following address
mailx -s "Backuplog from $SERVER has run, check mail for resault." $mail <
/var/log/backup.txt
#
# Script Complete
Good! Then you understand that the native backup procedures are not
the way to go (cpio, tar, dump in SCO)
>
>After reading your message i understand that i should stop trying with cpio
>and tar etc, and go for a backup software sollution.
>but, our default wendors for backup program, Veritas and CA does not sell
>programs for unix, only found some agents for unix.
>I someone here don't have any other sollutions i have to call them and ask
>for products.
>Or i can look into supertar, but i understood that this is not good enough
>to... (or not the perfect sollutions).
'Supertar' is not a product, it is a concept, and is the only REAL
solution if you value your data (So yes, it is 'good enough'!). The 2
most frequently mentioned supertar products (in this NG, at least)
are:
Lone-Tar http://www.cactus.com
Backup Edge http://www.microlite.com
What the SuperTars give you that cpio/tar/dump can't (To borrow from
our own Mr. Lawrence's review):
Backup everything, including device files, named pipes, etc.
Support for backing up raw partitions and sparse files
Support for file locking
Intelligent support for media errors (both disk and tape)
Non-proprietary compression optional
Backup across the network
Use multiple tape drives
True bit-level verification
Menu driven operation
Point and click restores (assuming GUI available)
Tape labeling
Tape indexing for fast restores
Boot recovery diskettes that can recreate disk partitions and
divisions for simple restore without reinstallation.
Point being, if you value your data, then let the professionals handle
your backups. You may get your script to work, but, you won't KNOW
that your script worked until the day you have to restore from the
tape. I certainly wouldn't want that kind of pressure!
You already use a 3rd party backup product on your Windows platforms,
the same logic applies on the SCO Unix system(s).
Scott McMillan
Yes, no question about that :-)
> >
> >After reading your message i understand that i should stop trying with
cpio
> >and tar etc, and go for a backup software sollution.
> >but, our default wendors for backup program, Veritas and CA does not sell
> >programs for unix, only found some agents for unix.
> >I someone here don't have any other sollutions i have to call them and
ask
> >for products.
> >Or i can look into supertar, but i understood that this is not good
enough
> >to... (or not the perfect sollutions).
>
> 'Supertar' is not a product, it is a concept, and is the only REAL
> solution if you value your data (So yes, it is 'good enough'!). The 2
> most frequently mentioned supertar products (in this NG, at least)
> are:
ok, i see...
> Lone-Tar http://www.cactus.com
> Backup Edge http://www.microlite.com
i've start looking at microlite's edge. I'll try to install that..
If it works, i'll talk my boss into bying a license for it.
> What the SuperTars give you that cpio/tar/dump can't (To borrow from
> our own Mr. Lawrence's review):
>
> Backup everything, including device files, named pipes, etc.
> Support for backing up raw partitions and sparse files
> Support for file locking
> Intelligent support for media errors (both disk and tape)
> Non-proprietary compression optional
> Backup across the network
> Use multiple tape drives
> True bit-level verification
> Menu driven operation
> Point and click restores (assuming GUI available)
> Tape labeling
> Tape indexing for fast restores
> Boot recovery diskettes that can recreate disk partitions and
> divisions for simple restore without reinstallation.
Great, just as our other backup programs works..
>
> Point being, if you value your data, then let the professionals handle
> your backups. You may get your script to work, but, you won't KNOW
> that your script worked until the day you have to restore from the
> tape. I certainly wouldn't want that kind of pressure!
>
> You already use a 3rd party backup product on your Windows platforms,
> the same logic applies on the SCO Unix system(s).
>
Yepps, i understand that.. well.. at least i now knew why i should go for a
product...
We try to use as much as operationg system as possible, with Windows 2000
there is a good enough backup program that works for a server like this..
It's Veritas that have made that product to microsoft.. but with less
options..
I thought i could use cpio or tar in the same way as the internat backup
program with windows. (NT Backup).
as i said, i have started to look into Edge's backup program.
i don't know how far with the setup i get before it stops.. but i'll try!
:-)
Thanks!
Cheers!
/Freddy Ulvseth
Well, you must be paid very, very little if your time hasn't cost more
than $300.00 attempting to do this.
> Therefor i'm trying to get it to work.
>
> The script have i made myselfe, but i have taken the command "find
> / -depth -print | cpio -ovcuB -O /dev/rct0" from a tip i got from someone
> here. It seems to run, it lists all up, and tape begings to spinn.
> It says that folder "/app" is what to backup, in my script thats changed to
> / now, it was /app only for testing.
>
>
> "Tony Lawrence" <to...@pcunix.com> wrote in message
> news:3DD4F007...@pcunix.com...
>
>>FAR better solution: http://aplawrence.com/Reviews/supertars.html
>
>
> Thanks for that! i'll look into it!
>
>
>>My suspicion is that you got that script from someone else. I say that
>>because if you knew enough to write that, you would know how to list the
>>tape at least, but you don't.
>
>
> I know a little about scripting, by copy and paste.. adding my own values
> etc.
>
>
>>So you are using a script you really don't understand. Frankly, it's a
>>crappy script.
>
>
> Thanks!
No offense meant.
>
>>Do you understand that the "tape erase" is probably unnecessary and a
>>waste of time?
>
>
> Realy? I did'nt know that, from "man tape" i understood it as a command to
> clean the tape for data.
You don't need to clean it of data. New data will overwrite the old.
Even if you write less than what was there before, the old is gone for
all normal purposes.
>
>
>>How about that the "setcomp" is done on the wrong device?
>
>
> Its correct device!
No, it is not. The correct device is /dev/xct0.
>
>
>>Do you understand that the "Backup Complete if Tape Status exists, else
>>failed" message is absolutely untrue? You backup could fail in all
>>sorts of ways that this script would never catch.
>
>
> I know that, thaths only a text i added for putting in info.. the info is
> sent to myselfe!
>
>
>>Do you understand that even the listing you requested WOULD NOT
>>guarantee the integrity of the backup at all?
>
>
> i know, therefor i want to see whats on my tape!
SEEING WHAT'S ON THE TAPE DOESN'T TELL YOU THE BACKUP IS ANY GOOD!
Sorry for shouting but that's important to understand. Listing the tape
works somewhat like this:
Read along, expecting to find header information that gives the file
name, permissions etc. and how big it is. Display that info and then..
read the filesize many bytes, totally ignoring the contents, and then
expect to read another header.
It's not a verify. The data could be repetitive blocks of "nay-ya! lost
your data!" and you'd never know. The supertars COMPARE that data to
the original file.
>
>
>>So.. do you REALLY want to trust backup to this sort of scripting?
>
>
> If this works, thats what i need. if this does not work, i have to look for
> something else!
(sigh). That's what I'm trying to tell you. It DOESN'T work.
>
>
>>BTW, I'm not trying to beat up on you for not knowing this stuff.
>>That's OK- every one of us started out not knowing anything, and most of
>>us still have tremendous gaps in our knowledge. My purpose in asking
>>these questions is not to embarass you, but to show you the defects of
>>the script.
>
>
> Well, you just did!
No, I didn't. I just gave you information about why your script isn't
useful.
> My knowledge in sco unix sux, (and probably my english wring to! *lol*)
> but i'm trying to learn!
Good. First lesson: don't write your own backup scripts. Second
lesson: visit http://aplawrence.com/newtosco.html and proceed from there.
>
>>Most of us here are capable of writing scripts that would work far
>>better than that rather pathetic thing.
>
> Thanks!
>
>
>>Yet, we don't. Just about
>>every qualified person here uses one of the supertar products for their
>>important servers. Why? Because we ARE NOT capable of doing anything
>>half as good as what the professionals do.
>
>
> How much do you guys charge to write a script thats works, how much will it
> cost?
Again: http://aplawrence.com/Reviews/supertars.html. Commercial
products, appx $300.00 though often discounted.
>
> On Windows NT/2000 servers, we ONLY use like BackupExec from Veritas, or
> ArcServe to backup our data. And we have procedures to check the tapes
> several times a week to verify that backup is OK for our customers.
> But we do not know enough about unix server to do the same, but we should be
> able to do it, therefor i have to learn how to take backup, restore data,
> verify that backup is OK etc.
Right. I personally think Arcserve is not that great, but it's
certainly better than anything I could write myself on NT.
>
> After reading your message i understand that i should stop trying with cpio
> and tar etc, and go for a backup software sollution.
> but, our default wendors for backup program, Veritas and CA does not sell
> programs for unix, only found some agents for unix.
That's not a bad idea either, though the supertars have more features
like crash recovery).
> I someone here don't have any other sollutions i have to call them and ask
> for products.
> Or i can look into supertar, but i understood that this is not good enough
> to... (or not the perfect sollutions).
Understood from whom????
Did you READ the links I sent you to???
If you have ANY problem, just send them an email- they will respond.
Either/or. If you have ANY problems with either, email or call their
respective support departments. Both companies offer great support,
from what I've heard.
A bonus: Representatives of each company post in this NG frequently -
Look for
Jeff Hyman - Cactus Software (Still? Haven't seen him around here in
awhile)
-and-
Thomas Podnar - Microlite
AFAIK, each company provides a fully-functional XX-day trial, so it
should work without much hassle. Getting through all of the menu
options and understanding where/what/how may take some time to fully
comprehend, but in the end you WILL have a useable backup.
>:-)
>
>Thanks!
>
>Cheers!
>
>/Freddy Ulvseth
>
Scott McMillan
> as i said, i have started to look into Edge's backup program.
> i don't know how far with the setup i get before it stops.. but i'll try!
This is just a curiousity question. Edge is a good choice.
But, what made you choose Edge over the others? The
http://aplawrence.com/Reviews/supertars.html article I sent you to
mentions 3 products, in alphabetical order because I don't want any of
my personal prejudices to influence other peoples choices. I have
reviews of two of the products also, and I don't think I've indicated
any favorites there either.
I do think that each of these products, although very similar, fits
different needs and different personalities, and I suspect that their
web pages appeal differently also.
Again this is just curiousity: did you go to the web pages of each and
look them over? I'm sure both Jeff and Tom would be interested in how
their respective marketing affected you.
>FAR better solution: http://aplawrence.com/Reviews/supertars.html
I agree your recommandation to supertars.
But i made -years ago- bad expirience with "propiety"
backup formats not beeing readable by other software...
How "compatible" are those tapes (today)?
Currently one .com-company or software vendor or unix after
the next "dies".
What if one bought a "supertape" software, changed system
and has to recover a tape made serveral years ago (had that in
a patent case) and can't get a running version of the supertar
used then?
Can it be recovered using any standard cpio or tar or ?
Or is the reader/restore open source or sufficient documented?
Good point. Experience has shown that this happens more often than we
would like, and portability can suffer when using 3rd party products.
We produce a Dental Management software package, sold nationwide. For
updating our customers, we use the native SCO tar to create media.
Then it's just a matter of using media that the customer's tape drive
will be compatible with. Very portable. (Actually, more than 75% of
our customers get CDs created with CDRecord - much more portable.)
The idea that started this thread was a _backup_ of a system. At that
point, I assumed - maybe incorrectly - that whatever tape created on
that system would be used to restore _that_ system. It is in this
case that the SuperTars are much more reliable/efficient than the
native OS options. (Note: The supertars also give you the ability to
restore that tape onto a different system, even with differing HD
controllers)
Anyway, portability _can_ be a potential problem. In Lone-Tar's case,
it claims it "is tar compatiable for restoring data." (whatever the
heck "compatiable" is!) http://www.lonetar.com/products/lonetar.html
I don't know about BackupEdge or Ctar (or any others, for that
matter). I have actually used the native SCO tar to read tapes
created with Lone-Tar, but that was many moons ago...
Scott McMillan
They are NOT proprietary. They all use "tar" format. If you use
software compression, they use standard compression tools: if you had
to, you could extract the files with tar, rename them temporarily and
uncompress them using standard uncompress.
>On our SCO server, the way i'm taking backup of the server works with
>this script.
>------ script start --------
>#/bin/bash
># Backup script.
> echo "" > /var/log/backup.txt
> tape -a 3 setcomp /dev/rct0 >> /var/log/backup.txt
> tape getcomp /dev/rct0 >> /var/log/backup.txt
> tape erase >> /var/log/backup.txt
> tape status >> /var/log/backup.txt
> find /app -depth -print | cpio -ovcuB -O /dev/rct0
> mailx -s "Backuplog from ITG" fre...@mymaildomain.invalid < /var/log/backup.txt
>-------------- end of script -------------
>This script tells me nothing of the backup has run as it should,
The script is very, emm, elementary... ;-)
Only a "quick hack" but nothing one should call "backup".
>therefor i would like to do like a "ls" ore something on the tape,
>read whats on the tape and add it to my backup logg.
>Anyone have some tips for me, changes i should do, better sollutions
>etc.. please come with it :-)
If you never wallpapered a room, emm, use a supertar ;-)
On the other hand if you have time and want to learn a lot
and your data is not very valuabel you can -at least-
a) redirect the stdout and stderr of "cpio -ovcuB" to a file
(To see what is happening you can do a "tail -f" on that file
(How to do that depends on the shell you use)
b) readback the tape with cpio -ivxxxx "restoring" it to /dev/null
c) align and compare the both logfiles...
d) count the number of files on the disk and on the tape (wc -l)
e) estimate the sizes (beware of hard and softlinks)
f) mail the differences and statistic.
there should be no differences...
(and you should have lot more (shell) programing practice)
But:
there are still many mean traps, one for example, is the parameter "-P0,1".
That is required if you run cpio from crontab (as usual) and
if you want a more comprehensive error message
than "can't write to tty1" is case the tape is full or
broken. You will run into that problem only after a long time...
(until the tapes are tired or you have to backup a lot more than to day).
etc. pp..
And:
that a tape is readable does not mean that the data is really Ok.
(It's very likely, but no sure...)
Too you should make some time stamping to be aware if the backup is
suddenly very fast or needs very long which you can't explain.
Then you have to close several applications, which might lock
some files, so those files will never be backeduped...
What happens if the "last" and only backup tape you have shows
errors iuf you need to restore?
What if your streamer was dejustified and breaks "unrepairable"
and the new streamer can't read none of your old tapes?
What do you do in case of desaster recovery?
You have nothing on the box with the new discs to do the restore...
start to install SCO...
Does it become clear why is wise to use a supertar?
But:
As good as supertars are, i would take it only as one out of
-at least- two (mostly) _independend_ ways of making backups
on different hardware (dejustified streamers).
Other ways are rdist/rsync/dirvish to a remote system for
example. But too, don't trust them alone if your data is
really valuable.
>Rainer Zocholl wrote:
>> (Tony Lawrence) 15.11.02 in /comp/unix/sco/misc:
>>
>>
>>
>>>FAR better solution: http://aplawrence.com/Reviews/supertars.html
>>
>>
>> I agree your recommandation to supertars.
>> But i made -years ago- bad expirience with "propiety"
>> backup formats not beeing readable by other software...
>They are NOT proprietary.
Pardon my typo. (One of the words i'll never learn "proprietary" ;-))
>They all use "tar" format.
Ok. Good to hear/know.
>If you use software compression, they use standard compression tools:
>if you had to, you could extract the files with tar, rename them
>temporarily and uncompress them using standard uncompress.
Thanks.
>On Windows NT/2000 servers, we ONLY use like BackupExec from
>Veritas, or ArcServe to backup our data. And we have procedures
>to check the tapes several times a week to verify that backup
>is OK for our customers. But we do not know enough about unix
>server to do the same, but we should be able to do it, therefor
>i have to learn how to take backup, restore data, verify that
>backup is OK etc.
You don't have to know about Unix to use BackupEdge or LoneTar.
The packages also will perform checks right after backup so you
know that they are correct. I get email nightly from a couple of
machines that tell me if the backup is OK or not. No special
procedures are needed.
I've seen the BackupExec running on an NT next to an SCO
with BackupEdge and the performance difference alone is amazing.
At that time the client said they wished they had something
like BE for NT. LoneTar is the same.
I actually have both running at different places because one
support HW platforms the other doesn't So don't let it worry you
that BackupExec doesn't suport Unix. In fact - be glad, be very
very glad.
--
Bill Vermillion - bv @ wjv . com
>>FAR better solution: http://aplawrence.com/Reviews/supertars.html
>I agree your recommandation to supertars.
>But i made -years ago- bad expirience with "propiety"
>backup formats not beeing readable by other software...
It's really not a proprietary format at all. It's more
like an enhanced tar. A couple of the main points are that
the supertars will backup empty directories and device node
entries while tar wont.
That means that if you have a directory that is sometimes full and
sometimes empty and you backup with a normal tar that directory
won't be backed up.
If this were a standard backup program that would be normal
But the supertars have the ability to boot from floppies, or CD
that you create to match your system, and if you lose a drive and
have a known good drive to put in, or if it's SCSI and
automatically heals itself, you can be restoring the complete tape
to a brand new hard drive in under five minutes.
If you used a tar/cpio backup you would have to reinstall the OS.
Then you would configure the tape device. And only then would you
be able to reload the tape.
But SURPRISE. Since the tar did not save empty directories those
aren't created and the first time a program that needs to use one
and can't find it, it might just blow up in your face. So much for
most backup programs. The supertar programs are 'backup systems'.
Same for device nodes. I've seen MS people who can not believe it
when I have restored a complete system to a naked drive and had it
rebooted and running before they even got the MS bases OS
reinstalled. Its then that you really appreciate these products.
>How "compatible" are those tapes (today)?
Quite.
>Currently one .com-company or software vendor or unix after
>the next "dies".
>What if one bought a "supertape" software, changed system
>and has to recover a tape made serveral years ago (had that in
>a patent case) and can't get a running version of the supertar
>used then?
I"d have more faith in the ability to recover a tape made by a
supertar than I would on an MS system. Because they are tar
compatible.
Worst case you could tar the files into a system and then massage
them by hand. And that would be very rare.
It was on an older version of one of these products and the data
was compressed before storage. [I won't name names because I've
only seen it a long time ago].
I need to extract data create on an SGI Challenge server [MIPS
based and the byte order is different than iNTEL chips].
The compressed were read via a NORMAL TAR command on a BSD system.
The files werent readable at first. This problem - again a long
time ago - ws because the compressed files were restored but with
no extension to indicate compression.
Running the 'file' command showed they were compressed. I rename
of the files with an extension cured that. [That was needed
otherwise the extracted file would want to overwrite the compressed
file in the same directory].
All ascii type files should restore perfectly. I had some files
that were stored in the native CPU format on the SGI whose
byte-order is opposite of iNTEL.
So for those files I did this:
dd if=oldfilename of=newfilename conv=swab
And it was done.
So the only time you would find incompatibility - based on my
experience - is if you took a supertar file created on
a different platform/cpu and move it to another with just
a little effort.
The supported platforms between the two major products include
SGI, Sun, HP-UX, Data General Avions, IBMs AIX, Dec Alphas,
NCRs towers, BSD, FreeBSD, Linux, and of course all SCO variants.
Let's see BackupExec match that !!!
They both support bootable CDs which will be used to restore the
tapes. They both have network and dial in support.
You seem to indicate you have remote clients and both products
support dial-in modem and network support.
So you could have the remote client with a dead-system boot with
floppies or CD and then you could do the rest from your machine.
Truly amazing products.
I first started using these products back in 1986 when I did
on-call work for a site with 11 Xenix system and we had a supertar
backup on all of them with two port tape drives.
In those days a 20MB drive then was considered large. And
those drives cost more than that time it was backup to multiple
floppies. Thankfully a 20MB drive then was considered large. And
those drive cost more than the 250GB drives you can buy todayn
Now those 1986 backup tapes would be hard to handle years later
- just as almost all old tapes will because there will be no
hardware to read them.. You'd have to look long an
hard to find a system with a Teac Cassette Data Drive to read
those tapes. But if you could the data would be readable today.
I think every major support person in this NG insists their
customers use one or the other.
Once you use them you'll wish you had them for the MS systems.
Bill
Well, in OSR 5.0.6, tar has progressed a bit:
Limitations
===========
tar cannot archive device special files. For this reason, it is
not suitable for creating filesystem backups.
Prior to this release, tar could not archive symbolic links,
information about directories, or empty directories but it
could follow symbolic links if the L function modifier was
specified. Use the P function modifier to tar if you want to
create an archive that can be read by the previous version of tar.
Still a tar limitation: maximum of 99 characters in a pathname.
--
JP
After reading the web pages i just made a decision to go for Edge..
I have downloaded the program, and started to install it.. i got trubble, so
i called them, they connected themselfe to our server and tried to fix the
problem. Problem needed a reboot of the server, but i had to wait to later
the eavning since people are working on the server.. server is now rebooted
and i'm going to try again.
> I do think that each of these products, although very similar, fits
> different needs and different personalities, and I suspect that their
> web pages appeal differently also.
>
> Again this is just curiousity: did you go to the web pages of each and
> look them over? I'm sure both Jeff and Tom would be interested in how
> their respective marketing affected you.
I will see if Edge is working as i need, if not i'll try one of the others
on your link.
Thanks for your advise :-)
/Freddy Ulvseth
Hehe... i'm glad when i have a full backup of the server :-)
I'm open to try out new products, and my boss is too as long as i can
demonstrate that this is a better product from what we use today.
On UNIX we have now such things as standard software, therefor this is a
good way for me to get in a product, get to know it and show my boss this
product.. and will by license for it... :-)
/Freddy Ulvseth
l BackupEDGE Installation / Upgrade / Configuration
k
lqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqk
xWARNING: no media detected in /dev/rStp0! x
xDefault values may be substituted for
x
xcorrect ones.
x
Whats wrong? hmmm..
/Freddy Ulvseth
"Tony Lawrence" <to...@pcunix.com> wrote in message
news:ar3cfa$pdr$1...@pcls4.std.com...
I got through it! just by clicking next all the way.. i look forward to see
how the backuyp works :)
VERY easy to install, i thought it should be more "/dev/strange/things/"
questions, but it was easy... :-)
/Freddy Ulvseth
"Ulven" <fre...@REMOVESPAMulven.com> wrote in message
news:Ax1C9.13454$TK2.1...@juliett.dax.net...
# tape status
tape: can't open '/dev/nrStp0': No such device or address
and backup with Edge failed to...
==========================================================================
Microlite BackupEDGE Data Archiving System Summary
==========================================================================
Message Time = 2002-11-18 09:37:46
BackupEDGE Release = 01.02.03
Serial Number = demo1100
BackupEDGE Expiration = Jan 17, 2003
System Name = tourplan.server
WARNING: = Please Make RecoverEDGE Media
Error Detected = No Medium Detected
Job Name = tourplan.server:simple_job_master
Job Description = (Master) Basic Schedule
Sequence Name = tourplan.server:onsite_system
Sequence Description = On-Site Backups of Entire System
Domain Name = tourplan.server:system
Domain Description = Entire System
Primary Device = tourplan:tape!tape0
Number of Files = 0
Backup Type [Status] = Master [FAILED - Status Is 53]
==========================================================================
Detailed Information
--------------------------------------------------------------------------
No Medium Detected
Exit Status Is 53
Summary: BACKUP_FAIL (tourplan.server:simple_job_master)
[End of Summary]
There is tape in the drive..
What can be wrong?
"Tony Lawrence" <to...@pcunix.com> wrote in message
news:ar3cfa$pdr$1...@pcls4.std.com...
All it says is that you didn't have a tape in the drive. But it did
find the drive.
-
-i've start looking at microlite's edge. I'll try to install that..
-If it works, i'll talk my boss into bying a license for it.
-
A real world example of how useful edge is:
All our customers use edge, and do full system backups occasionally. 2 weeks ago
one of them had a SCSI errors on the disk. Engineer came out and swapped it. I
was on site, and using the emergency floppies and their last backup tapes had
the system back up an running in an hour. This involved booting from floppy1,
inserting floppy2, navigating a menu to Auto-Restore and pressing enter.
Customer back up, I'm a hero, warm tea and biscuits all round.
-Rob
robatwork at mail dot com
--
/Ulven
http://freddy.ulven.com
"Bill Vermillion" <b...@wjv.comREMOVE> wrote in message
news:H5s54...@wjv.com...
Hello Scott,
To assure complete 'tar' compatability with any one of the supertars,
you would need to stay within the guidelines of the standard 'tar'
command on that particular system. For example, some (not all) OS's
'tar' cannot read any backup if the blocksize was greater then
20 (supertars go much higher than 20). If the supertar 'compression'
was turned "on", then restoring a compressed supertar file with regular
'tar' will appear to work but could cause havic in some cases especially
if you restore '/bin' '/etc' '/usr/bin' overtop the original directories.
Reason being is the supertars do not tag the filename with a suffix (.Z)
to identify it is compressed. As a result, you will clobber /bin/xyz
with /bin/xyz (compressed version). Next time you want to execute
'/bin/xyz' you're in deep dodo. This issue has been around since the
early days of all the supertars and actually has not caused much of a
problem and was a segue to some of the interesting flags such as
'-zNw' '-w' '-zN' non-destructive and interactive restores.
I would strongly recommend to anyone wanting to restore a supertar
backup using regular 'tar' to do the following:
1. Read the supertar tape label or first file. This beginning file will
tell you all you need to know about the backup, including blocksize,
low-lever SCSI blocksize, compression, etc.
2. Restore relative to a sub-directory as to not clobber any existing
files on the system.
3. In the worse-case-senareo where you're not sure... you can always
download a DEMO from the web and use it to get the job done. No
cost and no strings attached.
http://www.microlite.com ............... BackupEDGE
http://www.unitrends.com ............... CTAR
http://www.cactus.com .................. LONE-TAR
Hope this helps,
Jeffrey Hyman, President
.--.
___________________________ .-. | | _____________________________________
Lone Star Software Corp. | | | | .-. Home of World Famous LONE-TAR(tm)
Cactus International, Inc. | |_| | | | Backup Software for UNIX and LINUX
Sales: 800.525.8649 _ |___ |_| | 24x7 Support Available
Support: 301.829.1622 _| ~- | ___| RESCUE-RANGER(tm) and AIR-BAG(tm)
http://www.LONE-TAR.com \, _} | | Disaster Recovery Software
-------------------------- \( -- | | --------------------------------------
| |
The failure of the tape status command is important.
If the operating system doesn't think the drive is working,
it is unlikely to work with BackupEDGE SS.
Tell us the exact tape model number, whether it is ATAPI or
SCSI, whether its worked in the past.
What shows in
"mkdev tape"
1. Configure a SCSI or Enhanced IDE tape drive
6. View Current SCSI and Enhanced IDE Tape Drive configuration
?
Show the results of "cat /etc/conf/cf.d/mscsi".
--
Best 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 |
+-----------------------------------------------------------+
Tape Drive is a SCSI drive, Seagate STT2000 (10/20GB Travan).
It has worked before, there are new tapes..
ha attach number ID lun bus
wd Srom 1 0 0 0
alad Sdsk 0 0 0 0
alad Stp 0 3 0 0
Where i guess that Stp is the backup station. :-)
And mkdev tape is:
The current tape configuration is:
Unit Description
0 Generic SCSI-1 / SCSI-2 tape drive
what can i do ?
--
/Ulven
http://freddy.ulven.com
"D. Thomas Podnar" <t...@microlite.com> wrote in message
news:3DD94EBA...@microlite.com...
I've found a problem on a another server we have, i tried to install
BackupEdge on that server, its the same as the other... but during the
installation i saw that the date was one year i front.. i continued with
installation and changed the date after that.. now it says that the license
is wrong..
I want to clean the whole installation and re-install it..
I tried to look at your pages (www.microlite.com) but did not find anything
there..
How do i remove the program?
I tried to re-install the program, did not work..
/Ulven
http://freddy.ulven.com
Unix will look for a SCSI tape drive with ID 3.
Have you checked the jumpers on the Seagate to see if in fact
the tape drive is set to ID 3?
--
JP
Run 'custom' ...
--
JP
--
/Ulven
http://freddy.ulven.com
"Jean-Pierre Radley" <j...@jpr.com> wrote in message
news:2002111822...@jpradley.jpr.com...
# cat /etc/default/tape
# @(#) tape.dfl.src 25.1 94/07/25
#
# Copyright (C) 1988-1994 The Santa Cruz Operation, Inc.
# All Rights Reserved.
# The information in this file is provided for the exclusive use of
# the licensees of The Santa Cruz Operation, Inc. Such users have the
# right to use, modify, and incorporate this code into other products
# for purposes authorized by the license agreement provided they
include
# this notice and the associated copyright notice with any such
product.
# The information in this file is provided "AS IS" without warranty.
#
# default/tape - tape device: tape(C)
#
# for cartridge tapes, use /dev/xct0
# for floppy tapes, use /dev/xctmini
#
device = /dev/nrStp0
curdriver=Stp0
--
/Ulven
http://freddy.ulven.com
"Jean-Pierre Radley" <j...@jpr.com> wrote in message
news:2002111822...@jpradley.jpr.com...
Should be configured as DAT, not generic scsi.
I have changed it by mkdev tape:
Host
Adapter Adapter
Type Device Number ID LUN BUS
----------------------------------------------
alad Stp 0 3 0 0
Update SCSI configuration? (y/n) y
The SCSI configuration file has been updated.
Adding device to system configuration files ...
System files have been successfully updated.
Configuring Tape Driver ...( Stp )
Enter Vendor Identification string or
press <Return> to use default
or enter q to return to main menu:
Enter SCSI version that device is conformant to or
press <Return> to use default
or enter q to return to main menu:
Enter Response Data Format that device uses or
press <Return> to use default
or enter q to return to main menu:
The following tape drive types are supported:
1. Generic SCSI-1 / SCSI-2 tape drive
2. EXABYTE 8mm tape drive (8200 or 8500)
3. IBM rebadged EXABYTE 8mm tape drive (8200)
* 4. DAT drive (Compressing and non-Compressing)
5. QIC Cartridge tape drive
Please choose one of the above, press <Return>
for default,or enter q to return to main menu: 4
Tape Driver Successfully Configured
Default special devices have been created with the following links:
/dev/xct0 linked to /dev/xStp0
/dev/rct0 linked to /dev/rStp0 and /dev/rmt/0b
/dev/nrct0 linked to /dev/nrStp0 and /dev/rmt/0bn
In /etc/default/boot:
this looks fine?
/Freddy Ulvseth
"Tony Lawrence" <to...@pcunix.com> wrote in message
news:arbqk9$pnv$1...@pcls4.std.com...
Yes. Does it work now???
I have to reboot the server, but there are several clients logged into the
server now..
I'll let you know when i have tested...
yesterday i tried with dat, but it said that the tape was offline.
/Freddy
"Jean-Pierre Radley" <j...@jpr.com> wrote in message
news:2002111822...@jpradley.jpr.com...
I'm interested in the exact number, as well as the firmware level
of the drive. We'll get to this more in a minute.
> It has worked before, there are new tapes..
OK.
>
> ha attach number ID lun bus
> wd Srom 1 0 0 0
> alad Sdsk 0 0 0 0
> alad Stp 0 3 0 0
> Where i guess that Stp is the backup station. :-)
The "sconf -v" command reports what the OS is seeing,
as opposed to what it is configured for. Does it agree
that the tape drive is on ID 3?
>
> And mkdev tape is:
>
> The current tape configuration is:
> Unit Description
> 0 Generic SCSI-1 / SCSI-2 tape drive
>
> what can i do ?
OK.
next steps.
After a reboot, lets do the following in order.
Is the tape drive alive?
tape status /dev/xStp0
Tar backup.
tar cvbf 20 /dev/rStp0 /bin /usr/bin
BackupEDGE SS backup - blocked like tar.
edge cvbf 20 /dev/rStp0 /bin /usr/bin
BackupEDGE SS backup - blocked as normal.
edge cvbf 64 /dev/rStp0 /bin /usr/bin
BackupEDGE SS backup - add double buffering.
edge cvbfS 64 /dev/rStp0 /bin /usr/bin
BackupEDGE SS bit level verify of the last backup.
edge TTvbf 64 /dev/rStp0
What I'm looking for is the point where the backups stop
working. None of the tests take too long. As long as they
don't fail, the actual results and summaries aren't
important.
If all of the above passes, I want to query the tape drive
to see if our SCSI queries cause a problem. report the
results of the following commands. After each, do a
tape status /dev/xStp0
to see if any of them futz up the drive.
edge.tape -i /dev/xStp0
edge.tape -t /dev/xStp0
edge.tape -terse -t /dev/xStp0
edge.tape -V /dev/xStp0
These commands will tell us the model and firmware
revision of your device, among other things.
You've now got my curiosity up. If it is us locking
up the tape drive I want to know why so that I can
fix it. It may also be poor cabling or termination,
but lets run the gauntlet first.
I may want to contact you off-list and have an engineer
telnet in and look around.
Tom Podnar
Microlite
And THAT is exactly why I so strongly push people to use these products.
This happens to be Microlite, but I bet Jeff Hyman has the same level
of interest in improving Lone-Tar. The important thing here is not so
much that the poster gets their problem solved (although that is
important of course) but that this type of problem can lead to
engineering improvements that wil ultimately benefit everyone.
The installer calls custom in command line mode to ensure
easy integration/removal.
Tom Podnar
Microlite
>hmmm.. new problem...
># tape status
>tape: can't open '/dev/nrStp0': No such device or address
You said you are starting on unix.
So please allow the (dummy) questions:
Which permissions/owner do /dev/nrStp0 etc. have?
What account are you trying to use it or BE with?
>---- No Medium Detected
>Exit Status Is 53
Uups...remember...SCSI...extended sense code?...could that
be "media changed" "media load/eject failed" coming still
from the boot time?
Do/did you power your box off?
What happens if you first do the "dd/tar" stuff mentioned in
other postings and start after that with BE?
(I don't assume that this would solve, but the drive/device
seems to work phyiscally.).
>Summary: BACKUP_FAIL (tourplan.server:simple_job_master)
>[End of Summary]
>There is tape in the drive..
>What can be wrong?
Unformated? (not really required, but i don't know tarvan)
Incompatible media?
Write protected?
Sealed?
Yes.. it is on ID 3
>
> next steps.
>
> After a reboot, lets do the following in order.
>
> Is the tape drive alive?
> tape status /dev/xStp0
# tape status /dev/xStp0
status : ready beginning-of-tape
soft errors : 0
hard errors : 0
underruns : 2
> Tar backup.
> tar cvbf 20 /dev/rStp0 /bin /usr/bin
# tar cvbf 20 /dev/rStp0 /usr/bin
a /usr/bin/egrep symbolic link to /opt/K/SCO/Unix/5.0.5Eb/bin/grep
a /usr/bin/fgrep symbolic link to /opt/K/SCO/Unix/5.0.5Eb/bin/grep
a /usr/bin/euc/sed symbolic link to /opt/K/SCO/Unix/5.0.5Eb/usr/bin/euc/sed
and so on... until # came back.
thats OK then?
> BackupEDGE SS backup - blocked like tar.
> edge cvbf 20 /dev/rStp0 /bin /usr/bin
# edge cvbf 20 /dev/rStp0 /bin /usr/bin
Microlite BackupEDGE Enhanced Data Archiving System
(c) Copyright 1991-2000 by UniTrends Software Corporation
All Rights Reserved
BackupEDGE Temporary Activation
Serial Number: demo1100 Expires On Sat Jan 18 00:00:55 2003
a /bin/basename, 0 blocks
Symbolic link to ===> /opt/K/SCO/Unix/5.0.5Eb/bin/basename
a /bin/cat, 0 blocks
Symbolic link to ===> /opt/K/SCO/Unix/5.0.5Eb/bin/cat
a /bin/chmod, 0 blocks
Symbolic link to ===> /opt/K/SCO/Unix/5.0.5Eb/bin/chmod
a /bin/chown, 0 blocks
and so on for a while....
==========> BackupEDGE Backup Summary S/N: demo1100 <==========
Wed Nov 20 11:11:16 2002
FILES: 585
Total DATA: 306 bytes
Elapsed Time: 10 seconds
Data Transfer Speed: 44959 bytes/sec ( 2.6 Mb/min)
#
> BackupEDGE SS backup - blocked as normal.
> edge cvbf 64 /dev/rStp0 /bin /usr/bin
==========> BackupEDGE Backup Summary S/N: demo1100 <==========
Wed Nov 20 11:14:04 2002
FILES: 585
Total DATA: 306 bytes
Elapsed Time: 8 seconds
Data Transfer Speed: 56198 bytes/sec ( 3.2 Mb/min)
> BackupEDGE SS backup - add double buffering.
> edge cvbfS 64 /dev/rStp0 /bin /usr/bin
==========> BackupEDGE Backup Summary S/N: demo1100 <==========
Wed Nov 20 11:16:00 2002
FILES: 585
Total DATA: 306 bytes
Elapsed Time: 2 seconds
Data Transfer Speed: 224793 bytes/sec ( 12.9 Mb/min)
> BackupEDGE SS bit level verify of the last backup.
> edge TTvbf 64 /dev/rStp0
SUMMARY: Byte by Byte Verification
585 files were encountered
5 special files (links, directories, devices, etc.)
580 files verified successfully
All files match using byte by byte comparison!!
> What I'm looking for is the point where the backups stop
> working. None of the tests take too long. As long as they
> don't fail, the actual results and summaries aren't
> important.
>
> If all of the above passes, I want to query the tape drive
> to see if our SCSI queries cause a problem. report the
> results of the following commands. After each, do a
> tape status /dev/xStp0
> to see if any of them futz up the drive.
>
> edge.tape -i /dev/xStp0
Product ID: STT20000N
Vendor: Seagate
Revision: 7A61
Interface: SCSI
SCSI Compliance: 2
Description: Sequential Access
Media Present: 1
Removable Medium: 1
> edge.tape -t /dev/xStp0
Product ID: STT20000N
Vendor: Seagate
Revision: 7A61
Interface: SCSI
SCSI Compliance: 2
Description: Sequential Access
Media Present: 1
Removable Medium: 1
Partition Support: 1
Current Partition: 0
Number of Partitions: 1
Erasable Medium: 1
Density: 0x47
Density String: Travan NS20
Loaded Medium: Tape
Write Protected: 0
Setmark Support: 1
Current Block Size: 512
Minimum Block Size: 9
Maximum Block Size: 65536
Variable Block Support: 1
Compression Flag: 3
TapeAlert(tm) Support: 1
> edge.tape -terse -t /dev/xStp0
ET_PRODUCT="STT20000N "
ET_VENDOR="Seagate "
ET_REVISION="7A61"
ET_IFACE="0"
ET_SCSILEV="2"
ET_DESC="Sequential Access"
ET_MEDIA="1"
ET_SURE_MEDIA="1"
ET_REMOVABLE="1"
ET_PART="1"
ET_CPART="0"
ET_NPART="1"
ET_CAPT0="-1"
ET_CAPR0="-1"
ET_CAPW0="-1"
ET_CAPTC="-1"
ET_CAPRC="-1"
ET_ERASABLE="1"
ET_UNCREAD="-1"
ET_DLYREAD="-1"
ET_CORREAD="-1"
ET_UNCWRITE="-1"
ET_DLYWRITE="-1"
ET_CORWRITE="-1"
ET_DENS="47"
ET_DENSDESC="Travan NS20"
ET_LENGTH="-1"
ET_MEDIATYPE="1"
ET_WPROT="0"
ET_RSMK="1"
ET_ROBDR="0"
ET_WOBDR="0"
ET_BLOCKSIZE="512"
ET_MINBLOCKSIZE="9"
ET_MAXBLOCKSIZE="65536"
ET_VARBLOCKSIZE="1"
ET_COMPRESSION="3"
ET_TAPEALERT="1"
ET_RETCODE="0"
> edge.tape -V /dev/xStp0
TapeAlert(tm) Support: 1
TapeAlert(tm) Status: [No Message]
> These commands will tell us the model and firmware
> revision of your device, among other things.
It seems to work fine here, now i start BackupEdge.
with edgemenu, start scheduled job.
Job Exited With Exit Code 4
Message Time = 2002-11-20 11:20:06
x
BackupEDGE Release = 01.02.03
x
Serial Number = demo1100
x
BackupEDGE Expiration = Jan 18, 2003
x
System Name = tourplan.haman.se
x
WARNING: = Please Make RecoverEDGE Media
x
Job Name = tourplan.haman.se:simple job master
x
Job Description = (Master) Basic Schedule
x
Sequence Name = tourplan.haman.se:onsite system
x
Sequence Description = On-Site Backups of Entire System
x
Domain Name = tourplan.haman.se:system
x
Domain Description = Entire System
x
Primary Device = tourplan:tape!tape0
Just for testing the driver after failing:
# tape xstatus
status : ready beginning-of-tape
read errors corrected w/o substantial delay : 0
read errors corrected with possible delay : 0
Total bytes transferred (read) : 2048
Total write errors : 0
Total bytes transferred (write) : 600960
> You've now got my curiosity up. If it is us locking
> up the tape drive I want to know why so that I can
> fix it. It may also be poor cabling or termination,
> but lets run the gauntlet first.
>
> I may want to contact you off-list and have an engineer
> telnet in and look around.
you can reach me at: fre...@it-systemer.no
> Tom Podnar
> Microlite
>
/Ulven
http://freddy.ulven.com
--