ufsdump/restore size limit? - SUN

This is a discussion on ufsdump/restore size limit? - SUN ; I'm having a problem restoring a fairly large file system under Solaris 8. The hardware is a Sun Fire V240, with a third-party SCSI-to-SCSI raid controller. The filesystem is just shy of 300 GB, with about 100 GB in use. ...

+ Reply to Thread
Results 1 to 8 of 8

Thread: ufsdump/restore size limit?

  1. ufsdump/restore size limit?

    I'm having a problem restoring a fairly large file system under Solaris 8.
    The hardware is a Sun Fire V240, with a third-party SCSI-to-SCSI raid
    controller. The filesystem is just shy of 300 GB, with about 100 GB in
    use. We're using ufs, and ufsdump and ufsrestore, dumping to an SDLT
    drive that's directly attached to the V240. We are current with Solaris
    8 patches.

    We periodically restore the dumps to an old machine that we use for
    testing, just to make sure that they can be restored. I can no longer
    restore the dumps -- ufsrestore asks for a second tape, when there isn't
    one. Even if we dump to a file on another server, and then try to
    restore from that, ufsdump still asks for a second tape/file to restore
    from. The dump files don't appear to be truncated.

    Are there any limits to what ufsdump & restore can handle? I sure
    can't find anything about this.
    --
    Jeff Wieland

  2. Re: ufsdump/restore size limit?

    In article ,
    Jeff Wieland wrote:

    > I'm having a problem restoring a fairly large file system under Solaris 8.
    > The hardware is a Sun Fire V240, with a third-party SCSI-to-SCSI raid
    > controller. The filesystem is just shy of 300 GB, with about 100 GB in
    > use. We're using ufs, and ufsdump and ufsrestore, dumping to an SDLT
    > drive that's directly attached to the V240. We are current with Solaris
    > 8 patches.
    >
    > We periodically restore the dumps to an old machine that we use for
    > testing, just to make sure that they can be restored. I can no longer
    > restore the dumps -- ufsrestore asks for a second tape, when there isn't
    > one. Even if we dump to a file on another server, and then try to
    > restore from that, ufsdump still asks for a second tape/file to restore
    > from. The dump files don't appear to be truncated.
    >
    > Are there any limits to what ufsdump & restore can handle? I sure
    > can't find anything about this.
    > --
    > Jeff Wieland


    I recall ufsrestore always asking for a 2nd tape and just replying no or
    0 or something like that. It's been a couple years. Isn't this
    standard behavior for a full ufsrestore? It doesn't keep any volume
    info on the tape and you have to tell ufsrestore it's done.

    --
    DeeDee, don't press that button! DeeDee! NO! Dee...




  3. Re: ufsdump/restore size limit?

    In article Michael Vilain writes:
    >In article ,
    > Jeff Wieland wrote:
    >
    >> I'm having a problem restoring a fairly large file system under Solaris 8.
    >> The hardware is a Sun Fire V240, with a third-party SCSI-to-SCSI raid
    >> controller. The filesystem is just shy of 300 GB, with about 100 GB in
    >> use. We're using ufs, and ufsdump and ufsrestore, dumping to an SDLT
    >> drive that's directly attached to the V240. We are current with Solaris
    >> 8 patches.
    >>
    >> We periodically restore the dumps to an old machine that we use for
    >> testing, just to make sure that they can be restored. I can no longer
    >> restore the dumps -- ufsrestore asks for a second tape, when there isn't
    >> one. Even if we dump to a file on another server, and then try to
    >> restore from that, ufsdump still asks for a second tape/file to restore
    >> from. The dump files don't appear to be truncated.
    >>
    >> Are there any limits to what ufsdump & restore can handle? I sure
    >> can't find anything about this.
    >> --
    >> Jeff Wieland

    >
    >I recall ufsrestore always asking for a 2nd tape and just replying no or
    >0 or something like that. It's been a couple years. Isn't this
    >standard behavior for a full ufsrestore? It doesn't keep any volume
    >info on the tape and you have to tell ufsrestore it's done.
    >
    >--
    >DeeDee, don't press that button! DeeDee! NO! Dee...


    Hmmm. It doesn't ask for a second tape for other dumps, like /opt or
    root.
    --
    Jeff Wieland

  4. Re: ufsdump/restore size limit?

    In article Jeff Wieland writes:
    >In article Michael Vilain writes:
    >>In article ,
    >> Jeff Wieland wrote:
    >>
    >>> I'm having a problem restoring a fairly large file system under Solaris 8.
    >>> The hardware is a Sun Fire V240, with a third-party SCSI-to-SCSI raid
    >>> controller. The filesystem is just shy of 300 GB, with about 100 GB in
    >>> use. We're using ufs, and ufsdump and ufsrestore, dumping to an SDLT
    >>> drive that's directly attached to the V240. We are current with Solaris
    >>> 8 patches.
    >>>
    >>> We periodically restore the dumps to an old machine that we use for
    >>> testing, just to make sure that they can be restored. I can no longer
    >>> restore the dumps -- ufsrestore asks for a second tape, when there isn't
    >>> one. Even if we dump to a file on another server, and then try to
    >>> restore from that, ufsdump still asks for a second tape/file to restore
    >>> from. The dump files don't appear to be truncated.
    >>>
    >>> Are there any limits to what ufsdump & restore can handle? I sure
    >>> can't find anything about this.
    >>> --
    >>> Jeff Wieland

    >>
    >>I recall ufsrestore always asking for a 2nd tape and just replying no or
    >>0 or something like that. It's been a couple years. Isn't this
    >>standard behavior for a full ufsrestore? It doesn't keep any volume
    >>info on the tape and you have to tell ufsrestore it's done.
    >>
    >>--
    >>DeeDee, don't press that button! DeeDee! NO! Dee...

    >
    >Hmmm. It doesn't ask for a second tape for other dumps, like /opt or
    >root.
    >--
    >Jeff Wieland


    On the odd chance that there was a filesystem consistency problem, we
    rebooted the system single user and ran an fsck on it -- no problems
    were found.

    There appears to be nothing that I can type at the "Specify next volume #:"
    prompt to get ufsrestore to complete. I've tried n, no, and q to no avail.
    --
    Jeff Wieland

  5. Re: ufsdump/restore size limit?

    Jeff Wieland wrote:

    >In article Jeff Wieland writes:
    >
    >
    >>In article Michael Vilain writes:
    >>
    >>
    >>>In article ,
    >>>Jeff Wieland wrote:
    >>>
    >>>
    >>>
    >>>>I'm having a problem restoring a fairly large file system under Solaris 8.
    >>>>The hardware is a Sun Fire V240, with a third-party SCSI-to-SCSI raid
    >>>>controller. The filesystem is just shy of 300 GB, with about 100 GB in
    >>>>use. We're using ufs, and ufsdump and ufsrestore, dumping to an SDLT
    >>>>drive that's directly attached to the V240. We are current with Solaris
    >>>>8 patches.
    >>>>
    >>>>We periodically restore the dumps to an old machine that we use for
    >>>>testing, just to make sure that they can be restored. I can no longer
    >>>>restore the dumps -- ufsrestore asks for a second tape, when there isn't
    >>>>one. Even if we dump to a file on another server, and then try to
    >>>>restore from that, ufsdump still asks for a second tape/file to restore
    >>>>from. The dump files don't appear to be truncated.
    >>>>
    >>>>Are there any limits to what ufsdump & restore can handle? I sure
    >>>>can't find anything about this.
    >>>>--
    >>>>Jeff Wieland
    >>>>
    >>>>
    >>>I recall ufsrestore always asking for a 2nd tape and just replying no or
    >>>0 or something like that. It's been a couple years. Isn't this
    >>>standard behavior for a full ufsrestore? It doesn't keep any volume
    >>>info on the tape and you have to tell ufsrestore it's done.
    >>>
    >>>--
    >>>DeeDee, don't press that button! DeeDee! NO! Dee...
    >>>
    >>>

    >>Hmmm. It doesn't ask for a second tape for other dumps, like /opt or
    >>root.
    >>--
    >>Jeff Wieland
    >>
    >>

    >
    >On the odd chance that there was a filesystem consistency problem, we
    >rebooted the system single user and ran an fsck on it -- no problems
    >were found.
    >
    >There appears to be nothing that I can type at the "Specify next volume #:"
    >prompt to get ufsrestore to complete. I've tried n, no, and q to no avail.
    >--
    >Jeff Wieland
    >
    >

    Since it asked you for a "volume #" perhaps you should try entering a
    number! Try "2".
    0 and 1 also seem to be plausible choices.


  6. Re: ufsdump/restore size limit?

    In article "Richard B. Gilbert" writes:
    >Jeff Wieland wrote:
    >
    >>In article Jeff Wieland writes:
    >>
    >>
    >>>In article Michael Vilain writes:
    >>>
    >>>
    >>>>In article ,
    >>>>Jeff Wieland wrote:
    >>>>
    >>>>
    >>>>
    >>>>>I'm having a problem restoring a fairly large file system under Solaris 8.
    >>>>>The hardware is a Sun Fire V240, with a third-party SCSI-to-SCSI raid
    >>>>>controller. The filesystem is just shy of 300 GB, with about 100 GB in
    >>>>>use. We're using ufs, and ufsdump and ufsrestore, dumping to an SDLT
    >>>>>drive that's directly attached to the V240. We are current with Solaris
    >>>>>8 patches.
    >>>>>
    >>>>>We periodically restore the dumps to an old machine that we use for
    >>>>>testing, just to make sure that they can be restored. I can no longer
    >>>>>restore the dumps -- ufsrestore asks for a second tape, when there isn't
    >>>>>one. Even if we dump to a file on another server, and then try to
    >>>>>restore from that, ufsdump still asks for a second tape/file to restore
    >>>>>from. The dump files don't appear to be truncated.
    >>>>>
    >>>>>Are there any limits to what ufsdump & restore can handle? I sure
    >>>>>can't find anything about this.
    >>>>>--
    >>>>>Jeff Wieland
    >>>>>
    >>>>>
    >>>>I recall ufsrestore always asking for a 2nd tape and just replying no or
    >>>>0 or something like that. It's been a couple years. Isn't this
    >>>>standard behavior for a full ufsrestore? It doesn't keep any volume
    >>>>info on the tape and you have to tell ufsrestore it's done.
    >>>>
    >>>>--
    >>>>DeeDee, don't press that button! DeeDee! NO! Dee...
    >>>>
    >>>>
    >>>Hmmm. It doesn't ask for a second tape for other dumps, like /opt or
    >>>root.
    >>>--
    >>>Jeff Wieland
    >>>
    >>>

    >>
    >>On the odd chance that there was a filesystem consistency problem, we
    >>rebooted the system single user and ran an fsck on it -- no problems
    >>were found.
    >>
    >>There appears to be nothing that I can type at the "Specify next volume #:"
    >>prompt to get ufsrestore to complete. I've tried n, no, and q to no avail.
    >>--
    >>Jeff Wieland
    >>
    >>

    >Since it asked you for a "volume #" perhaps you should try entering a
    >number! Try "2".
    >0 and 1 also seem to be plausible choices.
    >


    I know what the problem is -- the dangers of backing up a system while
    in multiuser mode. I had been using ufsrestore with the "x" option.
    Today I tried restoring using the "r" option, which causes ufsrestore
    to not ask for a volume number, but to just start restoring. This time
    it finished and spewed out a bunch of error messages about files that
    were missing from the dump. It appears that these are files that were
    deleted during the dump, so that dump file recorded that the files
    would there, but they weren't. So, with the "x" option, ufsrestore
    assumed that they must be on another volume, but with the "r" option,
    ufsrestore knows that's all there is to the dump.

    It's unfortunate that ufsdump doesn't complain about files that it
    couldn't back up -- at least we'd have a clue then as to what was
    going on.
    --
    Jeff Wieland

  7. Re: ufsdump/restore size limit?

    In article ,
    Jeff Wieland wrote:

    >
    > I know what the problem is -- the dangers of backing up a system while
    > in multiuser mode. I had been using ufsrestore with the "x" option.
    > Today I tried restoring using the "r" option, which causes ufsrestore
    > to not ask for a volume number, but to just start restoring. This time
    > it finished and spewed out a bunch of error messages about files that
    > were missing from the dump. It appears that these are files that were
    > deleted during the dump, so that dump file recorded that the files
    > would there, but they weren't. So, with the "x" option, ufsrestore
    > assumed that they must be on another volume, but with the "r" option,
    > ufsrestore knows that's all there is to the dump.
    >
    > It's unfortunate that ufsdump doesn't complain about files that it
    > couldn't back up -- at least we'd have a clue then as to what was
    > going on.
    > --
    > Jeff Wieland


    Ahh. I've done a full restore using r from tape a couple of times but
    done "x" many times, even with "i" to pick and choose files. That's why
    I'd see this so much.

    As to not backing up everything, this is a surprise to you? You didn't
    backup in single-user, so the filesystem changed underneath you.
    Several 3rd-party backup products provide coverage for this possibility,
    but ufsdump/ufsrestore don't. I think this is pretty much understood
    that unless you backup a quiet system (e.g. Oracle shutdown and users
    logged off), you'll have thing changing during the backup.

    --
    DeeDee, don't press that button! DeeDee! NO! Dee...




  8. Re: ufsdump/restore size limit?

    In article Michael Vilain writes:
    >In article ,
    > Jeff Wieland wrote:
    >
    >>
    >> I know what the problem is -- the dangers of backing up a system while
    >> in multiuser mode. I had been using ufsrestore with the "x" option.
    >> Today I tried restoring using the "r" option, which causes ufsrestore
    >> to not ask for a volume number, but to just start restoring. This time
    >> it finished and spewed out a bunch of error messages about files that
    >> were missing from the dump. It appears that these are files that were
    >> deleted during the dump, so that dump file recorded that the files
    >> would there, but they weren't. So, with the "x" option, ufsrestore
    >> assumed that they must be on another volume, but with the "r" option,
    >> ufsrestore knows that's all there is to the dump.
    >>
    >> It's unfortunate that ufsdump doesn't complain about files that it
    >> couldn't back up -- at least we'd have a clue then as to what was
    >> going on.
    >> --
    >> Jeff Wieland

    >
    >Ahh. I've done a full restore using r from tape a couple of times but
    >done "x" many times, even with "i" to pick and choose files. That's why
    >I'd see this so much.
    >
    >As to not backing up everything, this is a surprise to you? You didn't
    >backup in single-user, so the filesystem changed underneath you.
    >Several 3rd-party backup products provide coverage for this possibility,
    >but ufsdump/ufsrestore don't. I think this is pretty much understood
    >that unless you backup a quiet system (e.g. Oracle shutdown and users
    >logged off), you'll have thing changing during the backup.
    >
    >--
    >DeeDee, don't press that button! DeeDee! NO! Dee...


    I'd expect to get some sort of error messages during the dump. Using
    the "r" option at least gave me error messages during the restore that
    pointed me in the right direction.

    Dumping in single-user mode isn't an option, unfortunately. I'm
    planning to start using snapshots during dumps to prevent this in the
    future.
    --
    Jeff Wieland

+ Reply to Thread