Best practices comes down to what you do or do not want the VPN clients to access. This mostly comes down to routing and firewall rules.
So, what should your users have access to?
Also what is the vpn?
Best practices comes down to what you do or do not want the VPN clients to access. This mostly comes down to routing and firewall rules.
So, what should your users have access to?
Also what is the vpn?
I’m not entirely sure what the actual question is. Can you rephrase what exactly you are trying to accomplish?
If the total data is 3tb and you want disk failure protection I would take your two 6tb disks and put them in a mirror. With the amount of data you have and the drive sizes at your disposal that makes the most sense. This leaves you with 3tb free for growth. If you wanted an additional backup I would recommend storing it in a different location entirely or pay a cloud provider like Backblaze.
I would do this with ZFS but you can also do this via LVM or just straight md-raid/mdadm. I’m not sure what your issues are with zfs on popos but they should be resolvable as Ubuntu supports zfs fine to my knowledge.
An alternative you could consider is using mergersfs to logically pool indivial filesystems on each of the disks and then use SnapRAID to provider some level of protection. You’ll have to look into that further if interests you as I don’t have to much info in my head related to that solution. Its not as safe as a mirror but its better than nothing.
Your title is about backups but your question seems mostly just about how to set up your storage for backups.
You can go about pooling disks in a few ways but you first need to define what level of protection from failure you want. Before going further though, how much space do you project that you will need for backups?
If you want simple you’ll have to manually decrypt each time it needs doing.
If you want it to be “automatic” then your best bet is something network based. A “simple” would be to just have a script ssh’s somewhere, pulls the decryption key, and then decrypts the disks. There’s plenty of flaws with this though as while a threat actor couldn’t swipe a single encrypted disk they could just log in as root, get your script, and pull the decryption key themselves.
The optimal solution would be to also encrypt the root partition but now you need to do network based decryption at boot which adds further complexity. I’ve previously used Clevis and Tang to do this.
I personally don’tencrypt my server root and only encrypt my data disks. Then ssh in on a reboot or power event and manually decrypt. It is the simplest and most secure option.
I backed this: https://www.crowdsupply.com/cool-tech-zone/tangara
Its not yet released and is in the manufacturing process but I think it’s worth considering
I prefer restic for my backups. There’s nothing inherently wrong with just making a copy if that is sufficient for you though. Restic will create small point in time snapshots as compared to just a file copy so I’m the event that perhaps you made a mistake and accidentally deleted something from the “live” copy and managed to propagate that to your backup it is a nonissue as you could simply restore from a previous snapshot.
These snapshots can also be compressed and deduplicated making them extremely space efficient.
Just look at the bit rate of what you are streaming and multiply it by 3 then add a little extra for overhead.
Ah, I was wondering why I couldn’t get it to detect my yubikey. I saw keepassxc-full in the repo but that also didn’t seem to work. I’ll have to revisit it.
What exactly do you mean by “not mountable”?
The primary reason a private track is private is to make it feasible to maintain a curated community. Many users are not good torrent citizens. Many users are not good netizens in the first place. More than a few will look to actively do harm. Keeping a mostly closed community allows the vetting of users and those who end up breaking the rules are dealt with swiftly.
The extra barrier of entry also helps prevent bad actors from operating on the site. This is of course not a full proof thing but it is obviously much better than a public site.
Additionally running a private tracker and site takes server resources that are not free. Limiting the total number of users is a way of maintaining uptime by staying within your operational limits.
I’m sure there are other benefits for private trackers but these are at least a few.
I am not going to explain why someone on the internet was mean to you. Given the tone of this post I wouldn’t be surprised if it was deserved.
Are you asking about why private trackers are private or are you asking about why a handful of people were mean to you who also happened to use a private tracker?
Edit: typo
Debian for all things.
Add a test folder, add some data, delete the test root folder and see if it deletes the data.
Error message? Nextcloud logs?
Can’t tell you whats happening without information about what’s happening other than “it doesn’t work”.
But I wasn’t even talking about vpns. Just private trackers and how to get into them.
I don’t see how thats relevant.
Depends on which tracker. In general though invites and you get invites by association with relevant groups. Sometimes open registration occurs (though rarely) an other times the trakcer may do interviews.
It mostly comes down to time and patience.
You did not answer what VPN tech you are using.
Without that knowledge i would recommend setting up tailscale and having your users use that. If you want to be fully self hosted you can also run Headscale as the control plane instead of relying on Tailscales own service.
I recommend tailscale as it is very easy to grant a user privileges to ONLY use an endpoint as an exit node but also grant access to any other endpoints as needed (such as your future jellyfin server) via theor ACLs.