For example, iOS has these features:

  • iCloud backup restore or peer-to-peer transfer, very early in the device setup process
  • Two ways for things to be stored in iCloud, each with a corresponding list of per-app (not per-folder) toggle switches in iCloud Settings
    • “Saved to iCloud” normal syncing
      • Requires apps to use the right APIs and to handle conflicting changes
      • Allows same data to be read and modified by multiple devices
    • iCloud backup
      • Available for all apps
      • Separate backup per device
      • Only downloaded when setting up a new device
      • In app sandboxes, only excludes tmp (Flatpak equivalent is somewhere in /run) and Library/Caches (equivalent to cache directory in Flatpak sandbox) by default
      • Allows apps to set isExcludedFromBackup attribute for specific files (useful for things that are easy to recreate via download but are expected by the user to not be automatically deleted)
      • Includes system configuration such as home screen layout
      • Backs up a list of installed apps without backing up their executables and assets
  • Synced list of previously installed apps, not separate per-device
  • HaraldvonBlauzahn@feddit.org
    2·
    1 day ago

    Oh, and there is also bup, which might be what you are looking for:

    https://bup.github.io/

    • it stores files in version-controlled copies which can be synced. Perhaps good for backing up photos and such, up to a few GB.

    Two more interesting solutions:

    1. Nix OS and Guix SD let you define a system entirely from single configuration file, so it is easy to re-create when needed.
    2. The Btrfs and ZFS file systems allow to take snapshots in an instant which can very efficiently store earlier versions of files. I used that when working with yocto/bitbake, which compiles an entire embedded system from source - it can handle much larger data volumes than git or bup, and is the right thing when handling versions of binary data.

    And one more, the rsync tool allows to store hard-linked copies of directory trees.

    The key question is however - what do you want?

    • being able to recover earlier versions is essential when working with source code
    • being able to merge such versions in text files is necessary when working on code cooperatively with others - and only source control systems can do this well
    • In 99.9% of the other cases, you just want to be able to re-create a single ground-truth version of all your data after a disaster, and keep that backup copy as current as possible.

    These are not the same requirements, especially the volume of data will differ.

    And also, while you might to want or need to go patch by patch through conflicting source code tree with 10,000 different lines, I guess that absolutely nobody is willing or has time to go through a tree with 10,000 conflicting photographs and match them.

    So the question back is: What is your specific use case and what exactly do you want to achieve?