-----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, to...@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-----
