Re: Live Fille System Backup
-----BEGIN PGP SIGNED MESSAGE-----
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
anyway.
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.
cheers
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iEYEARECAAYFAlkOJ/sACgkQBcgs9XrR2kZ9DQCfX6V5a9UdO2pixunhFMyuM0ug
GFoAn1R/RLYL2KeRIkfBsL7BqrJJb1/V
=nRRb
-----END PGP SIGNATURE-----
Reply to: