Professional Web Applications Themes

Backup on DDS-4 tapes - FreeBSD

Hi, I am using 5.2.1-RELEASE-p3 for backup on DDS-4 tapes 40GB in size. # df -k Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/vinum/root 1016162 157405 777465 17% / devfs 1 1 0 100% /dev /dev/vinum/usr 84746248 54467390 23499160 70% /usr procfs 4 4 0 100% /proc # camcontrol devlist -v scbus0 on ahd0 bus 0: <IBM IC35L018UWD210-0 S5BS> at scbus0 target 3 lun 0 (pass0,da0) <IBM IC35L073UWDY10-0 S25F> at scbus0 target 9 lun 0 (pass1,da1) <HP C5683A C005> at scbus0 target 10 lun 0 (sa0,pass2) < > at scbus0 target -1 lun -1 () scbus1 on ahd1 bus 0: ...

  1. #1

    Default Backup on DDS-4 tapes


    Hi,

    I am using 5.2.1-RELEASE-p3 for backup on DDS-4 tapes 40GB in size.

    # df -k
    Filesystem 1K-blocks Used Avail Capacity Mounted on
    /dev/vinum/root 1016162 157405 777465 17% /
    devfs 1 1 0 100% /dev
    /dev/vinum/usr 84746248 54467390 23499160 70% /usr
    procfs 4 4 0 100% /proc
    # camcontrol devlist -v
    scbus0 on ahd0 bus 0:
    <IBM IC35L018UWD210-0 S5BS> at scbus0 target 3 lun 0 (pass0,da0)
    <IBM IC35L073UWDY10-0 S25F> at scbus0 target 9 lun 0 (pass1,da1)
    <HP C5683A C005> at scbus0 target 10 lun 0 (sa0,pass2)
    < > at scbus0 target -1 lun -1 ()
    scbus1 on ahd1 bus 0:
    <IBM IC35L018UWD210-0 S5BS> at scbus1 target 1 lun 0 (pass3,da2)
    <IBM IC35L073UWDY10-0 S23C> at scbus1 target 8 lun 0 (pass4,da3)
    < > at scbus1 target -1 lun -1 ()
    scbus-1 on xpt0 bus 0:
    < > at scbus-1 target -1 lun -1 (xpt0)
    # /sbin/dump -SLu0 -B 41943040 -C 32 -f /dev/sa0 /usr
    DUMP: Date of this level 0 dump: Mon Mar 14 10:29:51 2005
    DUMP: Date of last level 0 dump: the epoch
    DUMP: Dumping snapshot of /dev/vinum/usr (/usr) to /dev/sa0
    DUMP: mapping (Pass I) [regular files]
    DUMP: Cache 32 MB, blocksize = 65536
    DUMP: mapping (Pass II) [directories]
    DUMP: estimated 54189311 tape blocks on 1.29 tape(s).
    #
    # mt -f /dev/sa0 status
    Mode Density Blocksize bpi Compression
    Current: 0x26:DDS-4 variable 97000 DCLZ
    ---------available modes---------
    0: 0x26:DDS-4 variable 97000 DCLZ
    1: 0x26:DDS-4 variable 97000 DCLZ
    2: 0x26:DDS-4 variable 97000 DCLZ
    3: 0x26:DDS-4 variable 97000 DCLZ
    ---------------------------------
    Current Driver State: at rest.
    ---------------------------------
    File Number: 0 Record Number: 0 Residual Count 0

    I am using the following command:

    # /sbin/dump -Lu0 -B 41943040 -C 32 -f /dev/sa0 /usr

    or

    # /sbin/dump -aLu0 -C 32 -f /dev/sa0 /usr

    Why I cannot dump the filesystem on 2 tapes (it takes 3, it seems it
    works without compression) no matter if I use dump or cpio? What I am
    doing wrong?

    Any hints appreciated. Thank you very much in advance.

    Regards,

    lk
    Ludo Guest

  2. #2

    Default Re: Backup on DDS-4 tapes

    On Monday, 14 March 2005 at 10:38:02 +0100, Ludo Koren wrote: 

    You're using dump :-)

    Dump is too stupid to understand compression or EOF marks, so it errs
    on the side of caution. It's also IMO not a very good backup medium
    unless you really want the incremental dump facility. Even between
    different releases of FreeBSD there are compatibility problems, and
    you can assume that there is no compatibility at all between different
    operating systems. You may find tar a better choice.

    Greg
    --
    When replying to this message, please copy the original recipients.
    If you don't, I may ignore the reply or reply to the original recipients.
    For more information, see http://www.lemis.com/questions.html
    See complete headers for address and phone numbers.

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.2.6 (FreeBSD)

    iD8DBQFCNjSHIubykFB6QiMRArWOAJ4u/jWU5LIhtOS+btqWg4DG8jHhlwCgs68K
    yytUWMx058En6grAtTosFkc=
    =G67J
    -----END PGP SIGNATURE-----

    Greg Guest

  3. #3

    Default Re: Backup on DDS-4 tapes

    Ludo Koren wrote:
     
    I would guess that your tape drive does hardware compression in which
    case the amount of data which fits on a tape is variable. In such a
    case you can't tell dump how big the tape is -- I haven't used options
    like -B since 1600bpi reel-to-reel tapes, except in my day you specified
    how many feet of tape you had :-)

    from man dump

    -a ``auto-size''. Bypass all tape length considerations, and
    enforce writing until an end-of-media indication is returned.
    This fits best for most modern tape drives. Use of this option
    is particularly recommended when appending to an existing tape,
    or using a tape drive with hardware compression (where you can
    never be sure about the compression ratio).

    Don't know -L, must be a 5.x thing. Try:

    /sbin/dump -Lu0 -a -C 32 -f /dev/sa0 /usr

    I use -b 64 as well.

    Use cpio/tar at your peril as they may not do devices right and may not understand filesystem flags.

    --Alex

    Alex Guest

  4. #4

    Default Re: Backup on DDS-4 tapes

     
     [/ref]
     
     

    Surprisingly

    http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/backup-basics.html

    in 16.1.7 suggests dump, though as the reference is used (maybe)
    outdated E. Zwicky link...

    Anyway, cpio cannot handle the problem too, and the tar in
    5.2.1-RELEASE-p3 can handle multi-volume backup, but in the 5.3-STABLE
    don't according to the man page.

    I wonder what is then the best solution.

    Regards,

    lk
    Ludo Guest

  5. #5

    Default Re: Backup on DDS-4 tapes


     
    > I would guess that your tape drive does hardware compression in
    > which case the amount of data which fits on a tape is variable.
    > In such a case you can't tell dump how big the tape is -- I
    > haven't used options like -B since 1600bpi reel-to-reel tapes,
    > except in my day you specified how many feet of tape you had
    > :-)[/ref]
     
     

    It doesn't help either... The result is the same.
     

    -L This option is to notify dump that it is dumping a live file sys-
    tem. To obtain a consistent dump image, dump takes a snapshot of
    the file system in the .snap directory in the root of the
    filesystem being dumped and then does a dump of the snapshot.
    The snapshot is removed when the dump is complete. If the .snap
    directory does not exist in the root of the filesystem being
    dumped, the dump will fail. This problem can be corrected by
    creating a .snap directory in the root of the filesystem to be
    dumped; its owner should be root, its group should be operator,
    and its mode should be 0770.

     
     
     
     

    lk
    Ludo Guest

  6. #6

    Default RE: Backup on DDS-4 tapes


     
     

    I have never found multivolume tar archives to work unless I defined
    the size of each tape. Waiting for the tape device to return an EOT
    to the tar program always ended up with junk.

    If the tar in 5.3 doesen't have this option any longer why don't you
    compile a tar that does?

    Anyway, I think your problem is your tape device has it's dip switch
    set to disable compression. In that position it takes a SCSI command
    to turn compression on. If you flip the switch then the tape device
    starts with compression on, and it takes a scsi command to turn it
    off. This is hardware compression I am referring to, of course.

    Ted
    Ted Guest

  7. #7

    Default Re: Backup on DDS-4 tapes

    Ludo Koren wrote:
     
    Just to check I'm understanding your problem correctly -- you're
    expecting to write much more data to the tape than is actually being
    written.

    If that's correct, then there's a couple things I can think of:

    1) Your tape drive isn't doing hardware compression. Check the manual
    and see if there are any dip switches you need to set. (Make a note of
    how they're set before you change anything, so you can go back to what
    you had originally!).

    When you say the result is the same, if it used exactly the same number
    of tapes (down to the decimal point) then that definitely suggests that
    your tape drive is not compressing.

    2) The data you're writing to the tape is already mostly compressed, so
    you won't fit as much as you might if it were uncompressed data.

    Also, the 40Gb per tape that you quote is, I think, the MAXIMUM amount
    of data the tape will take. It's only 20Gb native. 40Gb is how much
    will fit at optimum compression, which you never get.

    It's unlikely to be a FreeBSD problem because I regularly fit 6-7Gb on a
    DDS-2, which has a native size of 4Gb. I use dump options like the ones
    in my last message.

    --Alex

    Alex Guest

  8. #8

    Default Re: Backup on DDS-4 tapes

     
    > Just to check I'm understanding your problem correctly --
    > you're expecting to write much more data to the tape than is
    > actually being written.[/ref]

    That's right. I suppose that 54GB of data could fit on 2 40GB tapes...
     
     

    I'll check this
     
     

    I will do statistics about files.
     
     
     

    Thank, for your suggestions.

    lk
    Ludo Guest

Similar Threads

  1. DDS3 and DDS4 tapes in a DDS2 tape drive??
    By Kurt in forum Sun Solaris
    Replies: 4
    Last Post: April 16th, 03:34 PM
  2. USB backup from APC?
    By Ralph in forum FreeBSD
    Replies: 0
    Last Post: February 23rd, 08:52 PM
  3. DDS1 tapes
    By John Willis in forum Linux / Unix Administration
    Replies: 2
    Last Post: December 21st, 02:03 PM
  4. loop - begin backup, end backup Oracle 8.1.7
    By Matthias Arth in forum Oracle Server
    Replies: 1
    Last Post: December 27th, 08:53 PM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139