FYI, if you run vaultwarden using docker compose with your data volume as a folder, all you have to do is bring it down for like 1minute, make a backup of the folders, and bring it back up. I use a cron script to do this nightly. When my vps host went out of business, I restored my docker folder to a new vps and was up and running again in a couple minutes. Also, you could easily restore it to a virtual machine, if you like. Docker with compose is extremely portable.
constantokra
That's pretty neat. I might start doing that, just for kicks.
Now that's the kind of paranoid I was hoping to see in here. High five, pal.
Can you explain why you use onion repos? I've never heard of that, and I've heard of kind of a lot of things.
If you have the option to host physical hardware from your friend's house, I'd go that route for the whole thing. Set it up so they can access your media server locally, maybe even immich, and VPN in for everything yourself, that way you don't have to expose ports, except the wireguard port. Don't acquire new content from their network unless you do it behind a good VPN with a killswitch and they know and are OK with what you're doing.
I would personally rather have my documents, photos and media collection on a computer a friend has physical custody of than in the cloud, but that's on you and your friend. I prefer to host vaultwarden and a notification server, in my case, gotify, on the cheapest vps I could find, which was about 12 bucks a year last I checked.
I'd also set up a tor hidden service for ssh, just so you have another way in, in case something comes up. Or you could get a cheap cellular modem and a yearly Sim card. In the US, red pocket is a good choice, with a limited option available for less than 50 bucks a year. You never know when their ISP is going to do something weird, and you'll be able to figure it out a lot easier if you have a reliable way into your server.
You should probably think about backups too. You can obviously do a backup before you go, but you're going to want to back up at least your new photos while you're gone. I'd suggest looking at koofr lifetime storage plans, as they're pretty cheap for the size.
Airvpn is fine, and also the cheapest option you'll find with any real hope of protection, which is why people are recommending it. It can use openvpn or wireguard, which will work on fedora just fine. I'd personally recommend wireguard, because you can set it up to automatically connect using systemd.
Otherwise, you could try installing riseup's client from the source, available at https://0xacab.org/leap/bitmask-vpn. It's linked on their main site. Don't know if you'll have luck with that. You'll likely have to manually install the dependencies.
You could also try tor.
That's basically the same as my writeup from when I did it. Except I also had a -k all on update-initramfs. Not sure about the switches, so I'll look into them. Thanks.
I was a bit surprised at it as well, but it doesn't for me running Debian headless. If I reboot after a kernel update it'll try to boot into the new kernel and fail waiting for the initramfs, but it'll boot just fine into the previous kernel. Once I update the initramfs it works fine.
If you know what resources you used to set it up, I'd be curious to take a look and see if I missed something.
Encrypt the boot drive, and use dropbear ssh in initramfs to be able to unlock it over ssh during boot. Then set up your data drives however you want, and use a key file on your boot drive to unlock them, once you've unlocked it. All drives are encrypted when your machine is off, and you only need one password you can enter remotely to unlock the whole thing.
Here's a good resource on how to do the initramfs part https://www.arminpech.de/2019/12/23/debian-unlock-luks-root-partition-remotely-by-ssh-using-dropbear/
Also, when you update the kernel you have to rebuild the initramfs with sudo update-initramfs -k all -u, or it won't be able to boot to the new kernel.
I've found it to be a super reliable setup.
I'm not sure how it will work, but if you're worried, just move the download folder before you remove it from within the application. Better yet, if you have the space, just copy the folder somewhere else.
Hopefully someone else has a better answer for you.
This is one of the reasons docker is so great. If you were running the application in docker, you would have mounted that folder as a volume, so if you wanted to move it you'd just stop the container, move the folder, edit your compose file to point to the new location, restart, and from the application's point of view nothing will have changed.
Switching to porkbun would make things a lot easier for you. DNS challenge is why I switched from Namecheap, and it's less expensive and considerably easier to administrate.
I've read that best practice is to do a database dump, in addition to backing up all the data files. It's my understanding that there's a slight chance of corrupting something in the database if you don't stop the service first, since something could be changed while you're doing your backup.
The easiest solution for me, as well as for being able to just restore my files and start the service again somewhere else, is to stop, backup, and restart. It's down for less than 5 minutes while i'm asleep. If I expected better uptime than that I wouldn't be trying to self host.