comp.os.linux, comp.os.linux.questions, comp.os.linux.misc

comp.os.linux, comp.os.linux.questions, comp.os.linux.misc

Post by gaius.petroni » Sat, 24 Nov 2001 14:20:27

James Howard writes:
>: A lot of people said this.  Why?  As near as I can tell, dump isn't
>: great either.  There is no way to exlude specific directories with
>: and it appears to be quite painful to restore a specific directory
>: 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.


>with "unsubscribe freebsd-hackers" in the body of the message

i also used to have complete faith in Mr. dump in all his various
forms (like ufsdump) until one day i discovered that he was not

system: Linux 7.1
dump method: dump to files on another slice

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

The output of dump doesn't really give me any clues:
cat /var/log/gdump.fang.2001-11-23.11:36
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
  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
-rw-r--r--    1 root     root     2147483647 Nov 22 17:57
-rw-r--r--    1 root     root     2147483647 Nov 23 04:28
-rw-r--r--    1 root     root     2147483647 Nov 23 11:33

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

cave Jabberwock


# 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`
ruid=`id -ru`
#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
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



if [ `mount|grep -c $writeslice` -ne 1 ] ; then {
        echo "The write slice $writeslice is not mounted. DUMP
        exit -1



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

# The motherlode dump level zero twice a month
if [ $weekday -eq 0 ] && [ $d -lt 8 -o $d -gt 23 ] ; then {



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



/bin/mail -s "`uname -n` DUMP `date`" $mailto <${reportfile}
exit 0