From owner-freebsd-questions@FreeBSD.ORG Thu Mar 4 13:51:14 2010 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 634F5106564A for ; Thu, 4 Mar 2010 13:51:14 +0000 (UTC) (envelope-from malcolm.kay@internode.on.net) Received: from ipmail06.adl2.internode.on.net (ipmail06.adl2.internode.on.net [150.101.137.129]) by mx1.freebsd.org (Postfix) with ESMTP id E00518FC12 for ; Thu, 4 Mar 2010 13:51:13 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAMFHj0t5LQMU/2dsb2JhbACbP3S3LoR8BA Received: from ppp121-45-3-20.lns20.adl2.internode.on.net (HELO alpha.home) ([121.45.3.20]) by ipmail06.adl2.internode.on.net with ESMTP; 05 Mar 2010 00:21:11 +1030 From: Malcolm Kay Organization: at home To: krad Date: Fri, 5 Mar 2010 00:21:10 +1030 User-Agent: KMail/1.8 References: <20100228132654.GA2796@orange.esperance-linux.co.uk> <201003041221.30263.malcolm.kay@internode.on.net> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201003050021.10356.malcolm.kay@internode.on.net> Cc: freebsd-questions@freebsd.org Subject: Re: / slice too small X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Mar 2010 13:51:14 -0000 On Thu, 4 Mar 2010 08:23 pm, krad wrote: > 2010/3/4 Malcolm Kay > > > On Thu, 4 Mar 2010 02:44 am, krad wrote: > > > On 3 March 2010 14:23, Malcolm Kay > > > > wrote: > > > > On Mon, 1 Mar 2010 08:44 am, krad wrote: > > > > > On 28 February 2010 15:42, Elias Chrysocheris > > > > > > > > wrote: > > > > > > > > > > You might well find it easier to use rsync rather than > > > > > dump. Just make sure you use the following flags > > > > > > > > > > rsync -aHP --numeric-ids > > > > > > > > This is a bit questionable for copying live fs. Probably > > > > OK if you use snapshots. Leaves you in very similar > > > > situation as doing backups with tar. These schemes also > > > > alter the access times on files (which I guess doesn't > > > > usually matter too much). > > > > > > > > But dump/restore is no more complex to use than rsync > > > > and manages snapshots for you, so why mess about with > > > > questionable schemes. > > > > > > I understand what you mean about live file systems, but in > > > this case its not a problem as he will be in single user > > > mode. > > > > I'm not sure that single user mode avoids this problem. > > > > > Also using the "a" flag means the modification times are > > > intact. > > > > I did not mention modification times but access times which > > I admit are seldom put to any use. It is very difficult for > > any utility to avoid altering these -- dump is the only > > exception I know of. > > > > Sorry i misread > > > > > I use rsync at work over 100s of systems and it is very > > > effective, and the noc find it far easier to recover small > > > numbers of files than having to go digging into dump > > > files. > > > > I've not found this too difficult even when working with > > compressed dumps. > > > > > The way we have got everything setup on a zfs backend mean > > > we can do incremental forever, as well which is much more > > > efficient than having to do regular level 0 dumps. > > > > Yes, rsync is great for updating incremental changes but > > this is quite irrelevant to the OP's problem. > > > > For backup it seems this also somewhat reduces the > > effectiveness. For example when you are asked to recover the > > original of a file that was changed before the lastest > > backup. Many of us think it desirable to regularly archive > > complete backups. > > This is not a problem in our scenario as the backend storage > is zfs and all underpinned with snapshots. This enables us to > retrieve and file from any day for the last x days dependent > on the retention period. Sounds good. I have no experience with zfs. But I suggest that 'x' needs to be quite large. Anyway I think we (or rather I) have done the subject to death, and it is time for me to keep quiet. Regards, Malcolm