Date: Thu, 26 Mar 2009 06:53:37 -0500 From: "Jack L. Stone" <jacks@sage-american.com> To: Peggy Wilkins <mozart@lib.uchicago.edu> Cc: freebsd-stable@freebsd.org, fs@freebsd.org Subject: Re: support quality (Re: dump | restore fails: unknown tape headertype 1853384566) Message-ID: <3.0.1.32.20090326065337.00f081e0@sage-american.com> In-Reply-To: <pvfxh1ek4j.wl%mozart@lib.uchicago.edu> References: <3.0.1.32.20090325072137.00ee6b48@sage-american.com> <49C9E635.5010106@kkip.pl> <49C83673.3000604@aldan.algebra.com> <200903251820.54749.doconnor@gsoft.com.au> <200903251925.36108.doconnor@gsoft.com.au> <3.0.1.32.20090325072137.00ee6b48@sage-american.com>
next in thread | previous in thread | raw e-mail | index | archive | help
At 09:45 AM 3.25.2009 -0500, Peggy Wilkins wrote: >>>>>> Jack L Stone <jacks@sage-american.com> writes: > > >> I've been watching this thread with some interest since we've had some > >> similar problems with dump/restore which we use every morning via cron > >> scripts on a number of servers to produce bootable clones as part of our > >> backup program. Have been doing this for years and also never saw a problem > >> as most of you say. We prefer dump/restore for backups. > > >> However, last month upon upon upgrading those servers from FBSD-6.3px > >> (RELEASE) to 7.0px (RELEASE) we found that about one-half of the servers > >> had a similar problem as the original poster while the other half did not. > >> All of the servers (rackmounts) use the same (type) hardware. We spent many > >> hours trying to solve the problem with those that failed to dump/restore. > >> Also, searched for any others with the problem and only found a very few, > >> but without solutions to this issue. (Indeed, the only one was a reference > >> to any efforts to restore an older OS version which didn't apply here). > [snip] > >> SOLUTION > >> The "clones" are a very important pasrt of our backup program. Since the > >> dump side of the problems simply stuck and provided no error message at all > >> and the errors from any restores were not useful, our only solution was to > >> revert back to FBSD-6.3 on those servers with this issue and dump/restore > >> went back to working again. We left those that were working on FBSD-7.0-R > >> and they continue to work okay. > >I was seeing this same problem on all my 64-bit systems: FreeBSD-7 >dump would hang at a random point. Dump continues to work flawlessly >for me on FreeBSD-7/i386. > >I ran across this which includes a patch: > >http://www.freebsd.org/cgi/query-pr.cgi?pr=121684 > >The kernel patch linked to there solved the problem for me, but I am >running many production systems and am unwilling to apply this patch >to -RELEASE every time there is a kernel update (I just use the >standard GENERIC kernel which I get via freebsd-update). I now live >without dump on amd64. Apparently this fix is waiting on some related >issue; and I will be very happy when it makes it to the officially >released kernel. > >plw > Thanks for the reply. Forgot to mention, our machines are all i386 with the problem -- so are the ones without the problem. Yes, I found that patch too and tried it on one of the servers -- no joy. Guess we'll continue to wait also for now. Maybe 7.2/i386....or, until someone finds the solution since we're out of ideas and stuck with 6.3 in order to use dump that we have trusted. Jack (^_^) Happy trails, Jack L. Stone System Admin Sage-american
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3.0.1.32.20090326065337.00f081e0>