|
Re: Are there any amanda users running FreeBSD here?
2008-01-02 17:48:55
John E Hein wrote:
Gene Heskett wrote at 14:50 -0500 on Jan 1, 2008:
> I just got bit by the volatile device major number getting moved
> again, and one of the kernel developers is asking me how FreeBSD
> users cope with this since FreeBSD's device majors are all dynamic.
Well, it's not really the major device, but the minor:
crw-r----- 1 root operator 0, 90 Dec 22 06:34 /dev/da0s1
crw-r----- 1 root operator 0, 92 Dec 22 06:34 /dev/da0s1a
crw-r----- 1 root operator 0, 93 Dec 22 06:34 /dev/da0s1b
crw-r----- 1 root operator 0, 94 Dec 22 06:34 /dev/da0s1c
crw-r----- 1 root operator 0, 95 Dec 22 06:34 /dev/da0s1e
crw-r----- 1 root operator 0, 96 Dec 22 06:34 /dev/da0s1f
crw-r----- 1 root operator 0, 97 Dec 22 06:34 /dev/da0s1g
crw-r----- 1 root operator 0, 98 Dec 22 06:34 /dev/da0s1h
But gtar uses a combination of major/minor, so this issue does, as you
say, affect FreeBSD (post 4.x).
> So if there are any FreeBSD users running amanda here, please
> respond and describe how you folks handle changing hardware that
> putz's with your devices major numbers.
Generally unless you're changing hardware around, the numbers don't
change. But if you do, you'll have the same issue that you do with
other OS's that have dynamic dev #s - it's not FreeBSD-specific, as
such.
You will either dump lots of spurious "changed" files next time you do
a time. Or you have to fix the gnutar incremental files. There was a
thread on -hackers recently about this. I suggested an option,
--ignore-devno-change, that could be added to gnu tar to help with
this. But as far as I know, no one has actually tried to implement.
Dustin has written a "fixit" script for the snapshot files that is
included in recent gtar distributions.
happens on Solaris as well.
When we've rearranged drives (e.g., finally decommissioning the narrow
scsi box and moving all the data onto Ultra320 drives in another box
attached to the same server last year), followed by a reconfigure boot,
things get all shuffled around (sometimes including stuff we didn't
change). We expect that, bring it up in single user, check to see how
things got configured, edit /etc/vfstab to fix references, and finally
reboot into multi user. On one server, we have 4 external drive cabinets
and a total of 28 drives.
ufsdump uses /etc/dumpdates. looking at that on my backup server (which
only has 4 drives), I see:
mormyrid:/usr/local/etc/amanda:amanda$ more /etc/dumpdates
/dev/rdsk/c0t0d0s3 0 Sat Dec 29 02:54:23 2007
/dev/rdsk/c0t8d0s4 0 Sat Dec 29 03:16:47 2007
/dev/rdsk/c6t5d0s2 0 Tue Jun 27 11:59:05 2006
/dev/rdsk/c6t5d0s7 0 Tue Jul 11 12:32:04 2006
/dev/rdsk/c0t0d0s3 1 Wed Jan 2 00:59:46 2008
/dev/rdsk/c0t8d0s4 1 Wed Jan 2 02:19:34 2008
/dev/rdsk/c0t8d0s4 2 Wed May 23 02:03:23 2007
/dev/rdsk/c0t0d0s5 0 Wed Jun 27 15:28:24 2007
/dev/rdsk/c0t0d0s5 1 Wed Jun 27 16:09:50 2007
(c6 doesn't exist anymore, and I never back up the 2 holding disks.)
Shuffling drives and doing a reconfigure reboot should be a fairly rare
event, and I've always just taken for granted that there is going to be
a little extra work involved. Interesting thing is that while my system
wouldn't function if I didn't clean up /etc/vfstab, I don't recall
whether I did anything about /etc/dumpdates. I may have hand edited it,
or I may have forgotten it. In any case, Amanda would catch up and have
things cleared up within a week. So, if I missed it, I may have gotten
some extra stuff backed up, or I may have missed some stuff on
incrementals because the date was wrong in /etc/dumpdates.
If I were a real business instead of an academic department, I'd
probably be ISO 9001 certified. I'd have documented, audited procedures
for all that and wouldn't miss it. ;-)
hmm. I wonder if any of the backup software companies provide boiler
plate documentation and assistance for ISO 9001 certification? That
might be an interesting goal for Zmanda if their commercial clients
showed any interest. I was with a company in the early 1990's
(Software/CAD/VAR) that got certified. They did it because they were
dealing with a lot of Fortune 100 companies, and some of them required
it or gave an edge to vendors who had it. Personally, I always thought
it was just a paperwork pain in the butt serving mainly for PR and
auditing, but I digress majorly. ;-)
---------------
Chris Hoogendyk
-
O__ ---- Systems Administrator
c/ /'_ --- Biology & Geology Departments
(*) \(*) -- 140 Morrill Science Center
~~~~~~~~~~ - University of Massachusetts, Amherst
<hoogendyk AT bio.umass DOT edu>
---------------
Erdös 4
|
|
|
