Re: Live Fille System Backup
-----BEGIN PGP SIGNED MESSAGE-----
On Sat, May 06, 2017 at 02:18:47PM -0300, Henrique de Moraes Holschuh wrote:
> On Sat, 06 May 2017, email@example.com 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
> "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
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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
-----END PGP SIGNATURE-----