Date: Wed, 30 Mar 2005 18:59:22 +0100 From: Andrea Venturoli <ml.diespammer@netfence.it> To: Kris Kennaway <kris@obsecurity.org>, freebsd-questions@freebsd.org Subject: Re: mksnap_ffs woes Message-ID: <424AE8FA.8080306@netfence.it> In-Reply-To: <20050330141626.GB73682@xor.obsecurity.org> References: <424AACD1.3060802@netfence.it> <20050330134259.GA66640@xor.obsecurity.org> <424ACEF8.60601@netfence.it> <20050330141626.GB73682@xor.obsecurity.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Kris Kennaway wrote: > It's possible you're seeing deadlock bugs in the snapshot code; you'd > need to compile your system with DDB support and obtain traceback > information as described in the developers' handbook chapter on kernel > debugging. Ok. As soon as I get the chance, I'll do this (I cannot stop a whole network right away). > The snapshot code was intended to support background fsck and that > alone. It's also optionally used by the dump code, but it was not > written as a general-purpose live filesystem snapshot service. Ok. I just think that this, as well as the disclaimer about it being alpha code and the access locks, should be mentioned in the Handbook. Reading that chapter or mksnap_ffs's manual, I didn't get it and I suspect people might get the idea that it is stable code, which provides some functionality that it doesn't. >>Are there other alternatives for live backups? > > Plenty, if you don't demand an instantaneous image of the backup > image. That depends on what you mean for instantaneous... I'll explain my needs briefly: I export (via Samba) a whole bunch of databases that 9 clients read and write. I do not have more details (I didn't write that app myself). The needs are: a) backup data so that in case of severe failure we can get it rapidly back (we are going to loose the last transactions, obviously); b) replicate everything to another machine (via rsync) so that a remote user can see a snapshot of the system status. We probably can live with some incoherent records in a) (after all, something will almost for sure need manual fix anyway); as for b) I fear it might be more prone to problems. So, if for instantaneous you mean at a specific time, I don't care at all wether the image is made an hour earlier or later. All I'd like is coherence. BTW, we have almost no room for changes on the client side :( > The pros and cons of the snapshot code have been discussed on the > mailing lists, and there is a (slightly outdated) information file > here: /usr/src/sys/ufs/ffs/README.snapshot I'm reading all this stuff; I might get back with some more questions later :) bye & Thanks av.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?424AE8FA.8080306>