Date: Thu, 21 Feb 2019 07:55:15 +0100 From: Polytropon <freebsd@edvax.de> To: "@lbutlr" <kremels@kreme.com> Cc: freebsd-questions@freebsd.org Subject: Re: Duplicating file system Message-ID: <20190221075515.c815b269.freebsd@edvax.de> In-Reply-To: <C8D2F401-AC47-4089-AD34-A2E7E8E033C0@kreme.com> References: <0A33E3BE-96C9-4D83-B9F7-D4D2792B5161@kreme.com> <32153EA7-4BC5-4EE2-98FA-5BDEE1903BA3@cretaforce.gr> <4CAB4BC4-0473-41CF-AF03-D1CE796F5545@cretaforce.gr> <0F4BBC09-3F9D-4740-A8E4-BB3B87F2A657@kreme.com> <20190221032121.c0006dfe.freebsd@edvax.de> <C8D2F401-AC47-4089-AD34-A2E7E8E033C0@kreme.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 20 Feb 2019 20:59:21 -0700, @lbutlr wrote: > On 20 Feb 2019, at 19:21, Polytropon <freebsd@edvax.de> wrote: > > With this in mind, I'd start with an 1:1 copy using dd, and from that > > point on, have a scheduled job of rsync or cpdup in place to have any > > source changes affect the "copy drive". > > I will try cpdup as I have tried rsync already and it is too > resource intensive to run it constantly. Even with a 5 minute > delay sometimes a task will not finish before the next one > starts and then a cascade will bring the system down as more > and more processes get stuck. This makes the scenario even more look like a situation where a mirrored approach (like software RAID, gmirror) is a good solution; writes will happen in quasi-parallel and transparent to the writing process, so those race conditions won't appear. But definitely try cpdup, it might work fast enough to fit the time window. :-) -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20190221075515.c815b269.freebsd>