Backing up via snapborg allows you to see file structure, because actually it is a file-based backup. snapper here allows me to separate snapshot creation from actual backups.

I guess we disagree about the point of backups then.

We just use different threat models.)

For me, the main threat is disk failure, so I want to get new disk, restore system from backup and continue as if nothing happened.

Surely, if your hardware or OS configuration changes, you should not backup /usr, /etc and other folders.

However, the proposed workflow could be adapted to both scenarios: a single snapborg config backs up snapshots from a single subvolume, so I, actually, use two configs: one for /home excluding /home/.home_unbacked and another one for / excluding /var and some other directories. This two configs have different backup schedule and different retention policies, so in case of hardware/OS change, I’ll just restore only /home backup without restoring /.

btrbk requires, that destination disk is also formatted as btrfs.

I didn’t want to have such constrain.

Snapshots are made atomically, so this workflow allows you to separate snapshot creation from actual backing up.

As subvolumes are dynamically sized, you can create as many subvols as you like and backup those, that need it.

Thanks. :3

BcacheFS also supports snapshots, so I think that it should be relatively easy to port snapper to it. Probably, it is already done, but I haven’t checked.

Have you considered cryfs?

First of all, let’s recap how TOTP works: your authenticator app stores “TOTP password” in an accessible way (some apps store it plaintext, Aegis stores them in an encrypted DB. They can also be stored on Yubikey.). To generate one time code, the app takes the password, concatenates it with current time rounded to 30 seconds and compute a hash from this string.

The resulting hash is used to create a 6 digit code, that you’ll enter on login.

To check the code, server repeats the same procedure and compare your result with the just generated one.

As you can see, for this system to work you and the server must use the same hash function.

Conclusion: 1)Hash function in TOTP has nothing to do with password storage, it is used only for TOTP-code generation. 2) Cryptographic security of the hash function is not much a concern here: TOTP code expose an extremely low amount of information about TOTP password, so to reliably recover the password from TOTP-codes you’ll have to intercept millions of them.

Geph were not mentioned yet. It will likely not solve the problem mentioned by OP, but it is VERY censorship resistant.