Questions about dump



Hi,

I have a fc3 and a fc4 system that I use dump to backup files. My script for
dump has these lines:

/sbin/dump ${level}uf /dev/nst0 /
/sbin/dump ${level}uf /dev/nst0 /home
/sbin/dump ${level}uf /dev/nst0 /var
/sbin/dump ${level}uf /dev/nst0 /usr

then, the system cronjob sets:

0 23 * * 5 /usr/local/bin/backup_dump_st0.sh 0
0 23 * * 6 /usr/local/bin/backup_dump_st0.sh 9
0 23 * * 0 /usr/local/bin/backup_dump_st0.sh 8
0 23 * * 1 /usr/local/bin/backup_dump_st0.sh 7
0 23 * * 2 /usr/local/bin/backup_dump_st0.sh 6
0 23 * * 3 /usr/local/bin/backup_dump_st0.sh 5

It was working well. Recently, since more users are added and users have more
emails received, sometimes the tape is full. Then, the dump job got aborted.
The message shows something like:

...
DUMP: Volume 1 1972170 blocks (1925.95MB)
DUMP: Volume 1 took 0:14:53
DUMP: Volume 1 transfer rate: 2208 kB/s
DUMP: 1972170 blocks (1925.95MB) on 1 volume(s)
DUMP: finished in 891 seconds, throughput 2213 kBytes/sec
DUMP: Date of this level 7 dump: Mon Jan 30 23:00:13 2006
DUMP: Date this dump completed: Mon Jan 30 23:15:20 2006
DUMP: Average transfer rate: 2208 kB/s
DUMP: DUMP IS DONE
DUMP: Date of this level 7 dump: Mon Jan 30 23:15:20 2006
DUMP: Date of last level 0 dump: Fri Jan 27 23:33:32 2006
DUMP: Dumping /dev/hda3 (/var) to /dev/nst0
DUMP: Label: /var
DUMP: Writing 10 Kilobyte records
DUMP: mapping (Pass I) [regular files]
DUMP: mapping (Pass II) [directories]
DUMP: estimated 3208240 blocks.
DUMP: Volume 1 started with block 1 at: Mon Jan 30 23:15:29 2006
DUMP: dumping (Pass III) [directories]
DUMP: dumping (Pass IV) [regular files]
DUMP: 20.44% done at 2179 kB/s, finished in 0:19
DUMP: 40.83% done at 2179 kB/s, finished in 0:14
DUMP: End of tape detected
DUMP: Closing /dev/nst0
DUMP: Volume 1 completed at: Mon Jan 30 23:29:09 2006
DUMP: Volume 1 1777190 blocks (1735.54MB)
DUMP: Volume 1 took 0:13:40
DUMP: Volume 1 transfer rate: 2167 kB/s
DUMP: Change Volumes: Mount volume #2
DUMP: fopen on /dev/tty fails: No such device or address
DUMP: The ENTIRE dump is aborted.
...
DUMP: Change Volumes: Mount volume #2
DUMP: fopen on /dev/tty fails: No such device or address
DUMP: The ENTIRE dump is aborted.

My questions are:

1. How to make the tape ejected if the tape is full so that I know to insert
the 2nd tape to continue the dump job?

2. How to make the 2nd tape continueing the dump job not finished on Volume 1
tape? What change do I need in my script for dump?

3. Do I need to do anything on tape 2 so that the system knows that it is
Volume 2 for a specific Volume 1 tape?

4. For Volume 1 tape, when I do level 0 dump, it erases the whole tape so that
it has a fresh dump on it. When I reuse the volume 2 tape next time (e.g.
next month), how to erase the tape's previous dumped contents so that it will
have new dump files?

Thanks a lot for any help!

Hongwei Li

--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list



Relevant Pages

  • Multi-tape backup with "dump"
    ... dump wedges when I put in a new tape. ... as much cpu as they can, ... <ACPI PCI bus> on pcib0 ...
    (freebsd-questions)
  • ufsrestore not /dev/fd friendly
    ... I've recently begun keeping dump tapes' contents online. ... Verify tape and initialize maps ... Unfortunately, on Solaris, ufsrestore seems to incorrectly interpret ... resync restore, skipped 1 blocks ...
    (comp.unix.solaris)
  • Re: Dumping SMF directly to TAPE
    ... Actually our SMF dump job dumps to a daily tape which in the next step is mod on to a weekly tape using IEBGENER. ... This proc used the old IBM "SMFDUMP" program to dump all non-empty SMF datasets to DASD GDS. ...
    (bit.listserv.ibm-main)
  • ufsdump/ufsrestore bizarreness, Solaris 8
    ... The tape is on a remote linux system. ... Where the symbols are filled in appropriately for each file system. ... the first dump on the tape was easily restored using the expected sort of inverse operation: ... That is, spool tape -> local disk, send each big chunk from disk over the network to ufsrestore until done. ...
    (comp.sys.sun.admin)
  • Re: Poor SCSI Tape Drive Performance
    ... DUMP: Volume 1 took 6:04:29 ... DUMP: Volume 1 transfer rate: 2849 kB/s ... LTO-3 drives with good results. ... blocksize for my VXA-1 and VXA-2 tape drives is 65536 bytes. ...
    (comp.os.linux.misc)