Add option to create full backups instead of per-target

[bannmann]

My hand-crafted tarsnap script used one archive per run, so I wanted to keep it that way when I switched to ACTS.

This PR adds that option, but keeps the existing behavior as the default.

[assistcontrol]

I understand what you're trying to accomplish with this patch, but I wonder whether it's possible to accomplish this without such an invasive modification (it provides an option that completely changes the behaviour of the single most important option).

Just brainstorming here: what about null-mounting the paths you want?

mkdir -p /var/tarsnaproot/etc /var/tarsnaproot/home_me
mount -o nullfs /etc /var/tarsnaproot/etc
mount -o nullfs /home/me /var/tarsnaproot/home_me

And then just back up /var/tarsnaproot? You could even put the above commands in $prebackupscript and umount them in $postbackupscript.

[bannmann]

Unfortunately, nullfs is not available on my system: I'm on WSL, so I there's no kernel I could recompile or switch. I imagine other users (even some on *nix systems) may be in a similar situation. Given that ACTS focuses on being portable, I would see it as an advantage to support that use case without requiring certain OS packages and/or kernel modules.

Anyway, I thought of emulating your nullfs approach with symlinks and then using --strip-components 2 so that inside the archive, I'd e.g. have etc instead of var/tarsnaproot/etc. Then, I'd obviously need to change the exclusions in /etc/tarsnap.conf accordingly, e.g. from mnt/c/Users/Jens/Downloads to var/tarsnaproot/mnt/c/Users/Jens/Downloads.

TBH, I feel that's an awful lot of complexity to force upon the user. Using the fullbackups approach, however, would be dead simple, and has a few other advantages:

• It "feels right" (subjective, of course). Incidentally, it closely matches what Apple Time Machine does (i.e. one directory per backup, full of hard links to files).
• It allows removing a directory from the backup targets without affecting archive pruning.
• Although I did not test it, it may even allow implementing support for backing up directories that contain spaces.

Fun fact: to me, learning that ACTS implements a "one archive per directory" approach was a surprise. I can't think of a use case where that approach offers substantial advantages over the "one archive per run containing whatever directories you had configured at the time", so it felt like an arbitrary choice. Disclaimer: I'm no expert in either backup systems or Linux.

[alexjurkiewicz]

Thanks for the PR. However I also have reservations about it.

The reason for per-directory backups:

When I wrote acts, the use-case was backing up configuration and state on servers. There were only a few paths I cared about (etc and var, mostly) -- that's where the initial "whitelist" approach came from. I agree that for desktop backup, a "blacklist" approach makes more sense.

My general reservations for any change:

acts is a relatively mature tool, and I've always seen it as more like Latex which became "more finished" over time, instead of more typical software which gets "more better" over time. Backup software should be simple and reliable.

My specific reservations for this change:

1. I think you can approximate this feature with backuptargets -- it's not like Unix suffers from top level directory sprawl, a handful of entries will cover your system forever.
2. Having two ways to specify "backup mode" is a step backwards for UX.
3. Adding a second workflow to acts makes the code much more complex and that much harder to test (it's already pretty difficult, as seen by the bugs over the years).

In my mind, the benefits are not large enough to justify this feature.

Where this change would work:

I think you are right -- full server backup is a more natural fit for desktop use cases, and probably many server use-cases now too. It's also simpler to implement, if you removed per-directory workflow from acts you would end up with something much smaller and easier to configure.

So why not consider that? Fork acts and give it a new name. Pull out the per-directory logic and start over with something simpler.

[bannmann]

Thanks for the explanations, @alexjurkiewicz! I understand your reasoning. Usually, my approach is "avoid forking, make the upstream project more versatile instead". But you convinced me that in this case, doing so would do more harm than good.

I'll go ahead and give my fork its own identity and focused direction. Thanks again to you and @assistcontrol for the quick reactions and taking the suggestion seriously (despite ultimately rejecting it). In my experience, both things cannot be taken for granted :-)

[assistcontrol]

Once you have the fork up and running, let us know. I’d like to be able to link to it from the FAQ.

[bannmann]

@assistcontrol, the fork is ready: CalSnap. Thanks again!