Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 5 Feb 2010 10:50:29 +0000
From:      krad <kraduk@googlemail.com>
To:        "Svein Skogen (Listmail Account)" <svein-listmail@stillbilde.net>
Cc:        freebsd-questions@freebsd.org
Subject:   Re: Backup and FreeBSD/ZFS
Message-ID:  <d36406631002050250v670ef0a4yd8a2ad221fdcad68@mail.gmail.com>
In-Reply-To: <4B6B0E7A.3080207@stillbilde.net>
References:  <4B694A52.4080306@stillbilde.net> <4B69BD02.5060305@gmail.com> <4B69CCC8.2060105@stillbilde.net> <d36406631002040139o1fe12ea4h1f5b9ed1080bd94a@mail.gmail.com> <4B6AE93C.5090803@stillbilde.net> <4B6AFC7A.9040200@infracaninophile.co.uk> <4B6B0E7A.3080207@stillbilde.net>

next in thread | previous in thread | raw e-mail | index | archive | help
On 4 February 2010 18:14, Svein Skogen (Listmail Account) <
svein-listmail@stillbilde.net> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 04.02.2010 17:57, Matthew Seaman wrote:
> > On 04/02/2010 15:35, Svein Skogen (Listmail Account) wrote:
> >
> >> On a monthly rotation the tapes are placed in a firetolerant safe. Sin=
ce
> >> the most critical thing here is the terabyte (and growing!) of origina=
l
> >> photographs, I'm not thinking about just day-to-day diskfailure or
> >> pebcaks (proper raid and snapshotting handles that rather well). Howev=
er
> >> snapshotting and raid solutions handles the house being on fire rather
> >> poorly, or should we say "Data integrity and fires, get along like a
> >> house on fire"? ;)
> >
> > fire tolerant?  That doesn't sound amazingly effective to me.  Would it
> > stand up to temperatures in excess of 600degC for more than about 20
> > minutes?  That's going to be fairly typical in a house fire...
>
> Well, this one is the kind placed within the concrete of our cellar
> (this is a home solution, not an industry one). But that area isn't
> suitable for the servers for other reasons. The cellar is within the
> bedrock of the area (the house foundation is directly on bedrock, and
> the cellar area has been blasted out from the bedrock), so discounting
> the plane-crash-into-building scenario, it's rather safe for our use
> (and the plane-crash scenario would quite likely invalidate me along
> with the backup, and so the need for a restore wouldn't be that critical)
>
> > A safe like that is a good idea for local storage of backup media while
> > it waits to go into the tape library or off-site.  It's a bad idea for
> > storing your entire archive.
> >
>
> *snip*
>
> >
> > Tape libraries are horribly expensive since they're not mass market
> > items.  They are also intrinsically prone to breaking down or failing
> > to work quite as well as the salesman implied.  They're the only viable
> > solution when your storage volumes get really huge, but what is
> > considered huge nowadays is rather more than terabyte scale.  If you ca=
n
> > get away with just a single tape drive you'll save yourself a lot of
> > money.
>
> Alas, a full backup of the current disk setup takes 4 tapes and ... I
> really don't feel like staying up one entire night per week to swap
> tapes (both for the backup and the verify). The autoloader I've got now
> (8 slot, 1 drive, LTO-3, SAS) works fairly well with the currently
> installed OS (Windows Storage Server 2008), giving about 60MB/Sec
> sustained transfer rate.
>
> > LTO4 tapes are rated at 800--1600GB depending on achievable compression=
,
> > so they might be big enough on their own.  As image formats are already
> > internally compressed, I'd expect them to come in at the low end of
> > that, which might be tight.  Worth trying out if you can get a drive on
> > evaluation.
>
> A standalone LTO-4 might be a good alternative, if I didn't already have
> the tapeloader. ;)
>
> > You might want to evaluate getting a bunch of 1TB (or larger) hard dive=
s
> > -- either USB or hot-swap SATA.  They don't need to perform particularl=
y
> > well, but they'd have to be rated for a lot of spin-up/spin-down cycles
> > (so something aimed at the mobile PC market).
> >
> > One other thing you should seriously consider is on-line backup.  There
> > are quite a lot of providers out there, and they should be at least
> > competitive with running your own dedicated backup system.  They also
> > generally have the advantage of being instantly available if you need t=
o
> > recover anything in a hurry.
>
> Online-backup-solutions are a no-go for me, alas.
>
> >> Someone told me that Amanda should handle this, and I'm looking into i=
t
> >> now (especially reading up on what I'd need to do to handle disaster
> >> recovery), but other options are welcome as well, including the option
> >> of going Solaris (if someone can point me to proper documentation on h=
ow
> >> to get Solaris to do what I want).
> >
> > Also checkout Bacula.  I've found Bacula quite a lot easier to manage
> > than Amanda, especially with tape libraries.
> >
> >> The box itself is a C2D E7500 with 8GB ram, Asus P5Q Premium (the
> >> "deluxe" version with fewer NICs is on the BigAdmin HCL, basically an
> >> intel P45 chipset with sufficient number of pci-express slots, and fou=
r
> >> Marvell Yukon gigabit nics with Marvell Alaska PHY), backed by LSI
> >> SAS-MPT for the autoloader and SAS-MFI for the disks, and will handle
> >> SMB/CIFS, NFS, and iSCSI services (and the backups of that data).
> >> Nothing fancy here, meaning it should hardwarewise be no biggie to get
> >> it up and running in FreeBSD, Solaris (or leave it on Windows Storage
> >> server if that's the best solution, even if that means the
> >> iSCSI-target-service has ... less than stellar performance).
> >
> >> So, I'm basically looking for pointers on what solutions to consider,
> >> not looking for a pre-cooked solution. I have sufficient external
> >> diskspace (still with redundancy) to handle the move-to-new-os-and-fs
> >> issue...
> >
> >> Thanks again for taking the time to help me out here. ;)
> >
> > Hard to know what to advise OS-wise.  FreeBSD will do the job, although
> > I'm not sure the iSCSI-target stuff is the best available.  So will
> > Solaris for that matter, although more likely to suffer from hardware
> > incompatibilites.  I really haven't got a clue about how well Windows
> > would perform although I personally would avoid it simply because it wa=
s
> > Windows...
>
> Windows was chosen as ... the least painful alternative at the time, and
> luckily I'm pragmatic about computing OS'es. They're all broken and
> prone to crashes. :p
>
> //Svein
>
> - --
> - --------+-------------------+-------------------------------
>  /"\   |Svein Skogen       | svein@d80.iso100.no
>  \ /   |Solberg =D8stli 9    | PGP Key:  0xE5E76831
>   X    |2020 Skedsmokorset | svein@jernhuset.no
>  / \   |Norway             | PGP Key:  0xCE96CE13
>        |                   | svein@stillbilde.net
>  ascii  |                   | PGP Key:  0x58CD33B6
>  ribbon |System Admin       | svein-listmail@stillbilde.net
> Campaign|stillbilde.net     | PGP Key:  0x22D494A4
>        +-------------------+-------------------------------
>        |msn messenger:     | Mobile Phone: +47 907 03 575
>        |svein@jernhuset.no | RIPE handle:    SS16503-RIPE
> - --------+-------------------+-------------------------------
>         If you really are in a hurry, mail me at
>               svein-mobile@stillbilde.net
>  This mailbox goes directly to my cellphone and is checked
>        even when I'm not in front of my computer.
> - ------------------------------------------------------------
>                     Picture Gallery:
>          https://gallery.stillbilde.net/v/svein/
> - ------------------------------------------------------------
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.12 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAktrDnkACgkQODUnwSLUlKR8swCgs20KjWiGKoNJK/llELC3PcNL
> CyoAoLkDFCvYU8NyI80gF5RVxuo5FWcH
> =3DX40n
> -----END PGP SIGNATURE-----
> _______________________________________________
> freebsd-questions@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to "
> freebsd-questions-unsubscribe@freebsd.org"
>


If you do decide to go with zfs as the file system and need stability, I
would go for solaris 10 as thats where is the most mature and stable zfs
platform. As mentioned in a previous post you might get compatibility
issues. A good alternative would then be opensolaris. I would stick to
2009.06 at the moment though for it as its been out a while and proved to b=
e
reliable. Having said all that I run zfs on freebsd, but its far more
immature and not officially supported by the zfs team, so it more of a risk
than the other platforms.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?d36406631002050250v670ef0a4yd8a2ad221fdcad68>