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?)
> 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: g...@unixarea.de | - No HTML/RTF in E-mail
WWW: http://www.unixarea.de/ | - No proprietary attachments
phone: +49-170-4527211 | - Respect for open standards
_______________________________________________
freebsd-questi...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
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
should work. You can find an example in "man restore".
-- Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...
_______________________________________________
freebsd-questi...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
________________________________
From: Polytropon <free...@edvax.de>
To: free...@dreamchaser.org Cc: FreeBSD Mailing List <freebsd-questi...@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
Matthias Apitz | - No system with backdoors like Apple/Android E-mail: g...@unixarea.de | - No HTML/RTF in E-mail WWW: http://www.unixarea.de/ | - No proprietary attachments phone: +49-170-4527211 | - Respect for open standards _______________________________________________ freebsd-questi...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
-- Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...
_______________________________________________
freebsd-questi...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
> 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
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
> 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.
> 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: g...@unixarea.de | - No HTML/RTF in E-mail
WWW: http://www.unixarea.de/ | - No proprietary attachments
phone: +49-170-4527211 | - Respect for open standards
_______________________________________________
freebsd-questi...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
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.
> 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...
_______________________________________________
freebsd-questi...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
