4 ms·

Do you prefer restoring from the original drive instead of a backup because it's faster?

magicalhippo 3y ago
I use a daily full-disk backup on Windows[1], this has allowed me to be back up and running within the hour the few cases my disk died. What's a good alternative for Linux? [1]: Acronis TrueImage, but there are others.
- jeroenhd 3y ago
  With modern file systems like BTRFS you could take a(n incremental) snapshot and send that over the network using btrfs send. Filesystems without snapshots can't be disk cloned that easily, but tools like Timeshift will try to replicate snapshot behaviour using hardlinks, so I assume backups of Timeshift snapshots should also suffice. Timeshift can be configured in various ways, including making daily snapshots. I mostly use it for periodic snapshots and snapshots taken before the package manager runs (as a poor man's System Restore alternative). I don't think Timeshift supports automatically sending snapshots just yet. For that, you'd need to set up a cronjob or systemd timer.
  - o11c 3y ago
    Last time I tried to replace my `rsync` backups, `btrfs send` had grave limitations - something like "you can't actually use the destination filesystem for anything other than the one computers backups" I think?
    - jeroenhd 3y ago
      btrfs receive has some limitations for sure. I don't think having the volume mounted is a problem, but during the transfer the snapshot is read/write. If you modify the volume, subsequent differential updates will fail. If you have some other process messing with the snapshot being received, you also risk messing up the send/receive. There are also limitations w.r.t. the way the volume is mounted; if you alter the default mount point or mounted a subvolume somewhere deep in the chain, receive will also fail. If you have a BTRFS volume on a server that exists purely to receive backups and separate the subvolumes sufficiently (i.e. using specific subvolumes for the different backed up devices), I don't think send/receive should be a problem. I wouldn't back up to the root partition of a running system, I think a dedicated data volume makes a lot more sense design-wise.
zeta0134 3y ago
Often I want to collect a very small number of files that I was working on which are newer than the last complete backup

I use a daily full-disk backup on Windows[1], this has allowed me to be back up and running within the hour the few cases my disk died. What's a good alternative for Linux? [1]: Acronis TrueImage, but there are others.

jeroenhd 3y ago
With modern file systems like BTRFS you could take a(n incremental) snapshot and send that over the network using btrfs send. Filesystems without snapshots can't be disk cloned that easily, but tools like Timeshift will try to replicate snapshot behaviour using hardlinks, so I assume backups of Timeshift snapshots should also suffice. Timeshift can be configured in various ways, including making daily snapshots. I mostly use it for periodic snapshots and snapshots taken before the package manager runs (as a poor man's System Restore alternative). I don't think Timeshift supports automatically sending snapshots just yet. For that, you'd need to set up a cronjob or systemd timer.
- o11c 3y ago
  Last time I tried to replace my `rsync` backups, `btrfs send` had grave limitations - something like "you can't actually use the destination filesystem for anything other than the one computers backups" I think?
  - jeroenhd 3y ago
    btrfs receive has some limitations for sure. I don't think having the volume mounted is a problem, but during the transfer the snapshot is read/write. If you modify the volume, subsequent differential updates will fail. If you have some other process messing with the snapshot being received, you also risk messing up the send/receive. There are also limitations w.r.t. the way the volume is mounted; if you alter the default mount point or mounted a subvolume somewhere deep in the chain, receive will also fail. If you have a BTRFS volume on a server that exists purely to receive backups and separate the subvolumes sufficiently (i.e. using specific subvolumes for the different backed up devices), I don't think send/receive should be a problem. I wouldn't back up to the root partition of a running system, I think a dedicated data volume makes a lot more sense design-wise.

zeta0134 3y ago

Often I want to collect a very small number of files that I was working on which are newer than the last complete backup