[Unison-hackers] reconsidering the backups concept

[Christoph Groth]

Greg Troxel wrote:
> unison has a concept of making backups, but this is awkward because:
>
> 1) They are sometimes put in a different place than the replica (could
> be different security properties, could have different space issues).
> I think this shouldn't happen, at least by default.

On the other hand, scattering backup files all over the replica could be
seen as a bad default as well.

A further issue is that the default central backup location is the same
for any pair of replicas, so that backups relating to different replicas
are mixed up.

This could be especially problematic with the backupcurr option for
three-way merges, if the same file is synced with multiple replicas.
The consequence will be that three-way merge may not be proposed in
cases where it would be possible if the backup directories were
separate.

I think that a solution to all these problems could be to
• keep backups centralized by default,
• but make the default backup location undefined, forcing the user to
  explicitly choose one.
The manual could mention that the backup directory should likely have
a unique name for each pair of replicas.

In addition, to solve the security problem, unison could mirror
permissions and ownership when backing up files (and when creating
directories) and warn/fail if setting them is impossible.

> 2) The scheme is simplistic and there is no eventual garbage
> collection of no longer needed backups.  Of course, software can't
> tell what the future holds and "no longer needed" is tricky
> business.  I'm not really sure what to do here, even ig there were
> cycles to do it.  My own approach to backups is to keep them
> indefinitely and buy more disks over time and at some point decide
> they are so old they don't matter.  Because I generally back up the
> contents of replicas, and don't run -auto, I have never turned on
> unison's mechanism.
>
> 3) The interaction of backups for merge and backups on delete/modify
> is not easy to understand, and may not be the best choice.

In my opinion “backupcurr” is more important than “backup” for Unison’s
core functionality.  Backupcurr allows thee-way merges which are very
useful when synchronizing text files, while plain “backup” seems hardly
useful if one has some other backup solution already (as one should).

Moreover, since “backupcurr” explicitly only keeps a single copy of the
*current* version of the file, it does not seem problematic at all to
automatically remove such backups upon deletion of a file.  More than
that, in contrast to plain “backup”, it even corresponds to what Unison
might be expected to do, since the “current version” of a deleted file
is “no file”.

It seems to me that an easy and conservative but useful enhancement of
Unison would be to add an option “deletebackupcurr” (or similar) that
would be “off” by default.

(If breaking absolute backward compatibility is possible, eventually it
could be required to set this option explicitly, and finally the default
could change to “on”, and the requirement to specify it disappear.)

> It might be that it would be good to have "backupmaxage", defaulting
> to off, but settable to e.g. 1 year, that causes unison to
> periodically scan replicas (when syncing, not every time) and remove
> backups that were created too long ago.  It might be that this has
> consequences we don't like -- I don't really know.

I think that this is dangerous if not limited to files that are no
longer in the replica: even an old backup can be the most recent one.
Moreover, simply deleting files of a certain age can be implemented
easily outside of unison.

However, limiting “backupmaxage” to backups of files that are no longer
present in the replicas poses the difficulty that the same backup
directory may be (and by default indeed is) used for different pairs of
replicas, so that it seems difficult to define the concept of “a backup
file of a file that no longer exists in the replica”.

All in all, I do not see a satisfactory and easy solution to this
problem.

This is in contrast to deleting “backups” that are only kept to allow
three way merges.  After all, after deleting a file no three-way merge
is possible anyway.

> I don't intend to work on this, because it solves a problem I don't
> have, but if someone does, please feel free to discuss here,
> especially if you're willing to write code, write manual text, and
> write tests.

I do not speak OCaml and have only limited time for such things, but
I hope to have made the point that adding a mechanism for deleting
“backupcurr” files would be easy, consistent, safe and useful.

Cheers
Christoph
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 869 bytes
Desc: not available
URL: <http://LISTS.SEAS.UPENN.EDU/pipermail/unison-hackers/attachments/20220909/d987e77a/attachment.asc>