URGENT at this stage:understanding restore and dump
/dev/null
>Let me lay out the scenario and then ask my three questions please.
>
>This site has no tape device; it has two (2) 40-GB ide hdisks.
>
>I created a large partition for dump -0u, and smaller slices for the other
>levels. I ran mkfs on the partition just to see how dump would handle it,
>but
>dump seemed to just blow it away and write its own image, ignoring any
>filesystem. This makes sense.
>
>Never having run dump in a routine before, I needed to test it. /dev/hda is
>my data and /dev/hdc is my 'backup device.'
>
>I have slices hdc1-hdc9 for dump levels 0-9 respectively.
>
>The proof of course is in the restore.
>Here was my test routine which I ran in cron overnight:
>
>dump -0u -f /dev/hdc1 /
>dump -3u -f /dev/hdc2 /
>dump -2u -f /dev/hdc3 /
>dump -5u -f /dev/hdc5 /
>dump -4u -f /dev/hdc6 /
>dump -7u -f /dev/hdc7 /
>dump -6u -f /dev/hdc8 /
>dump -9u -f /dev/hdc9 /
>
>I created /restore on /dev/hda and cd to it
>Then began my simple test.
>The idea was to test the different dump levels from each slice on /dev/hdc
>
># restore -i -f /dev/hdc1
>
>restore > cd fff
>restore > ls
>./bb/name/fff:
>d1/ d11/ d123/
>
>restore > add d1/ d11/ d123/
>restore > extract
>You have not read any tapes yet.
>Unless you know which volume your file(s) are on you should start
>with the last volume and work towards the first.
>Specify next volume #: 1
>Mount tape volume 2
>Enter ``none'' if there are no more tapes
>otherwise enter tape name (default: /dev/hdc1) none
>
>At this point the program exits
>I checked the contents of the directories after the restore. It seems that
>d1
>and d11 were fine, but d123 was empty. I checked the timestamps of the
>files
>in the original directory and they are much older than the dump.
>
>Question: possible explanations for this failure? It was dump level 0.
>
>Question: Can volumes be spanned automatically? i.e. when running dump from
>a
>sh script, can I somehow tell dump to go to /dev/hdc2 when it is out of
>space
>on /dev/hdc1?
>
>Question: If I restore /dev/hdc9, must I restore /dev/hdc2, 5, and 7 first,
>and in that order?
I suppose I neglected to add to that 2 mysteries:
1. My restore of dir d123 fails without error messages, but I can see the
data
clearly in the dump when i execute ' restore> ls' It's all there in the
dump.
2. The restore program prompts me for the next volume. Next volume, Next
volume, and I can't break out of it. Fine. So it got me thinking that
there
was a space overflow that prevented the rest of the dumps from executing
(i.e.
levels 2-9)... This would explain why I can't read anything on /dev/hdc2 --
probably there is nothing there to read. My next step was to test a very
small dump (the -u option is prohibited if the dump is a subdirectory) to
/dev/hdc3 (arbitrary, just a spot-check). Whoa! This is what dump tells me:
[root@server /restore]# dump -0 -f /dev/hdc3 /bb/name/d123/*
DUMP: Date of this level 0 dump: Wed Aug 22 17:33:12 2001
DUMP: Date of last level 0 dump: the epoch
DUMP: Dumping /dev/hda6 (/ (dir bb/name/d123/)) to /dev/hdc3
DUMP: Label: /
DUMP: mapping (Pass I) [regular files]
DUMP: mapping (Pass II) [directories]
DUMP: estimated 33680 tape blocks.
DUMP: Volume 1 started at: Wed Aug 22 17:33:12 2001
DUMP: End of tape detected
DUMP: Closing /dev/hdc3
DUMP: Volume 1 completed at: Wed Aug 22 17:33:12 2001
DUMP: Change Volumes: Mount volume #2
DUMP: Is the new volume mounted and ready to go?: ("yes" or "no") yes
DUMP: Volume 2 started at: Wed Aug 22 17:33:41 2001
DUMP: Volume 2 begins with blocks from inode 0
DUMP: EOT detected at start of the tape!
DUMP: The ENTIRE dump is aborted.
Does anyone have any ideas about this EOT error the dump program encounters
on
the /dev/hdc3 slice? The hdisk is fresh IBM and I wrote to it prior to
creating the slices.
Can anyone shed some light on all that is happening here?
One last question, not as critical, but nonetheless will save some
aggravation: why does 'restore' not preserve the ownership and file
permissions? Or is that dump's responsibility?
URGENT.
Thanks!
------------------------------------------------------------
dd -if /usr/ignorance -of /dev/null; reboot
------------------------------------------------------------
Chuck Geigner
>
> DUMP: EOT detected at start of the tape!
> DUMP: The ENTIRE dump is aborted.
>
> Does anyone have any ideas about this EOT error the dump program encounters
> on
> the /dev/hdc3 slice?
not volumes of help but:
EOT=End of Tape
Good Luck
--
Chuck Geigner ---------------------------------------
AIX Sysop
Milner Library, Illinois State Univ.
"Been borrowing Occam's shaving instrument since 1992
Haven't cut myself yet."_____________#rgvac==mongoose
/dev/null
If anyone can help me with the third I 'd be most appreciate. -yeah-- like
that's worth anything! :)
This part I am not 100% sure on yet.
It seems that after dump level 0, dump 3 and 2 (in this order) work this
way:
dump 3 will backup all files modified since level 0 dump
dump 2 will backup all files since level 0 dump also since it is a lower
level
dump than level 3. Is this a correct assumption?
Therefore a level 5 dump and level 4 dump in this order would also work this
way, as would level 9 dump and level 8 dump in this sequence.
therefore, for an up-to-date restore according to my dump schema, I would
need
to restore in this sequence: 0, then 3, then 5, then 9. Is this correct?
>
>I suppose I neglected to add to that 2 mysteries:
>
>1. My restore of dir d123 fails without error messages, but I can see the
>data
>clearly in the dump when i execute ' restore> ls' It's all there in the
>dump.
Why the files appear in the 'restore> ls' may be a bug in dump, i don't
know.
Perhaps it actually writes a listing of files before it writes them. I can
almost guarantee the files were not there, because of the next problem I
discovered.
> DUMP: EOT detected at start of the tape!
> DUMP: The ENTIRE dump is aborted.
>
>Does anyone have any ideas about this EOT error the dump program encounters
>on
>the /dev/hdc3 slice? The hdisk is fresh IBM and I wrote to it prior to
>creating the slices.
>
>Can anyone shed some light on all that is happening here?
I figured this out using a little common sense.
I ran dump with the -S [uppercase S] option present on Linux to simulate a
dump. I then compared the size estimated for the dump with the size of the
slice to which I intended to write. Needless to say, the slice to which I
intended to write was slightly smaller than the dump size. Therefore, [1]
the
dump encounters and EOT and prompts for next volume (?true) and [2] the
subsequent dump levels in the shell program fail. End of story?
>
>One last question, not as critical, but nonetheless will save some
>aggravation: why does 'restore' not preserve the ownership and file
>permissions? Or is that dump's responsibility?
I discovered that when the restore was "normal" i.e. restoring from a dump
that was completely written, 'restore' will prompt me to decide whether or
not
to preserve file ownerships. HOWEVER I discovered something just as
aggravating: the permissions were read/execute only. Not a 'w' among them.
Has anyone encountered this? Just what the hell does dump think it's doing
by
changing the permissions? 'tar' doesn't do that with the -preserve option.
Jefferson Ogata
[a long story]
Okay, I don't know where to start. The whole approach is wrong. Go get the
O'Reilly UNIX Backup and Restore book and read it. Here's a little advice to
tide you over until you do.
Get rid of the multiple partitions on the second drive. Create one partition
and build a filesystem on it. Write your dumps to files in that filesystem.
Yes, there will be a little overhead with this, but you won't be constrained by
the size of the target partitions. If you're concerned about overhead, reduce
the number of inodes when you create the filesystem. You don't need very many.
On dump levels: 0 is the whole filesystem, 1 is everything modified since 0, 2
is everything modified since 1, etc. A typical scenario is to take a level 0
once a month (adjust for volatility), take a level 5 weekly, and take a level 9
daily. To restore, first restore the monthly level 0, then restore the most
recent level 5, then restore the most recent level 9. In general on restore,
start with 0, then do the most recent dump of each level in increasing order.
If you can't afford a tape drive, get a spare disk of the same size and swap it
out of the machine every month so you can take one dump off site. Having all
your backups on the same host is a disaster waiting to happen -- fire, flood,
lightning, power surge, theft, sabotage, stupid error -- any one of these and
more can completely nullify all your work.
Perform dumps when the system is as quiescent as possible. If necessary, kill
-STOP any processes that never quiet down. You don't want things shifting
around on the filesystem while you are imaging it.
--
Jefferson Ogata : Internetworker, Antibozo
<og...@antibozo-u-spam-u-die.net> http://www.antibozo.net/ogata/
whois: jo...@whois.networksolutions.com
http://www.antibozo.net/ogata/pgp.asc
/dev/null
=====
>/dev/null wrote:
>[a long story]
well, more information is usually better than less. I get your drift.
>
>Okay, I don't know where to start. The whole approach is wrong. Go get the
>O'Reilly UNIX Backup and Restore book and read it.
I'm in a country where I won't be able to get that book very easily.
> Here's a little advice to
>tide you over until you do.
Many thanks.
>
>Get rid of the multiple partitions on the second drive. Create one partition
>and build a filesystem on it. Write your dumps to files in that filesystem.
>Yes, there will be a little overhead with this, but you won't be constrained
by
>the size of the target partitions. If you're concerned about overhead, reduce
>the number of inodes when you create the filesystem. You don't need very
many.
the idea behind slicing the hdisks is to increase the chances of recovery in
the event that there is a problem with the partitions. Remember, we are
substituting slices for tapes here. Is there no apparent advantage to my
design?
>
>On dump levels: 0 is the whole filesystem, 1 is everything modified since 0,
2
>is everything modified since 1, etc. A typical scenario is to take a level 0
>once a month (adjust for volatility), take a level 5 weekly, and take a level
9
>daily. To restore, first restore the monthly level 0, then restore the most
>recent level 5, then restore the most recent level 9. In general on restore,
>start with 0, then do the most recent dump of each level in increasing order.
>
Yeah that's pretty much what I wrote, except you didn't clarify one aspect:
If I have a level 0 dump, then in this sequence: levels 3, 2
Will the level 2 dump not be a dump of all files modified since the level 0
dump?
>If you can't afford a tape drive, get a spare disk of the same size and swap
it
>out of the machine every month so you can take one dump off site.
Good idea.
> Having all
>your backups on the same host is a disaster waiting to happen -- fire, flood,
>lightning, power surge, theft, sabotage, stupid error -- any one of these and
>more can completely nullify all your work.
yeah, well, that's a fact.
>
>Perform dumps when the system is as quiescent as possible. If necessary, kill
>-STOP any processes that never quiet down. You don't want things shifting
>around on the filesystem while you are imaging it.
>
I get your drift-- thanks.
>--
>Jefferson Ogata : Internetworker, Antibozo
><og...@antibozo-u-spam-u-die.net> http://www.antibozo.net/ogata/
>whois: jo...@whois.networksolutions.com
>http://www.antibozo.net/ogata/pgp.asc
Are there any good dump shell programs out on the net that you'd recommend?
Thanks.
------------------------------------------------------------
dd if=/usr/ignorance of=/dev/null; reboot
------------------------------------------------------------
Jefferson Ogata
> >===== Original Message From Jefferson Ogata <og...@antibozo-u-spam-u-die.net>
> =====
> >Get rid of the multiple partitions on the second drive. Create one partition
> >and build a filesystem on it. Write your dumps to files in that filesystem.
> >Yes, there will be a little overhead with this, but you won't be constrained
> by
> >the size of the target partitions. If you're concerned about overhead, reduce
> >the number of inodes when you create the filesystem. You don't need very
> many.
>
> the idea behind slicing the hdisks is to increase the chances of recovery in
> the event that there is a problem with the partitions. Remember, we are
> substituting slices for tapes here. Is there no apparent advantage to my
> design?
Not enough of one to be worth it. Just get the spare disk instead.
> >On dump levels: 0 is the whole filesystem, 1 is everything modified since 0,
> 2
> >is everything modified since 1, etc. A typical scenario is to take a level 0
> >once a month (adjust for volatility), take a level 5 weekly, and take a level
> 9
> >daily. To restore, first restore the monthly level 0, then restore the most
> >recent level 5, then restore the most recent level 9. In general on restore,
> >start with 0, then do the most recent dump of each level in increasing order.
> >
>
> Yeah that's pretty much what I wrote, except you didn't clarify one aspect:
>
> If I have a level 0 dump, then in this sequence: levels 3, 2
> Will the level 2 dump not be a dump of all files modified since the level 0
> dump?
The level 2 dump has all files modified since the last level 0 or 1. In that
scenario, the level 3 dump should not be used; just use 0 and 2. My statement
above should include the qualifier "the most recent level X dump that is more
recent than any dumps of a lower level. An algorithm: sort all dumps by
increasing date, eliminate all dumps of an equal or higher level than a more
recent dump, restore the remaining dumps in order.
[snip]
> Are there any good dump shell programs out on the net that you'd recommend?
> Thanks.
Not a dump script, but you might want to look at Amanda.
Nick Bachmann
[snip snip]
>
>>Okay, I don't know where to start. The whole approach is wrong. Go get the
>>O'Reilly UNIX Backup and Restore book and read it.
>>
>
> I'm in a country where I won't be able to get that book very easily.
Look at http://www.oreilly.com/order/new.int-ship.html. O'Reilly will
ship their zoo almost anywhere! Amazon.com will ship almost as many
places for much cheaper prices. The only problem I would see would be
the need of a credit card.
[snip snipity snip]
--
Regards,
N
-----------------------------------
Nicholas Bachmann
nabac...@yahoo.com
http://hermie.freeshell.org
"To Boldly Go Where Angels Fear To Tread"
-From the Infocom Game "Stationfall"
----------------------------------
Anthony W. Youngman
customer collecting it at the other end :-(
Anything of any importance whatsoever we ship courier end-to-end to
South Africa, and that can be expensive. You can have the same problem
in the FSU, and there are plenty of other places like that.
And in Africa, having robust servers run over a flaky phone system is
probably far more reliable than the Post Office... that is, where the
Post doesn't deliver to the local town and you're 100 miles in the bush
relying on a 4-seater plane trip once a month... Hey, maybe that's why
restore and dump are so important - he needs robust servers to talk to
the internet :-)