Date: Fri, 20 May 2011 16:09:34 +0300 From: Andriy Gapon <avg@FreeBSD.org> To: lev@FreeBSD.org Cc: Kirk McKusick <mckusick@mckusick.com>, freebsd-fs@FreeBSD.org Subject: Re: Snapshots fail on large FFS2 volumes regulary -- how to backup /usr/home?! Message-ID: <4DD6680E.9040006@FreeBSD.org> In-Reply-To: <795474996.20110520122933@serebryakov.spb.ru> References: <1606289061.20110519211755@serebryakov.spb.ru> <201105200316.p4K3G6EU039569@chez.mckusick.com> <795474996.20110520122933@serebryakov.spb.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4DD6680E.9040006>