From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1Nrdem-0007Fi-VA for garchives@archives.gentoo.org; Tue, 16 Mar 2010 20:46:29 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 874DCE08E5; Tue, 16 Mar 2010 20:46:21 +0000 (UTC) Received: from smtp.hotchilli.net (mta3.th.hotchilli.net [62.89.140.53]) by pigeon.gentoo.org (Postfix) with ESMTP id 470DBE08E5 for ; Tue, 16 Mar 2010 20:46:21 +0000 (UTC) Received: from static-87-243-200-80.adsl.hotchilli.net ([87.243.200.80] helo=[10.0.1.253]) by smtp.hotchilli.net with esmtp (Exim 4.63) (envelope-from ) id 1Nrdee-0003nz-PK for gentoo-user@lists.gentoo.org; Tue, 16 Mar 2010 20:46:20 +0000 Message-ID: <4B9FEE1C.7050309@shic.co.uk> Date: Tue, 16 Mar 2010 20:46:20 +0000 From: Steve User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.8) Gecko/20100227 Lightning/1.0b1 Thunderbird/3.0.3 ThunderBrowse/3.2.8.1 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Re: Strategy for using SAN/NAS for storage with Gentoo... References: <4B9E343A.4040908@shic.co.uk> <87d3z53b2u.fsf@newsguy.com> <854dca5c1003150849l16b375ddl89ad2e20a8f6a135@mail.gmail.com> <4B9E5FA4.1040501@shic.co.uk> <7D7A990E-4680-472D-8408-FFABFE82EDBA@stellar.eclipse.co.uk> <4B9E87FA.3090600@shic.co.uk> <4B9EB4B6.9040106@alyf.net> <4B9FB29D.7010902@shic.co.uk> <25EC8AD5-9178-4556-AB64-6069AAB40845@stellar.eclipse.co.uk> In-Reply-To: <25EC8AD5-9178-4556-AB64-6069AAB40845@stellar.eclipse.co.uk> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Archives-Salt: 85ba43d8-4f12-4bfb-9e85-c6cdf537d9cb X-Archives-Hash: 2f35715665bdc2584575014aa10156bb On 16/03/2010 19:57, Stroller wrote: > How does your system boot if your RAID1 system volume fails? The one > you have grub on? I think you mentioned a flash drive, which I've seen > mentioned before. This seems sound, but just to point out that's > another, different, single point of failure. Well, at the moment, I don't have a RAID system... A flash drive (USB key) seems a reasonable strategy - I could even have two containing identical data - so, if the first were to fail then the second would kick in - if not automatically - then after the duff flash-drive is removed. A neat side effect of this would be to eliminate a moving part on the server - making it quieter... and the drives themselves can be located at two physically remote places on my LAN. >>> by one client at a time), the simplest solution is to completely avoid >>> having a FS on the storage server side -- just export the raw block >>> device via iSCSI, and do everything on the client. >> ... >> Snap-shots, of course, are only really valuable for non-archive data... >> so, in future, I could add a ZFS volume using the same iSCSI strategy. > If you do not need data sharing (i.e. if your volumes are only mounted Yes - I don't think I'd need sharing. It strikes me that it should be possible to have a 'live' backup server which just reads until fail-over... with a different /var/* - of course. > I have wondered if it might be possible to create a large file (`dd > if=/dev/zero of=/path/to/large/file` constrain at a size of 20gig or > 100gig or whatever) and treat it as a loopback device for stuff like > this. It's not true snapshotting (in the ZFS / BTFS sense), but you > can unmount it and make a copy quite quickly. You could, but the advantage of ZFS is the efficiency of snap-shots. With your strategy I'd need to process all of the large file every time I want to make a snapshot... which, even for a mere 100gig, won't be quick.