From owner-freebsd-fs@FreeBSD.ORG Fri May 20 13:09:38 2011 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 26C1C106566C; Fri, 20 May 2011 13:09:38 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 3AE9A8FC20; Fri, 20 May 2011 13:09:36 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id QAA00712; Fri, 20 May 2011 16:09:34 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4DD6680E.9040006@FreeBSD.org> Date: Fri, 20 May 2011 16:09:34 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110504 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: lev@FreeBSD.org References: <1606289061.20110519211755@serebryakov.spb.ru> <201105200316.p4K3G6EU039569@chez.mckusick.com> <795474996.20110520122933@serebryakov.spb.ru> In-Reply-To: <795474996.20110520122933@serebryakov.spb.ru> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: 8bit Cc: Kirk McKusick , freebsd-fs@FreeBSD.org Subject: Re: Snapshots fail on large FFS2 volumes regulary -- how to backup /usr/home?! X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2011 13:09:38 -0000 on 20/05/2011 11:29 Lev Serebryakov said the following: > Hello, Kirk. > You wrote 20 мая 2011 г., 7:16:06: > >> Given the size of your storage, you should consider using ZFS >> which is better able to handle such large systems better. > Yes, I know, that everybody loves ZFS now, but it doesn't have two > characteristics which is important for my installation: > > (1) nodump flag or any other way to mark directories and files as > not-importand for backup. "zfs send" is all-or-nothing solution, and > now my users use "nodump" to reduce backup sizes greatly. Two options: a) you don't have to zfs send all filesystems, just the ones that you really need; and you can easily create many filesystems with ZFS; you can tag filesystems that you do not want to backup with user properties. b) you can use something else for backups Besides, zfs send / receive best works for replicating data. Storing results of zfs send for later restoration is not a good idea, IMO. > (2) Incremental backups with a little of local information (zfs send > can send difference between snapshots, but system needs to store old > snapshot for this). > Second one is not so important yet, because there is a lot of free space, > but "zfs send" could not do anything with (1) :( > > All other backups solutions doesn't store full FS information, as > works on file level, not FS one :( This sounds more like a theoretical than practical objection. If you don't lose any information that you actually need, then a solution works. Take a look at e.g. archivers/star. >> My second suggestion is that you try building UFS2 with 32K >> blocks and 4K fragments. That will reduce the number of resources >> needed to take the snapshot. > I'll try this. But I remember, that some time ago (about 7.1-STABLE) > there was deadlock in kernel memory allocator when different UFSes > on system uses different block sizes... > -- Andriy Gapon