> :Thanks Dillon for your detailed informative reply :-)
> :
> :I am actually trying to upgrade my backup server which currently runs
> :OpenBSD and backuppc from 2 120GB SATA drives on RAID1 usinf Raidframe
> :to 2 500 GB SATA drives running on RAID1.
> :
> :Do you think I can safely use HammerFS and dragonfly for this?
> :Most of my search in the net gave me results that HammerFS is not yet
> :ready for production.
> :My concern is because this is a backup server.
>
> I'm using a 750G HAMMER filesystem on the DragonFly backup box. HAMMER
> is very well suited towards this sort of operation. The only downside
> is directory scan performance isn't as high as it could be. It gets
> better as one gets deeper in the directory structure, though.
>
> In anycase, using HAMMER for the backup drive is a near perfect match
> because you can let HAMMER do the snapshotting for you. Basically
> Our backup box NFS-ro-mounts the other 6 machines and uses cpdup to
> do a nightly backup. Everything is self contained in the backup box
> itself so there is no impact on the production system if the backup box
> goes down. I don't have to use hardlink tricks or renames or anything
> else, I just cpdup nightly and then use HAMMER to create a snapshot.
>
> The offsite runs weekly and uses the latest snapshot directory on the
> LAN backup box so it has a stable copy as the offsite source.
>
> I can hold about 120 days worth of daily snapshots on the backup box
> using this method, and over a year's worth of weekly backups on the
> offsite box.
>
> Setting up the snapshotting is fairly straight-forward. Basically
> the daily cron runs 'hammer cleanup' which sets up a <fs>/snapshots/config
> file automatically, you just have to be careful that it doesn't interfere
> with whatever custom snapshotting scheme you have. If you put the
> snapshots in the <fs>/snapshots directory but you want to generate your
> own snapshot softlinks instead of having hammer cleanup do it (so they
> are synchronized with the backup), then edit the <fs>/snapshots/config
> file as follows:
>
> snapshots 0d 120d
> prune 1d 60m
> reblock 1d 60m
> recopy 30d 60m
>
> (snapshots 0d Xd -- means the cron hammer cleanup doesn't create
> any snapshots, since you are creating custom ones. The rest of
> the parameters are just beefed up defaults since the backup drive
> is very large).
>
> Basically longer pruning and reblocking times then the default, turn off
> hammer cleanup's own snapshotting (0d on the snapshots config file),
> but do tell it to delete snapshots over 120 days old (adjust as required
> once the disk starts to fill up, so it doesn't become too full).
>
> :Also the system is amd64. Can I safely install the i386 port of
> :dragonfly on it and expect it to work properly? ( dmesg of the machine
> :at the end. )
>
> Not sure what you mean there. Yes, you want to install the main
> 32 bit distribution. Our 64 bit distribution is still under development.
> 32 bit boot works fine on amd64.
>
> :And is the best thing to do now for raid dragonfly+HammerFS+Vinnum ?
>
> Not for a backup box. For a backup box I'd just use a single large
> hard drive, preferably one in a hot-swap enclosure that I can just
> pull out and take with me in an emergency. I then also have an off-site
> backup box. As long as there are two backup machines (one on-site, one
> off-site), there is no real need to set up RAID or same-box redundancy.
>
> The storage requirements are too high... it's the production machines
> that might need the RAID, since they are production machines. The
> backup box is not a time-critical component, meaning that you want it
> to be around but it doesn't create a disaster if it goes down for a
> day or two.
>
> Theoretically I guess you could use vinum and set up a RAID-1 with
> two drives, but I don't consider that any more reliable then one drive.
> A vinum'd setup can be used for the root mount with appropriate kenv
> variables set in /boot/loader.conf.
>
> What I do do is put the /backup partition on its own private drive and
> leave the rest of the backup machine's system on a smaller drive.
> That way I can umount the backup drive, pull it out, throw a new one,
> and put the old one on a shelf somewhere as an archive.
>
> :Is HammerFS available as choice during the installation in the current rele=
> :ase?
> :
> :And Finally should I go for the release or the current?
> :
> :Thanks
> :
> :Siju
>
> You want to go with current.
>
> HAMMER is an installation choice but the setup we really recommend is
> not yet available on the installer. The best setup to have (in my
> view) is a BOOT+HAMMER setup. A small UFS BOOT partition 'a', say
> 256M, swap on 'b', and the rest of the disk would be a HAMMER FS on
> 'd' ('d' becomes the root fs). You mount the boot filesystem on 'a'
> under the root fs as /boot. Setting it up is fairly straight-forward,
> the only gotcha is how to tell the kernel where the root filesystem is
> since it isn't on 'a'. You do that by adding a line to /boot/loader.conf
> that looks something like:
>
> vfs.root.mountfrom="hammer:da0s1d"
>
> For a multi-disk setup making /boot redundant is a bit more difficult.
> What I recommend is simply creating a non-RAID /boot on every drive so
> the BIOS can boot from any one of them. If it is really important
> then put the base system on a SSD and boot from there. SSD's have the
> same MTBF as the motherboard so there isn't any need, or point, in
> RAIDing them. SSDs are actually quite reasonably priced for the low
> capacities needed for a base system partition.
>
> I don't like the fake-raid BIOS solutions. I really don't like them.
> They are not necessarily compatible between motherboards so just being
> able to pull the drives doesn't mean you can easily recover the data
> on another machine. When it comes down to it, a solid state drive (SSD)
> is the best way to boot a machine that absolutely needs to boot reliably.
>
> Once you get past the basic system boot you have a lot more options, and
> intelligence, with regards to mounting the other drives.
>
> -Matt
Great to see Dillon replying with such detailed information. HammerFS is also
being
ported to Linux via FUSE.
_______________________________________________
bsd-india mailing list
[email protected]
http://www.bsd-india.org/mailman/listinfo/bsd-india
