On Tue, 2019-06-04 at 23:20 +0200, Ángel wrote: > > In which case I think the argument about how to make sure Evo is > > stopped before doing a backup is pointless. Just don't stop it. > > > > poc > > Even if a program is transactional, it only guarantees the state at a > given point of time. Not that you can run a generic backup program in > the background while the program works and that it will be consistent. > > In order to do that you would need to work on a frozen filesystem. For > instance using LVM. btrfs also supports making a snapshot of a volume, > which is atomic. Then you could run your backup program over that copy, > and then (optionally) remove the snapshot. > > Suppose you were working locally on a maildir while you are running > tar(1) for making a backup.¹ > > 1- tar reads the list of files on cur/ and starts reading them one by > one to store them > 2- you read a message, it gets renamed from > 1528146778.123_0.evolution:2, to 1528146778.123_0.evolution:2,S > 3- tar attempts to backup ‘1559682696.123_0.evolution:2,’, but as it's > not there, will log an error and continue. > > The file has been on your mailbox for a year. The rename itself is > atomic. A power failure would not lose that file [if it's on a journaled > fs]. Yet your backup missed it.
Good point, and another reason to use IMAP rather than POP. Even though parts of the IMAP local state may be lost due to a race condition, it can always be recovered from the server, which AFAIK *is* transactional. poc _______________________________________________ evolution-list mailing list evolution-list@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-list
