Look, I appreciate you pushing on the UX aspects of the fediverse here. But let me ask yout something. What’s your email address? Is it Lost_My_Mind? No? Oh, because it’s got an @whatever.com on the end? Why is that? Why don’t we have one global, centralized namespace for email usernames such that there’s only a single Lost_My_Mind in the whole world?

Dude, do you even email?

This guy Overton windows.

People are also expected to understand the concept of manually picking a brand of toothpaste. My point is that if we can’t even expect a little consumer choice (the same consumer choice we have in the real world), then we deserve all the monopolization and centralization we get.

Also, selecting a Mastodon server isn’t like some scary technical choice. It’s like a vibe check and a signup form.

1. There are companies you can pay to physically shred your disk drives. You have to be able to trust them of course for this to work.

2. Or if you want to DIY, you can drill or smash your drives. Just wear eye protection, etc. Making the drives inoperative like this is the only thing I’d trust, but you can also software-wipe them first.

Wait. Signal was an SMS client. It wouldn’t cost them anything for a user to send an SMS message. IIRC, they nixed the SMS feature for security reasons, not cost.

I hope one (or both!) of them end up working out for you.

Separate configs is totally reasonable. It just sounds like you haven’t configured your Borg passphrase with borgmatic… Otherwise it wouldn’t prompt for your passphrase at all.

I’m not super familiar with Unraid, but yeah, the borgserver image sounds like it’d work for this… You don’t need borgmatic on the server side unless you want it there to make running Borg commands easier.

Nope! Borg always requires Borg on the remote side. It’s Borg’s biggest strength and weakness versus competing backup systems IMO. Strength, because it can do pretty smart stuff with its own code running on both sides. Weakness, because it means it doesn’t work natively with cloud object storage like S3. It’s a tradeoff like anything else.

Glad to hear it’s (mostly) working out for you! I know you came here looking for best practices with restores, but if you end up coming up with anything yourself, feel free to comment on that Docker borgmatic ticket with requests or ideas. I use the container myself on some systems for the same reasons you do, and I also wouldn’t mind smoother restores!

borgmatic dev here. First of all, if Vorta is working well for you to recover files, then by all means use Vorta! Right tool for the job and all. Having said that, a couple of thoughts on using borgmatic in Docker and recovering files:

borgmatic has a search feature that makes finding a particular file in an archive or across archives pretty easy. So that might be step one in restoring an accidentally deleted file.

Once you’ve found the file and archive to restore, you can either use borgmatic extract or borgmatic mount. With extract, you copy one or more files out of a backup archives. The challenge though is that with borgmatic in a container, by default there’s not an easy way to copy those files into their original locations. However I think the “fix” is to mount your source volumes as read-write instead of (the documented) read-only. That way you can easily copy extracted files back to where they belong.

As for borgmatic mount, you’ve got a similar challenge and fix. You can presumably mount backup archives (or a whole repository) within the container, but then you need to copy your recovered files out of that mount into their original source volumes. So that probably also means those volumes need to be mounted read-write.

Let me know if you have any questions!

I have one Compose file per stack, which is an application and all of its containers, databases, etc. Pretty much the same way I organized things with just Docker.

Since I use Docker Compose with Podman, I just make a single systemd service to run Docker Compose on boot, thereby starting all my containers at once.

Maybe I’m being naive, but it seems like the biggest threat of unchecked AI is “just” the further concentration of wealth (among humans). Which, ironically, poses a catastrophic risk to humanity…

Wait, when did the action happen??

It deduplicates aggressively at the block level. So if your files don’t change much, each additional backup takes very little space. And if a file changes a little, Borg only backs up what’s changed instead of the whole file again.

Borg also has a rich ecosystem of wrappers and tools (borgmatic, Vorta, etc.) that extend its functionality and make it easier to use.

Borg Backup would also fit the bill for backups going forward, especially if OP is still backing up to a local server (as opposed to cloud object storage).

I don’t think Docker’s API and CLI are historically where it’s had problems…

It’s not the “official” way to do it, but you can make systemd run Docker Compose (talking to Podman instead of Docker), which is pretty close to what you’re talking about. And then you don’t have to write stinky systemd INI files for each container.