Comment on How often do you run backups on your system?

• nichtburningturtle@feddit.org ⁨1⁩ ⁨year⁩ ago

  Yes. That’s why I sync my important files to my nextcloud.

  source

  • QuizzaciousOtter@lemm.ee ⁨1⁩ ⁨year⁩ ago

    That’s good. You can also check out btrbk - it’s a tool which can take snapshots for you, like Timeshift, but also back them up to somewhere.

    source
• tal@lemmy.today ⁨1⁩ ⁨year⁩ ago

  You’re correct and probably the person you’re responding to is treating one as an alternative as another.

  However, theoretically filesystem snapshotting can be used to enable backups, because they permit for an instantaneous, consistent view of a filesystem. I don’t know if there are backup systems that do this with btrfs today, but this would involve taking a snapshot and then having the backup system backing up the snapshot rather than the live view of the filesystem.

  Otherwise, stuff like drive images and database files that are being written to while being backed up can just have a corrupted, inconsistent file in the backup.

  source

  • QuizzaciousOtter@lemm.ee ⁨1⁩ ⁨year⁩ ago

    Absolutely, my backup solution is actually based on BTRFS snapshots. I use btrbk (already mentioned in another reply) to take the snapshots and copy them to another drive. Then a nightly restic job backs up the latest snapshot to B2.

    source
  • vividspecter@lemm.ee ⁨1⁩ ⁨year⁩ ago

    btrbk works that way essentially. Takes read-only snapshots on a schedule, and uses btrfs send/receive to create backups.

    There’s also snapraid-btrfs which uses snapshots to help minimise write hole issues with snapraid, by creating parity data from snapshots, rather than the raw filesystem.

    source

    • tal@lemmy.today ⁨1⁩ ⁨year⁩ ago

      and uses btrfs send/receive to create backups.

      I’m not familiar with that, but if it permits for faster identification of modified data since a given time than scanning a filesystem for modification times, which a filesystem could potentially do, that could also be a useful backup enabler, since now your scan-for-changes time doesn’t need to be linear in the number of files in the filesystem. If you don’t do that, your next best bet on Linux – and this way would be filesystem-agnostic – is gonna require something like having a daemon that runs and uses inotify to build some kind of on-disk index of modifications since the last backup, and a backup system that can understand that.

      looks at btrfs-send(1) man page

      Ah, yeah, it does do that. Well, the man page doesn’t say what time it runs in, but I assume that it’s better than linear in file count on the filesystem.

      source