On Tue, Jun 23, 2009 at 6:50 PM, Ashish SHUKLA<[email protected]> wrote:
>
> http://www.google.com/search?q=FreeBSD+gjournal+gmirror
> http://www.freebsd.org/doc/en/articles/gjournal-desktop/article.html
> http://www.freebsd.org/doc/en/books/handbook/geom-mirror.html
> http://www.freebsd.org/doc/en/books/handbook/geom-gjournal.html
>
Thanks a lot for these resources Ashish. They are really helpful.
Meanwhile Mathew Dillon ( dfly project leader and hammerfs author )
responded to my enquiries.
His reply is given below. I think I will go for dfly + hammerfs.
--Siju
===================================================
: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
======================================================
_______________________________________________
bsd-india mailing list
[email protected]
http://www.bsd-india.org/mailman/listinfo/bsd-india
