ugh. dump / restore problem(s) "Cannot find file dump list"

[Gary Aitken]

I needed to expand a /var partition,
which required saving and restoring /var and /usr

did the following:
booted to backup disk
dump -0aR -h 0 -f /usr/backup/dump_var_0_20121113_1920 /dev/ada0p4
(repeat for /tmp, /usr, / partitions to be safe)
repartitioned the main disk using gpart
newfs the modified partitions (var, tmp, usr)
rewrote the boot block and boot partition (#1)
mount /dev/ada0p4 /mnt/ssd/var
cd /mnt/ssd/var
restore -r /usr/backup/dump_var_0_20121113_1920
Cannot find file dump list

Any ideas why I get the "Cannot find file dump list"?
What / where is it supposed to be?

I was able to get some stuff back from one of the files,
but only by doing:

#restore -if /usr/backup/dump_usr_0_201121113_1920
restore > verbose
restore > add libdata
restore > extract
Extract requested files
You have not read any tapes yet
If you are extracting just a few files, start with the last volume
and work towards the first; restore can quickly skip tapes that
have no further files to extract. Otherwise, begin with volume 1.
Specify next volume #: 1
Mount tape volume 1
Enter "none" if there are no more tapes
otherwise enter tape name (default: /usr/backup/dump_usr_0_20121113_1920)
unknown tape header type -2
abort [yn] n
resync restore, skipped 786 blocks
extract file ...
...
Add links
Set directory mode, owner, and times.
Set owner / mode for '.' [yn] y
restore >

If I did not enter <Enter> after the "otherwise enter tape name",
but rather entered "none"
I did not get all of the desired contents.

Can anyone shed light on this problem?
I have been able to restore most everything from a cp I had done
at the same time, but I'm not very confident in the results.
Fortunately, user data was on a different disk.

Obviously, should have done a
restore -rN ...
before repartitioning. Ugh.

Related question:
I now realize I should not have answered "y" to the set owner / mode
question, as it changed the mode to the default for root instead of
doing what I thought which was restoring the owner / mode to what was
saved in the dump. Will
restore -x /usr/backup/dump...
correct the owner and mode? (and group and flags?)

Thanks,

Gary
_______________________________________________
freebsd-...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questi...@freebsd.org"

[Matthias Apitz]

El día Wednesday, November 14, 2012 a las 01:20:14AM -0700, Gary Aitken escribió:

> I needed to expand a /var partition,
> which required saving and restoring /var and /usr
>
> did the following:
> booted to backup disk
> dump -0aR -h 0 -f /usr/backup/dump_var_0_20121113_1920 /dev/ada0p4
> (repeat for /tmp, /usr, / partitions to be safe)
> repartitioned the main disk using gpart
> newfs the modified partitions (var, tmp, usr)
> rewrote the boot block and boot partition (#1)
> mount /dev/ada0p4 /mnt/ssd/var
> cd /mnt/ssd/var
> restore -r /usr/backup/dump_var_0_20121113_1920
> Cannot find file dump list
>
> Any ideas why I get the "Cannot find file dump list"?
> What / where is it supposed to be?

You need to specify the file containing the DUMP with -f flag; and use
the flag -r only to restore to the original location, or -x to restore
into the current dir; check the man page for details;

matthias
--
Sent from my FreeBSD netbook

Matthias Apitz | - No system with backdoors like Apple/Android
E-mail: gu...@unixarea.de | - No HTML/RTF in E-mail
WWW: http://www.unixarea.de/ | - No proprietary attachments
phone: +49-170-4527211 | - Respect for open standards

[Polytropon]

On Wed, 14 Nov 2012 01:20:14 -0700, Gary Aitken wrote:
> mount /dev/ada0p4 /mnt/ssd/var
> cd /mnt/ssd/var
> restore -r /usr/backup/dump_var_0_20121113_1920
> Cannot find file dump list

The last command looks wrong. The restore program requires
the dump file to be provided via -f, so

# restore -rf /usr/backup/dump_var_0_20121113_1920

should work. You can find an example in "man restore".



--
Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...

[Jack Mc Lauren]

________________________________
From: Polytropon <fre...@edvax.de>
To: fre...@dreamchaser.org
Cc: FreeBSD Mailing List <freebsd-...@freebsd.org>
Sent: Wednesday, November 14, 2012 12:27 PM
Subject: Re: ugh. dump / restore problem(s) "Cannot find file dump list"

On Wed, 14 Nov 2012 01:20:14 -0700, Gary Aitken wrote:
>  mount /dev/ada0p4 /mnt/ssd/var
>  cd /mnt/ssd/var
>  restore -r /usr/backup/dump_var_0_20121113_1920
>  Cannot find file dump list

>>The last command looks wrong. The restore program requires
>>the dump file to be provided via -f, so
>>
>>    # restore -rf /usr/backup/dump_var_0_20121113_1920
>>
>>should work. You can find an example in "man restore".

Hi
There is no - . This is the correct format : restore rf /path/to/dump/files

good luck :)

[Matthias Apitz]

El día Wednesday, November 14, 2012 a las 01:01:08AM -0800, Jack Mc Lauren escribió:

> Hi
> There is no - . This is the correct format : restore rf /path/to/dump/files

from man restore(8):

RESTORE(8) FreeBSD System Manager's Manual
RESTORE(8)

NAME
restore, rrestore — restore files or file systems from backups made
with
dump

SYNOPSIS
restore -i [-dDhmNuvy] [-b blocksize] [-f file | -P pipecommand]
[-s fileno]
restore -R [-dDNuvy] [-b blocksize] [-f file | -P pipecommand]
[-s fileno]
restore -r [-dDNuvy] [-b blocksize] [-f file | -P pipecommand]
[-s fileno]
restore -t [-dDhNuvy] [-b blocksize] [-f file | -P pipecommand]
[-s fileno] [file ...]
restore -x [-dDhmNuvy] [-b blocksize] [-f file | -P pipecommand]
[-s fileno] [file ...]

...

matthias

--
Sent from my FreeBSD netbook

Matthias Apitz | - No system with backdoors like Apple/Android
E-mail: gu...@unixarea.de | - No HTML/RTF in E-mail
WWW: http://www.unixarea.de/ | - No proprietary attachments
phone: +49-170-4527211 | - Respect for open standards

[Polytropon]

On Wed, 14 Nov 2012 01:01:08 -0800 (PST), Jack Mc Lauren wrote:
> There is no - . This is the correct format : restore rf /path/to/dump/files

Really? The manual at "man restore" mentions:

restore -r [-dDNuvy] [-b blocksize] [-f file | -P pipecommand]
[-s fileno]

And in the -r section:

newfs /dev/da0s1a
mount /dev/da0s1a /mnt
cd /mnt

restore rf /dev/sa0

So it seems that _both_ formats are supported (comparable to
tar).

One of the (in my opinion) most interesting reference sources
for dump/restore also mentions this format:

# mount /dev/da0s1 /mnt
# mkdir /tmp/oldvar
# cd /tmp/oldvar
# restore -ruf /mnt/var.dump
# umount /mnt

Source:

http://www.wonkity.com/~wblock/docs/html/backup.html#_em_dump_8_em_em_restore_8_em

--
Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...

[Gary Aitken]

On 11/14/12 01:30, Matthias Apitz wrote:
> El día Wednesday, November 14, 2012 a las 01:20:14AM -0700, Gary Aitken escribió:
>
>> I needed to expand a /var partition,
>> which required saving and restoring /var and /usr
>>
>> did the following:
>> booted to backup disk
>> dump -0aR -h 0 -f /usr/backup/dump_var_0_20121113_1920 /dev/ada0p4
>> (repeat for /tmp, /usr, / partitions to be safe)
>> repartitioned the main disk using gpart
>> newfs the modified partitions (var, tmp, usr)
>> rewrote the boot block and boot partition (#1)

>> mount /dev/ada0p4 /mnt/ssd/var
>> cd /mnt/ssd/var
>> restore -r /usr/backup/dump_var_0_20121113_1920
>> Cannot find file dump list
>>

>> Any ideas why I get the "Cannot find file dump list"?
>> What / where is it supposed to be?
>
> You need to specify the file containing the DUMP with -f flag; and use
> the flag -r only to restore to the original location, or -x to restore
> into the current dir; check the man page for details;

Sorry all, a typing issue on my part when composing the email; problem remains:

# restore -iN -f /mnt/hd_ssd_backup/usr/backup/dump_tmp_0_20121113_1920

Cannot find file dump list

[Warren Block]

On Wed, 14 Nov 2012, Polytropon wrote:

> On Wed, 14 Nov 2012 01:01:08 -0800 (PST), Jack Mc Lauren wrote:
>> There is no - . This is the correct format : restore rf /path/to/dump/files
>
> Really? The manual at "man restore" mentions:
>
> restore -r [-dDNuvy] [-b blocksize] [-f file | -P pipecommand]
> [-s fileno]
>
> And in the -r section:
>
> newfs /dev/da0s1a
> mount /dev/da0s1a /mnt
> cd /mnt
>
> restore rf /dev/sa0
>
> So it seems that _both_ formats are supported (comparable to
> tar).
>
> One of the (in my opinion) most interesting reference sources
> for dump/restore also mentions this format:
>
> # mount /dev/da0s1 /mnt
> # mkdir /tmp/oldvar
> # cd /tmp/oldvar
> # restore -ruf /mnt/var.dump

Yes, -u "unlinks" an existing file before restoring that file, useful
for restoring dumps over an existing filesystem. Leave out the -u when
restoring to a new filesystem and the restore will go faster.

> # umount /mnt

And that points out a mistake: /mnt can't be unmounted while it is the
PWD. Fixed.

> Source:
>
> http://www.wonkity.com/~wblock/docs/html/backup.html#_em_dump_8_em_em_restore_8_em

Thanks!

[Matthias Apitz]

El día Wednesday, November 14, 2012 a las 09:45:22AM -0700, Warren Block escribió:

> > One of the (in my opinion) most interesting reference sources
> > for dump/restore also mentions this format:
> >
> > # mount /dev/da0s1 /mnt
> > # mkdir /tmp/oldvar
> > # cd /tmp/oldvar
> > # restore -ruf /mnt/var.dump
>
> Yes, -u "unlinks" an existing file before restoring that file, useful
> for restoring dumps over an existing filesystem. Leave out the -u when
> restoring to a new filesystem and the restore will go faster.
>
> > # umount /mnt
>
> And that points out a mistake: /mnt can't be unmounted while it is the
> PWD. Fixed.

I think PWD is /tmp/oldvar and not /mnt;

matthias
--
Sent from my FreeBSD netbook

Matthias Apitz | - No system with backdoors like Apple/Android
E-mail: gu...@unixarea.de | - No HTML/RTF in E-mail
WWW: http://www.unixarea.de/ | - No proprietary attachments
phone: +49-170-4527211 | - Respect for open standards

[Warren Block]

On Wed, 14 Nov 2012, Matthias Apitz wrote:

> El día Wednesday, November 14, 2012 a las 09:45:22AM -0700, Warren Block escribió:
>
>>> One of the (in my opinion) most interesting reference sources
>>> for dump/restore also mentions this format:
>>>
>>> # mount /dev/da0s1 /mnt
>>> # mkdir /tmp/oldvar
>>> # cd /tmp/oldvar
>>> # restore -ruf /mnt/var.dump
>>
>> Yes, -u "unlinks" an existing file before restoring that file, useful
>> for restoring dumps over an existing filesystem. Leave out the -u when
>> restoring to a new filesystem and the restore will go faster.
>>
>>> # umount /mnt
>>
>> And that points out a mistake: /mnt can't be unmounted while it is the
>> PWD. Fixed.
>
> I think PWD is /tmp/oldvar and not /mnt;

Yes, you're correct. Re-fixed. Thanks!

[Gary Aitken]

> did the following:
> booted to backup disk
> dump -0aR -h 0 -f /usr/backup/dump_var_0_20121113_1920 /dev/ada0p4
> (repeat for /tmp, /usr, / partitions to be safe)
> repartitioned the main disk using gpart
> newfs the modified partitions (var, tmp, usr)
> rewrote the boot block and boot partition (#1)
> mount /dev/ada0p4 /mnt/ssd/var
> cd /mnt/ssd/var
> restore -r /usr/backup/dump_var_0_20121113_1920
> Cannot find file dump list

ok, after digging around in my notes and memory I have a better understanding
of what actually happened:

I went through several reboot sequences, between the backup disk and
the main disk.

After generating the /var dump file on the backup disk while booted from the
backup disk, I did a shutdown -r to reboot the main disk; can't remember why.
What I do remember is that the dump itself, running as root from ttyv5,
appeared to terminate normally, with no error message; I got the # prompt.
However, as the shutdown was happening, I saw the message:
Dump failed, partition too small
on ttyv1 -- despite the fact that the command completed without any message
on the controlling terminal, ttyv5.

The destination file-system was nowhere near full, and the source was read-only,
so I stupidly assumed the output was ok and the message was the result of
some other niggly thing.

Obviously dump ran out of space (the file is exactly a multiple
of the block size and apparently truncated), and the dump directory can't be
found. But where it ran out of space is unclear to me, as the destination
file system was nowhere near full before or after the event, and contains
two much larger intact dump sets (for / and /usr) and one of those was
written after the truncated ones.

The question I have is:
Why didn't the dump failure message show up on the controlling terminal?

It's not clear which partition ran out of space. Does dump use /tmp or /var?
/tmp and /var on the running backup os are relative small (512MB), and the
filesystem being dumped was the same size and ~70% full. If dump uses /tmp
and tmp runs out of space and the tty output of dump is depending on a socket
in /tmp, that might cause a problem. But once the process terminates, if it
cleans up after itself there's no trace of the overflow.

crazy? it was kinda late at night...