Date: Tue, 12 Aug 2014 16:48:17 -0300 (ADT) From: Andrew Hamilton-Wright <AHamiltonWright@MtA.ca> To: Roland Smith <rsmith@xs4all.nl> Cc: freebsd-questions@freebsd.org Subject: Re: Problems with dump and restore Message-ID: <alpine.BSF.2.11.1408121641480.1074@qemg.org> In-Reply-To: <20140812193419.GB7166@slackbox.erewhon.home> References: <alpine.BSF.2.11.1408121255230.1074@qemg.org> <20140812193419.GB7166@slackbox.erewhon.home>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Roland -- thanks for the suggestions.
On Tue, 12 Aug 2014, Roland Smith wrote:
> On Tue, Aug 12, 2014 at 01:07:06PM -0300, Andrew Hamilton-Wright wrote:
>
[ ... condensed ... ]
>> These were created using snapshots, so the level 0 was created via
>> dump 0uLCf 32 - /usr
>> and higher level dumps were created similarly.
>
> In 2011, a problem was found with snapshots in combination with soft
> updates *and* journaling (SU+J) hanging the machine. At that time the
> recommendation was to switch off journaling.
> According to https://wiki.freebsd.org/NewFAQs:
>
> If you want to use snapshot (dump -L) then disable the soft updates
> journal for that filesystem.
>
> This bug was fixed toward the end of 2011;
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=160662
>
> Personally I make dumps *only* from filesystems that are unmounted or mounted
> read-only, so never from a “live” filesystem, just to be on the safe side.
I had forgotten about the soft update issue. I am not sure that that
is related, as the machine is running 10.0 and the level 0 dump was
created in July, but it is definitely worth lowering the complexity
of the problem. I will ensure that soft updates are off before
dumping in the future.
> This is mentioned in the restore's manpage;
>
> expected next file <inumber>, got <inumber>
> A file that was not listed in the directory showed up. This can
> occur when using a dump created on an active file system.
True, but my understanding of snapshots is that it is supposed to
eliminate exactly this problem, no?
>> Some questions then:
>> - is anyone else using dump/restore as their main backup method?
>
> Yes, operating system filesystems like /, /usr and /var, which can contain
> flags and hard links and such. These filesystem's aren't all that big, so
> dumps are relatively quick.
What options are you using? Are you using dumplevels?
>> Are you using snapshots?
>
> No, because of the aforementioned bug that surfaced in 2011.
>
>> If so, have you seen anything like this when running restore?
>
> I've had hangs and corrupted dumps when dumping live filesystems.
Good to know.
>> - is there any means of validating the dump file, other than the -N
>> option (which returns no warnings on any of these files)?
>
> Not that I know of. I generally make and verify checksums when copying dumps
> to other machines or external harddrives.
Yes -- I suppose I have gotten lazy in that regard.
>> - does anyone have any advice that may help determine what may have
>> gone wrong?
>
> Try using restore's “degraded” mode (using the ‘-D’ option) and use the ‘-y’
> option.
I have started that running on a scratch device, and will report back with
results.
Andrew.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.11.1408121641480.1074>