[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Live Fille System Backup

Hash: SHA1

On Sat, May 06, 2017 at 02:18:47PM -0300, Henrique de Moraes Holschuh wrote:
> On Sat, 06 May 2017, tomas@tuxteam.de wrote:
> > Hm. That just means that the file will change after being copied.
> There can also exist busy file *sets*, which need to be atomically
> snapshotted (this is, of course, application specific).

Yes, this is what I meant by "skew": the point in time files are
copied varies. Even worse, some applications might have essential
parts of their state in RAM, not committed to file at all.

That's why I mentioned snapshotting (LVM, or overlayfs, or a file
system which can do the trick, as zfs or btrfs). If you go the whole
way of zfs or btrfs, those file systems can do better than rsync

For a database worth its salt there are other possibilities (PostgreSQL
can save a consistent state on-disk) -- after all they're in the
transaction business.

> "busy", as far as backups go, means:
> 1. a file changes [either in memory/buffer cache, or in the backend
>    storage] *while* being copied (so it is internally inconsistent) --
>    backup will have sections of the old file, and sections of the new
>    file.

Rsync will notice and warn on that. Of course, at the next attempt
that can happen again :)

> 2. one or more components of a set of several files change *during*
>    backup (files may be internally consistent, but the set of files
>    itself isn't).

Only the application can know that. But this is a realm where snapshots
won't help either, without the application's help.

> In some cases, (1) and (2) can manifest as files missing from the
> backup, or being zero-sized.

If I understood you correctly (2) won't produce empty or missing files,
just inconsistent application state.

- -- tomás
Version: GnuPG v1.4.12 (GNU/Linux)


Reply to: