Professional Web Applications Themes

dump ufsdump via SSH works but.... sometimes core dumps - Linux / Unix Administration

Hello, I have Sun Solaris 8 (2.8) with a SCSI 8mm tape drive that I'm doing ufsdumps via ssh && dd to other Solaris boxes that works just fine. From the tapehost (Box that's has the drive attached) I issue to dump: ssh -l root <remote_host_name_other_sun_box> -n ufsdump 0fu - <file_system_to_be_dumped> | dd bs=64k of=/dev/rmt/0n To get the data back: mt -f /dev/rmt/0 rew mt -f /dev/rmt/0 fsf (if I dumped more than one dump to a single tape....) Then to restore the data: dd bs=64k if=/dev/rmt/0n | ufsrestore vibf 64k - WORKS just fine, speed is great! Like Sliced ...

  1. #1

    Default dump ufsdump via SSH works but.... sometimes core dumps

    Hello,

    I have Sun Solaris 8 (2.8) with a SCSI 8mm tape drive that I'm
    doing ufsdumps via ssh && dd to other Solaris boxes that works
    just fine.

    From the tapehost (Box that's has the drive attached)
    I issue to dump:

    ssh -l root <remote_host_name_other_sun_box> -n ufsdump 0fu -
    <file_system_to_be_dumped> | dd bs=64k of=/dev/rmt/0n

    To get the data back:

    mt -f /dev/rmt/0 rew

    mt -f /dev/rmt/0 fsf (if I dumped more than one dump to a single
    tape....)

    Then to restore the data:


    dd bs=64k if=/dev/rmt/0n | ufsrestore vibf 64k -

    WORKS just fine, speed is great! Like Sliced Bread baby!

    Now I want to do the same thing only dump a Redhat 9.0 box
    to the Sun box.

    This works only for small test dumps, say just /etc or just /var:

    From the tapehost (Box that's has the drive attached)
    I issue

    ssh -l root <remote_host_linux_box> /sbin/dump -0a -f - /var | dd
    bs=64k of=/dev/rmt/0n

    Then to read the tape as usual:

    dd bs=64k if=/dev/rmt/0n | ufsrestore vibf 64k -

    HOWEVER, when the dump is LARGE i.e say dumping root i.e. "/" I the
    dump
    is successful but the restore core dumps:

    # dd bs=64k if=/dev/rmt/0n | ufsrestore vibf 64k -

    Verify volume and initialize maps
    Note: doing byte swapping
    Dump date: Tue Jan 06 13:49:05 2004
    Dumped from: the epoch
    Level 0 dump of / (dir usr) on linuxbox:/dev/hda1
    Label: /
    Extract directories from tape
    Segmentation Fault - core dumped
    uzi69mmm@yahoo.com Guest

  2. #2

    Default Re: dump ufsdump via SSH works but.... sometimes core dumps


    The Institute of Astronomy is part of the Faculty of Physics and
    Chemistry <http://www.ast.cam.ac.uk/physchemfaculty> within the School
    of the Physical Sciences
    <http://www.cam.ac.uk/cambuniv/schools/physsci/> of The University of
    Cambridge <http://www.cam.ac.uk/>

    top <http://www.ast.cam.ac.uk/mrtg/#top> | home
    <http://www.ast.cam.ac.uk/> | search
    <http://www.ast.cam.ac.uk/search/> | comments
    <http://www.ast.cam.ac.uk/contact/form.html?contact=webman> | help
    <http://www.ast.cam.ac.uk/help> Page last saved: 28th October 2003 by


    The Institute of Astronomy is part of the Faculty of Physics and
    Chemistry <http://www.ast.cam.ac.uk/physchemfaculty> within the School
    of the Physical Sciences
    <http://www.cam.ac.uk/cambuniv/schools/physsci/> of The University of
    Cambridge <http://www.cam.ac.uk/>

    top <http://www.ast.cam.ac.uk/mrtg/#top> | home
    <http://www.ast.cam.ac.uk/> | search
    <http://www.ast.cam.ac.uk/search/> | comments
    <http://www.ast.cam.ac.uk/contact/form.html?contact=webman> | help
    <http://www.ast.cam.ac.uk/help> Page last saved: 28th October 2003 by


    The Institute of Astronomy is part of the Faculty of Physics and
    Chemistry <http://www.ast.cam.ac.uk/physchemfaculty> within the School
    of the Physical Sciences
    <http://www.cam.ac.uk/cambuniv/schools/physsci/> of The University of
    Cambridge <http://www.cam.ac.uk/>

    top <http://www.ast.cam.ac.uk/mrtg/#top> | home
    <http://www.ast.cam.ac.uk/> | search
    <http://www.ast.cam.ac.uk/search/> | comments
    <http://www.ast.cam.ac.uk/contact/form.html?contact=webman> | help
    <http://www.ast.cam.ac.uk/help> Page last saved: 28th October 2003 by



    [email]uzi69mmm[/email] wrote:
    >Hello,
    >
    >I have Sun Solaris 8 (2.8) with a SCSI 8mm tape drive that I'm
    >doing ufsdumps via ssh && dd to other Solaris boxes that works
    >just fine.
    >
    >From the tapehost (Box that's has the drive attached)
    >I issue to dump:
    >
    >ssh -l root <remote_host_name_other_sun_box> -n ufsdump 0fu -
    ><file_system_to_be_dumped> | dd bs=64k of=/dev/rmt/0n
    >
    >To get the data back:
    >
    >mt -f /dev/rmt/0 rew
    >
    >mt -f /dev/rmt/0 fsf (if I dumped more than one dump to a single
    >tape....)
    >
    >Then to restore the data:
    >
    >
    >dd bs=64k if=/dev/rmt/0n | ufsrestore vibf 64k -
    >
    >WORKS just fine, speed is great! Like Sliced Bread baby!
    >
    >Now I want to do the same thing only dump a Redhat 9.0 box
    >to the Sun box.
    >
    >This works only for small test dumps, say just /etc or just /var:
    >
    >From the tapehost (Box that's has the drive attached)
    >I issue
    >
    >ssh -l root <remote_host_linux_box> /sbin/dump -0a -f - /var | dd
    >bs=64k of=/dev/rmt/0n
    >
    >Then to read the tape as usual:
    >
    >dd bs=64k if=/dev/rmt/0n | ufsrestore vibf 64k -
    >
    >HOWEVER, when the dump is LARGE i.e say dumping root i.e. "/" I the
    >dump
    >is successful but the restore core dumps:
    >
    ># dd bs=64k if=/dev/rmt/0n | ufsrestore vibf 64k -
    >
    >Verify volume and initialize maps
    >Note: doing byte swapping
    >Dump date: Tue Jan 06 13:49:05 2004
    >Dumped from: the epoch
    >Level 0 dump of / (dir usr) on linuxbox:/dev/hda1
    >Label: /
    >Extract directories from tape
    >Segmentation Fault - core dumped
    >
    >
    So you're trying to do a Solaris ufsrestore on a Linux dump - do you
    expect that to work?

    Pete.

    Peter Bunclark Guest

  3. #3

    Default Re: dump ufsdump via SSH works but.... sometimes core dumps

    Peter Bunclark wrote:
    >
    < lots of garbage snipped >
    >
    > So you're trying to do a Solaris ufsrestore on a Linux dump - do you
    > expect that to work?
    >
    > Pete.

    No, he was trying to dump from a Linux machine to a Sun tape drive and
    then restore back to the Linux machine. Nothing wrong with the
    concept. The problem is that dump for Linux does not work well. In
    Linus Torvalds' words:

    "Dump was a stupid program in the first place. Leave it behind."

    You can find out more about his thoughts on dump at:

    [url]http://lwn.net/2001/0503/a/lt-dump.php3[/url]

    I use Gnu tar to backup machines across the network and it works fine.

    Good luck,

    Steve
    --
    __________________________________________________ ___________
    Steve Cousins Email: [email]cousinsumit.maine.edu[/email]
    Research Associate Phone: (207) 581-4302
    Ocean Modeling Group
    School of Marine Sciences 208 Libby Hall,
    University of Maine Orono ME 04469
    Steve Cousins Guest

  4. #4

    Default Re: dump ufsdump via SSH works but.... sometimes core dumps

    In article <3FFC4960.F89653A2maine.edu>,
    Steve Cousins <steve.cousinsmaine.edu> wrote:
    > No, he was trying to dump from a Linux machine to a Sun tape drive and
    > then restore back to the Linux machine.
    No. he did the dump on the Linux machine to a Sun tape drive and then
    tried to use ufsrestore on the Sun to read the tape:

    | # dd bs=64k if=/dev/rmt/0n | ufsrestore vibf 64k -
    |
    | Verify volume and initialize maps
    | Note: doing byte swapping
    | Dump date: Tue Jan 06 13:49:05 2004
    | Dumped from: the epoch
    | Level 0 dump of / (dir usr) on linuxbox:/dev/hda1
    | Label: /
    | Extract directories from tape
    | Segmentation Fault - core dumped

    He runs ufsrestore on something that has a different byte order than
    the Linux machine (note the "Note: doing byte swapping" from ufsrestore)
    and as restore is called restore in Linux and ufsrestore in Solaris he
    certainly is not trying to do the restore on the Linux machine, most likely
    on he is doing it on the Sun.
    > Nothing wrong with the concept.
    It will not work. The dump format is not portable between implementations.
    > I use Gnu tar to backup machines across the network and it works fine.
    I would never trust GNU tar to do any of my backups. It is seriously
    broken and is not compatible with what the POSIX standard has to say
    about tar.

    --
    Göran Larsson [url]http://www.mitt-eget.com/[/url]
    Goran Larsson Guest

  5. #5

    Default Re: dump ufsdump via SSH works but.... sometimes core dumps



    Goran Larsson wrote:
    >
    > In article <3FFC4960.F89653A2maine.edu>,
    > Steve Cousins <steve.cousinsmaine.edu> wrote:
    >
    > > No, he was trying to dump from a Linux machine to a Sun tape drive and
    > > then restore back to the Linux machine.
    >
    > No. he did the dump on the Linux machine to a Sun tape drive and then
    > tried to use ufsrestore on the Sun to read the tape:
    You are correct! Sorry about that.
    > | # dd bs=64k if=/dev/rmt/0n | ufsrestore vibf 64k -
    As Goran says, this will not work. ufsrestoring a linux dump is not
    going to work due to different file systems as well as endian problems.
    > |
    > | Verify volume and initialize maps
    > | Note: doing byte swapping
    > | Dump date: Tue Jan 06 13:49:05 2004
    > | Dumped from: the epoch
    > | Level 0 dump of / (dir usr) on linuxbox:/dev/hda1
    > | Label: /
    > | Extract directories from tape
    > | Segmentation Fault - core dumped
    >
    > He runs ufsrestore on something that has a different byte order than
    > the Linux machine (note the "Note: doing byte swapping" from ufsrestore)
    > and as restore is called restore in Linux and ufsrestore in Solaris he
    > certainly is not trying to do the restore on the Linux machine, most likely
    > on he is doing it on the Sun.
    >
    > > Nothing wrong with the concept.
    >
    > It will not work. The dump format is not portable between implementations.
    As I (mis)read it the concept was ok. Of course, you can prove anything
    if you start with a false premise :*)
    > > I use Gnu tar to backup machines across the network and it works fine.
    >
    > I would never trust GNU tar to do any of my backups. It is seriously
    > broken and is not compatible with what the POSIX standard has to say
    > about tar.
    What do you use to backup linux machines? cpio? pax? There were a couple
    of versions of Gnu tar that did have some problems but I've used Gnu tar
    backups of some sort or another for many years with good results. I
    primarily use it now because of the ability to do incremental backups,
    which AFAIK can't be done with the non-Gnu tar.

    Steve
    __________________________________________________ ___________
    Steve Cousins Email: [email]cousinsumit.maine.edu[/email]
    Research Associate Phone: (207) 581-4302
    Ocean Modeling Group
    School of Marine Sciences 208 Libby Hall,
    University of Maine Orono ME 04469
    Steve Cousins Guest

  6. #6

    Default Re: dump ufsdump via SSH works but.... sometimes core dumps

    Steve Cousins wrote:
    > No, he was trying to dump from a Linux machine to a Sun tape drive and
    > then restore back to the Linux machine. Nothing wrong with the
    > concept. The problem is that dump for Linux does not work well. In
    > Linus Torvalds' words:
    >
    > "Dump was a stupid program in the first place. Leave it behind."
    >
    > You can find out more about his thoughts on dump at:
    >
    > [url]http://lwn.net/2001/0503/a/lt-dump.php3[/url]
    >
    > I use Gnu tar to backup machines across the network and it works fine.
    There is more info about the dump 'bug' in: [url]http://dump.sourceforge.net/isdumpdeprecated.html[/url]

    Xose Vazquez Perez Guest

  7. #7

    Default Re: dump ufsdump via SSH works but.... sometimes core dumps

    In article <3FFC911D.B9C10372maine.edu>,
    Steve Cousins <steve.cousinsmaine.edu> wrote:
    > What do you use to backup linux machines?
    Nothing. I don't backup any Linux machines, only Solaris machines.
    The Solaris machines are backed up by my own backup system that
    uses ufsdump inside.
    > There were a couple
    > of versions of Gnu tar that did have some problems but I've used Gnu tar
    > backups of some sort or another for many years with good results.
    You will find that it is likely only GNU tar that can read your
    backups. That might be ok if you know about this and treat GNU tar as
    having a proprietary format.
    > I
    > primarily use it now because of the ability to do incremental backups,
    > which AFAIK can't be done with the non-Gnu tar.
    The tar implementation "star" should be able to do what you require and
    still create POSIX compliant backups.

    --
    Göran Larsson [url]http://www.mitt-eget.com/[/url]
    Goran Larsson Guest

  8. #8

    Default Re: dump ufsdump via SSH works but.... sometimes core dumps

    In article <3FFC911D.B9C10372maine.edu>,
    Steve Cousins <steve.cousinsmaine.edu> wrote:
    >
    >> | # dd bs=64k if=/dev/rmt/0n | ufsrestore vibf 64k -
    >
    >As Goran says, this will not work. ufsrestoring a linux dump is not
    >going to work due to different file systems as well as endian problems.
    A real dump is able to deal with endian problems, there is a endian-structure
    decoder in restore.
    >> | Dump date: Tue Jan 06 13:49:05 2004
    >> | Dumped from: the epoch
    >> | Level 0 dump of / (dir usr) on linuxbox:/dev/hda1
    >> | Label: /
    >> | Extract directories from tape
    >> | Segmentation Fault - core dumped
    >>
    >> He runs ufsrestore on something that has a different byte order than
    >> the Linux machine (note the "Note: doing byte swapping" from ufsrestore)
    >> and as restore is called restore in Linux and ufsrestore in Solaris he
    >> certainly is not trying to do the restore on the Linux machine, most likely
    >> on he is doing it on the Sun.
    >>
    >> > Nothing wrong with the concept.
    >>
    >> It will not work. The dump format is not portable between implementations.
    >
    >As I (mis)read it the concept was ok. Of course, you can prove anything
    >if you start with a false premise :*)
    Many dump formats are portable, but note: the dump format is not a standard.
    Anything may be changed without notice and cause problems.
    >> > I use Gnu tar to backup machines across the network and it works fine.
    >>
    >> I would never trust GNU tar to do any of my backups. It is seriously
    >> broken and is not compatible with what the POSIX standard has to say
    >> about tar.
    >
    >What do you use to backup linux machines? cpio? pax? There were a couple
    >of versions of Gnu tar that did have some problems but I've used Gnu tar
    >backups of some sort or another for many years with good results. I
    >primarily use it now because of the ability to do incremental backups,
    >which AFAIK can't be done with the non-Gnu tar.
    GNU tar definitely cannot do incremental backups.

    Many people believe that it can (it is even in the doentation), but
    when you have a closer look at the basic idea and the implementation,
    you will see that it has problems in design and implementation.
    Even if it would work, it would cause a lot more tape to be written
    than needed with ufsdump or star.

    Star supports true incremental backups, it is not yet ready with its
    incremental restore.

    [url]ftp://ftp.berlios.de/pub/star/alpha/[/url]

    Star implements the same basic idea as ufsdump does. For this reason,
    star has exactly the same problems (except for consistency).
    The known problems with the incremental method used by star/ufsdump is that
    it misses files that are created between incremenrtal backups where somebody
    did set the mtime back to a value before the last full/incremental dump.

    Star is based on the latest POSIX TAR standard and I hope that I will in future
    be able to standardise the enhancemnts that are needeed to allow incremental
    backups.

    --
    EMail:joergschily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
    [email]jscs.tu-berlin.de[/email] (uni) If you don't have iso-8859-1
    [email]schillingfokus.fraunhofer.de[/email] (work) chars I am J"org Schilling
    URL: [url]http://www.fokus.fraunhofer.de/usr/schilling[/url] [url]ftp://ftp.berlios.de/pub/schily[/url]
    Joerg Schilling Guest

  9. #9

    Default Re: dump ufsdump via SSH works but.... sometimes core dumps

    In article <3FFC9EF7.2000505wanadoo.es>,
    Xose Vazquez Perez <DELETExosewanadoo.es> wrote:
    >Steve Cousins wrote:
    >
    >> No, he was trying to dump from a Linux machine to a Sun tape drive and
    >> then restore back to the Linux machine. Nothing wrong with the
    >> concept. The problem is that dump for Linux does not work well. In
    >> Linus Torvalds' words:
    >>
    >> "Dump was a stupid program in the first place. Leave it behind."
    >>
    >> You can find out more about his thoughts on dump at:
    >>
    >> [url]http://lwn.net/2001/0503/a/lt-dump.php3[/url]
    >>
    >> I use Gnu tar to backup machines across the network and it works fine.
    >
    >There is more info about the dump 'bug' in: [url]http://dump.sourceforge.net/isdumpdeprecated.html[/url]
    What these URLs describe are problems caused by an inconsistend Linux buffer
    cache design. The real problems with the dump method are:

    - general problems with life filesystems (not caused by the Linux design
    problems), these can be solved by fssnap (avaliable since January 2001.
    Either with Solaris 9 FCS or the Solaris 8 update that came out the same
    time, FreeBSD introduced a similar thing at the same time).

    - A nonstandard and not really portable archive format.

    - Filesystem type specifics prevent you from using the same backup utility
    for a bunch of different filesystems.

    - It is just wrong to assume that an instance besides the kernel fs
    implementation knows how to read the raw disk device.

    It is a bad idea to access the raw disk for backup purposes.

    - ufsdump is slow! It's antique design does not allow to have decent
    bufering.

    Star allows to virtually use any FIFO size. Defining e.g. 256 MB of FIFO
    works with star and will give you more than 30 seconds tape streaming
    reserve, even with modern fast tape drives.

    - The ufsrestore interface ist just significantly worse and less flexible
    than what you may do with star when it comes to restoring only a
    specific choice of files.

    - Ufsdump only works if you are root. It is impossible to use just one
    utility/archive-format for every day data exchange and backups.

    --
    EMail:joergschily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
    [email]jscs.tu-berlin.de[/email] (uni) If you don't have iso-8859-1
    [email]schillingfokus.fraunhofer.de[/email] (work) chars I am J"org Schilling
    URL: [url]http://www.fokus.fraunhofer.de/usr/schilling[/url] [url]ftp://ftp.berlios.de/pub/schily[/url]
    Joerg Schilling Guest

  10. #10

    Default Re: dump ufsdump via SSH works but.... sometimes core dumps

    In article <Hr5As7.JvAapprove.se>, Goran Larsson <hohinvalid.invalid> wrote:
    >> There were a couple
    >> of versions of Gnu tar that did have some problems but I've used Gnu tar
    >> backups of some sort or another for many years with good results.
    >
    >You will find that it is likely only GNU tar that can read your
    >backups. That might be ok if you know about this and treat GNU tar as
    >having a proprietary format.
    Beware: Even GNU tar will not read back GNU tar dumps in many cases.

    In case that you need to do multi-volume backups with GNU tar, GNU tar
    implements a chance from 1-5% that it will not acept a continuation
    volume. Star will be able to read those multi-volume GNU tar archives but
    star does not implement GNU tars pseudo incremental backup system.
    The reason is that the GNU tar incremental method does not work well and star
    implements a better method.

    --
    EMail:joergschily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
    [email]jscs.tu-berlin.de[/email] (uni) If you don't have iso-8859-1
    [email]schillingfokus.fraunhofer.de[/email] (work) chars I am J"org Schilling
    URL: [url]http://www.fokus.fraunhofer.de/usr/schilling[/url] [url]ftp://ftp.berlios.de/pub/schily[/url]
    Joerg Schilling Guest

  11. #11

    Default Re: dump ufsdump via SSH works but.... sometimes core dumps

    In article <Hr5As7.JvAapprove.se>, Goran Larsson <hohinvalid.invalid> wrote:
    >In article <3FFC911D.B9C10372maine.edu>,
    >> I
    >> primarily use it now because of the ability to do incremental backups,
    >> which AFAIK can't be done with the non-Gnu tar.
    >
    >The tar implementation "star" should be able to do what you require and
    >still create POSIX compliant backups.
    You may already do incremental backups using star (it implements the same basic
    ideas as ufsdump does), but the incremental restore is not yet ready.

    In case that files have been removed or renamed, you would need this specific
    incremental restore feature. I expect about one man month of work until the
    incremental restore is ready.

    As I did rewrite about 2/3 of star during that last 6 months, I need a small
    break and currently rather work on cdrtools.

    --
    EMail:joergschily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
    [email]jscs.tu-berlin.de[/email] (uni) If you don't have iso-8859-1
    [email]schillingfokus.fraunhofer.de[/email] (work) chars I am J"org Schilling
    URL: [url]http://www.fokus.fraunhofer.de/usr/schilling[/url] [url]ftp://ftp.berlios.de/pub/schily[/url]
    Joerg Schilling Guest

  12. #12

    Default Re: dump ufsdump via SSH works but.... sometimes core dumps

    > It will not work. The dump format is not portable between implementations.

    Unless I missed something in my first post. The DUMP does work.
    i.e. A sun ufsdump can "read" linux Dump. I've done AIX dump
    and if you play with the correct blocks, ufsdump can read them...
    uzi69mmm@yahoo.com Guest

  13. #13

    Default Re: dump ufsdump via SSH works but.... sometimes core dumps

    On Thu, 08 Jan 2004 01:01:49 +0000, Joerg Schilling wrote:
    > - ufsdump is slow! It's antique design does not allow to have decent
    > bufering.
    >
    > Star allows to virtually use any FIFO size. Defining e.g. 256 MB of FIFO
    > works with star and will give you more than 30 seconds tape streaming
    > reserve, even with modern fast tape drives.
    >
    > - The ufsrestore interface ist just significantly worse and less flexible
    > than what you may do with star when it comes to restoring only a
    > specific choice of files.
    Disclaimer: Joerg is the author of star.

    Ed Murphy Guest

  14. #14

    Default Re: dump ufsdump via SSH works but.... sometimes core dumps

    Joerg Schilling wrote:
    >
    > GNU tar definitely cannot do incremental backups.
    What should I do with the GNU tar incremental tapes that I have been
    backing up to and restoring from? I'm not sure what your reasoning is.
    Maybe it isn't as efficient as dump would be (if dump worked
    consistently), I don't know. But as someone who wants to be able to
    back up just the files that have changed since the last full backup I
    find that it works very well. Backups are quick and use just a small
    amount of tape compared to the full backup. And of course I need to be
    able to restore from these tapes, which I can. This fits my need for
    incremental backups. I haven't tried to do multiple levels of
    incremental backups and it seems that it can't do this (maybe I'm wrong
    about this, I haven't looked into it). However, I've never found
    multi-level ufsdumps to be that handy. I currently just do full and one
    level of incrementals for our Sun machines. Restores are much simpler
    this way.

    I have GNU Tar on my IRIX and Tru64 machines too and I've not had
    problems reading the Linux GNU Tar files. Maybe STAR would be the answer
    to my dreams but GNU Tar does everything I need right now so I won't be
    trying to fix something that isn't broken.

    Regards,

    Steve

    __________________________________________________ ___________
    Steve Cousins Email: [email]cousinsumit.maine.edu[/email]
    Research Associate Phone: (207) 581-4302
    Ocean Modeling Group
    School of Marine Sciences 208 Libby Hall,
    University of Maine Orono ME 04469
    Steve Cousins Guest

  15. #15

    Default Re: dump ufsdump via SSH works but.... sometimes core dumps

    In article <3FFD73EB.9FA792E8maine.edu>,
    Steve Cousins <steve.cousinsmaine.edu> wrote:
    >Joerg Schilling wrote:
    >>
    >> GNU tar definitely cannot do incremental backups.
    >
    >What should I do with the GNU tar incremental tapes that I have been
    >backing up to and restoring from? I'm not sure what your reasoning is.
    If you are _really_ happy with it....
    >Maybe it isn't as efficient as dump would be (if dump worked
    >consistently), I don't know. But as someone who wants to be able to
    I forgot the exact background, but about 1-3 years ago, I did several tests
    when I was planning the incremental backup method for star.

    During this tests, it turned out, that there are cases that are not handled
    correctly by GNU tar. You will not become aware of the problems until you
    start to restore the incrementals from scratch.

    Also note that if you rename a directory or chmod a large file, a GNU tar
    incremental may be many gigabytes in size while a star or ufsdumo incremental
    is only a few kilobytes.
    >back up just the files that have changed since the last full backup I
    >find that it works very well. Backups are quick and use just a small
    >amount of tape compared to the full backup. And of course I need to be
    The size that you observe seems to be a result of your usage profile.
    A ufsdump or star incremental is typically much smaller.
    >able to restore from these tapes, which I can. This fits my need for
    Well, did you ever try to restore?
    >incremental backups. I haven't tried to do multiple levels of
    >incremental backups and it seems that it can't do this (maybe I'm wrong
    GNU tar does not allow more than full + one incr. level which is bad.

    Star allows any number of levels, I did limit the max level to 99
    to make it simpler to print the numbers.
    >about this, I haven't looked into it). However, I've never found
    >multi-level ufsdumps to be that handy. I currently just do full and one
    >level of incrementals for our Sun machines. Restores are much simpler
    >this way.
    A typical ufsdump usage is to have three different levels:

    - Level 0 == full backup

    - Level 1 done weekly

    - Level 2 done daily you overwrite this tape after the next
    weekly incremental has been made.

    If you make level 0 dumps less frequent than once a month, you may like
    to add another incremental level.

    Please don't forget that there is a 1-5% chance that GNU tar does not
    accept to read in a continuatuion volume from a multi _volume_ backup.
    This is also something that you will never become aware unless you make
    a restore test.

    --
    EMail:joergschily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
    [email]jscs.tu-berlin.de[/email] (uni) If you don't have iso-8859-1
    [email]schillingfokus.fraunhofer.de[/email] (work) chars I am J"org Schilling
    URL: [url]http://www.fokus.fraunhofer.de/usr/schilling[/url] [url]ftp://ftp.berlios.de/pub/schily[/url]
    Joerg Schilling Guest

Similar Threads

  1. Set::Array core dumps in for loop
    By Sisyphos in forum PERL Modules
    Replies: 1
    Last Post: June 9th, 04:11 AM
  2. ufsdump vs dump
    By hemiguy in forum Sun Solaris
    Replies: 1
    Last Post: August 1st, 12:34 AM
  3. gui smit core dumps only for certain users
    By Michelle DeVault in forum AIX
    Replies: 0
    Last Post: July 18th, 07:43 PM
  4. Replies: 6
    Last Post: June 25th, 08:49 PM
  5. Replies: 0
    Last Post: June 24th, 06:36 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