Is BiT suitable for archive backups of Timeshift snapshots?

Currently, I have a separate partition for `/home`, and I allow Timeshift to store snapshots there. I have external media, but they're rarely connected - so they wouldn't be suitable targets for Timeshift's normal operation. I had the thought that from time to time it would be a good idea to back up my Timeshift snapshots explicitly on another physical drive. Naively, I tried running BiT as root (since the `timeshift` folder is owned by root), and setting up a profile to back up `/home/timeshift`, with no exclusions (reasoning that everything in there is there for a reason and might be needed if it were used for a system restore). I pretty promptly ran into the issue described in https://github.com/bit-team/backintime/issues/1003, which surprised me because if the log file is in `/root/.local` then it should be underneath `/home/timeshift`. But I guess that the snapshot contains symlinks to things in the running system and rsync tries to follow those. More worryingly, *the drive was still active* after I received the error message in the terminal (and the GUI stopped updating, and a "failed" marker file appeared in the backup folder). It was still active for several seconds after I quit BiT. (Fortunately this was on a new drive with tons of room, so no risk of exhausting the disk.) I also found https://github.com/bit-team/backintime/issues/1583 which makes it sound like maybe this isn't supposed to be possible, if people are arguing to exclude "snapshots" by default.... Is backing up `/timeshift` folders a supported use case? Are specific file-pattern exclusions necessary; and wouldn't they cause a problem with restoring from the backup (or rsyncing back to the original snapshot folder)? Would it have actually worked despite the one error message, such that I should have just let it run (it seems like rsyncing literally millions of files, most of them being hard links, would have been rather slow)? Are symlinks a problem, and if so how would I work around it? Karl Knechtel {:>

I think the short answer is no. A better strategy might be to sometimes use a target directory on the external drive for creating the original Timeshift backup. Or you might manually copy the timeshift directory to an empty directory on the external drive using rsync with the --hard-links option. - Derek On Tuesday, November 19th, 2024 at 9:07 AM, zahlman via Bit-dev <bit-dev@python.org> wrote:

Fair enough. From some more research I got the impression that "raw" rsynced copies are still problematic, for reasons that I wouldn't want to have to figure out if I were in a situation of actually needing the backup of the restore point. So I think that going forward, my strategy will be to just make sure I can plug in external media for "on demand" snapshots, while letting the regularly scheduled ones take place locally. Thanks anyway. Karl Knechtel {:> Sent with Proton Mail secure email. On Tuesday, November 19th, 2024 at 8:45 PM, Derek via Bit-dev <bit-dev@python.org> wrote:

I think the short answer is no. A better strategy might be to sometimes use a target directory on the external drive for creating the original Timeshift backup. Or you might manually copy the timeshift directory to an empty directory on the external drive using rsync with the --hard-links option. - Derek On Tuesday, November 19th, 2024 at 9:07 AM, zahlman via Bit-dev <bit-dev@python.org> wrote:

Fair enough. From some more research I got the impression that "raw" rsynced copies are still problematic, for reasons that I wouldn't want to have to figure out if I were in a situation of actually needing the backup of the restore point. So I think that going forward, my strategy will be to just make sure I can plug in external media for "on demand" snapshots, while letting the regularly scheduled ones take place locally. Thanks anyway. Karl Knechtel {:> Sent with Proton Mail secure email. On Tuesday, November 19th, 2024 at 8:45 PM, Derek via Bit-dev <bit-dev@python.org> wrote:
participants (2)
-
Derek
-
zahlman