James Howard writes:
>: A lot of people said this. Why? As near as I can tell, dump isn't
that
>: great either. There is no way to exlude specific directories with
dump
>: and it appears to be quite painful to restore a specific directory
(though
>: I could be wrong about this.
>dump will dump everything. Always. Without fail. All others fail.
>Restoring specific directories is trivial. Excluding directories in
>dump isn't possible on the command line, but you can tag them with
>chflags dodump and they won't get dumpt.
>Dump is a little slow sometimes, but it works 100% of the time. tar,
>et al don't and can't. Fixing the tar/cpio/pax file formats isn't
>possible at this late date, so thet are unsuitable.
>Warner
>with "unsubscribe freebsd-hackers" in the body of the message
forms (like ufsdump) until one day i discovered that he was not
dumping.
system: Linux 7.1
dump method: dump to files on another slice
df
Filesystem 1k-blocks Used Available Use% Mounted on
/dev/hda7 8206812 2587084 5202844 34% /
/dev/hda1 23302 13486 8613 62% /boot
/dev/hdd1 39577704 8400284 29166968 23% /system
/dev/hda6 70255900 22061008 44626056 34% /sun.usr
i have a sh prog that is fairly straightforward and it works on
another server. /sbin/dump is called for each slice and writes to a
file on /system. The size of /.sun.usr is now approxiamately 22 GB.
Is this a limitation? i have never heard (or read) of such a
limitation.
The output of dump doesn't really give me any clues:
cat /var/log/gdump.fang.2001-11-23.11:36
DUMP LOG FOR fang
-------
Filesystems and their dumpdates (if any):
/dev/hda1 23302 13486 8613 62% /boot
/dev/hda7 8206812 2584932 5204996 34% /
/dev/hdd1 39577704 8396872 29170380 23% /system
Filesystem 1k-blocks Used Available Use% Mounted on
-------
DUMP: WARNING: There is no inferior level dump on this filesystem
DUMP: WARNING: Assuming a level 0 dump by default
DUMP: Date of this level 0 dump: Fri Nov 23 11:18:36 2001
DUMP: Date of last level 0 dump: the epoch
DUMP: Dumping /dev/hda6 (/sun.usr) to
/system/dump.fang.seq-0.lev-9.001
DUMP: Label: /bb
DUMP: mapping (Pass I) [regular files]
DUMP: mapping (Pass II) [directories]
DUMP: estimated 21998280 tape blocks.
DUMP: Dumping volume 1 on /system/dump.fang.seq-0.lev-9.001
DUMP: Volume 1 started at: Fri Nov 23 11:19:49 2001
DUMP: dumping (Pass III) [directories]
DUMP: dumping (Pass IV) [regular files]
DUMP: 3.43% done at 2514 KB/s, finished in 2:20
DUMP: 6.81% done at 2497 KB/s, finished in 2:16
Since dump has never successfully completed, the file /etc/dumpdates
is empty, thus forcing a level 0 dump.
The only thing i notice is that dump stops writing the dumpfile
exactly at the same place, same time.
ls -ltr /system
total 8400280
drwxr-xr-x 2 root root 16384 Nov 22 10:01 lost+found
-rw-r--r-- 1 root root 2147483647 Nov 22 10:50
dump.fang.sun.usr.1122.lev0.001
-rw-r--r-- 1 root root 2147483647 Nov 22 17:57
dump.seq-0.lev-5.001
-rw-r--r-- 1 root root 2147483647 Nov 23 04:28
dump.seq-0.lev-9.001
-rw-r--r-- 1 root root 2147483647 Nov 23 11:33
dump.fang.seq-0.lev-9.001
Now to my questions:
[1] Both /system and /sun.usr slices are brand new Maxtor 80 GB
hdisks. The syslog reports nothing. Is there a way to set dump in a
trace or debug mode to actually see every seek request to the disk?
[2] i attempted dumps while /sun.usr was both mounted and unmounted
with the same results. i verified the contiguity of the data by
executing a cp -Rp of the entire slice to another slice and all was
well. Does this eliminate a hardware issue?
[3] i used to have another hdisk which i divided into slices and
executed dumps to /dev/hdc1 ...etc. These dumps are 100% reliable and
always worked. It seems that the transition of dumping to individual
files on a single slice is the problem. Any comments?
[4] In desperation i am looking at other tools. tar is inappropriate
since it alway dies around 2GB, thus forcing me to get lists of
directories and then tar[ring] to more than two hundred tar files. I
don't trust cpio. i have not yet tried 'pax' and would like to know
if the 'unix' format is reliable.
Although not apparently an issue, i have included the backup sh prog
below.
cave Jabberwock
--------------
#!/bin/bash
# gdump.fang
# loki 2001-11-22
# dump rotation from devices to files on Linux
server=`uname -n |awk -F. '{print $1}'`
d=`date +%d`
date=`date +%Y%m`$d
weekday=`date +%w`
writeslice=/system
dumpfile=dump
readslice=/dev/null
ruid=`id -ru`
gdump='/sbin/dump'
dumpopts='uMf'
#declare -a cal
# send it all to the reportfile
reportfile=/var/log/gdump.$server.`date +%Y-%m-%d.%H:%S`
exec 1>>$reportfile
exec 2>>$reportfile
echo "DUMP LOG FOR `uname -n`"
# take a snapshot of the dumpdates file and collate it with the
filesystems
cat /etc/dumpdates >/tmp/tmp.`basename $0`
df >>/tmp/tmp.`basename $0`
echo "-------"
echo "Filesystems and their dumpdates (if any):"
sort /tmp/tmp.`basename $0`
echo "-------"
rm -f /tmp/tmp.`basename $0`
if [ $ruid -ne 0 ] ; then {
echo "real user id=$ruid; not root; DUMP aborted. Adieu."
exit -1
fiQuote:}
if [ `mount|grep -c $writeslice` -ne 1 ] ; then {
echo "The write slice $writeslice is not mounted. DUMP
aborted."
exit -1
fiQuote:}
case $weekday in
0) dumplevel=9 ;;
1) dumplevel=3 ;;
2) dumplevel=2 ;;
3) dumplevel=7 ;;
4) dumplevel=5 ;;
5) dumplevel=9 ;;
6) dumplevel=8 ;;
default) echo "Can't get the weekday value. Something is
wrong. Adieu." ;
exit -1 ;;
esac
# The motherlode dump level zero twice a month
if [ $weekday -eq 0 ] && [ $d -lt 8 -o $d -gt 23 ] ; then {
dumplevel=0
fiQuote:}
i=0
for readslice in /sun.usr / /boot ; do {
$gdump -${dumplevel}${dumpopts}
${writeslice}/${dumpfile}.${server}.seq-${i}.lev-${dumplevel}. \
-L "$server $readslice" $readslice
i=`dc -e "$i 1 + p"`
doneQuote:}
/bin/mail -s "`uname -n` DUMP `date`" $mailto <${reportfile}
exit 0