Currently, a friend and I back up to each other’s NAS. The setup goes like this:
I run kopia on my NAS,
my friend runs Nextcloud behind a reverse proxy on his NAS,
my kopia backs up data from my NAS to his Nextcloud via WebDAV,
repo size is about 5 TB,
and vice versa.
The backup process runs well. However, repo verification is basically impossible. I wrote about it a while ago over on GitHub. We have not found a solution to this. But now I had the idea that maybe changing the setup could solve that problem. Would it make sense to:
run kopia server on my friend’s NAS, behind a reverse proxy,
run kopia client on my NAS,
my kopia client backs up my NAS data to his kopia server,
and vice versa?
So far, I’ve come up with these questions:
Would this change make sense or am I misunderstanding kopia server?
Is it safe to just put kopia server behind a reverse proxy and use a strong password, or would additional hardening be required?
Not being able to verify our repos is bugging both of us a bit, particularly since I’ve already had the pleasure of discovering 32.179 errors before. I would really appreciate input.
First, repo verification is best done locally, so either from a local Kopia client against a local fs based repo or from the Kopia server against a local fs based repo. That alone will probably solve your verification issues in regards to latency and speed.
I am running my Kopia server behind a HAproxy without any issues on a local 1 GbE fibre connection at home and I am generally pleased with its performace regarding remote clients.
Given both of your connections are fast enough, I don’t see any issues with such a setup.
Just to make sure I understand correctly. If my friend runs kopia server on his NAS and the repo is also on that same NAS, then I should be golden, right?
I found this post about verification by @jkowalski super helpful so far and have been trying to get the daily 0.3 percent verify going, but couldn’t with our current setup. Did I misunderstand him and he was talking about local repos (as recommended by you) or is my repo simply too big (5TB) or is WebDAV just a bad protocol for verification?
This sounds very promising, thanks for sharing your experience.
Basically, yes. As long as Kopia server or client has direct accesss to the repo files, the connection to/from the client does only matter , when it comes to actual data transfer while creating a snapshot.
We are doing that even between cities, e.g. between Vienna (Austria) and Hamburg (Germany)… and there are at least 20 or so TB in the repo.
i have a similar setup with 2 nas server remotely located i have some undred of gig, for each server, can i spin up 2 kopia server with repository configured and make a cross backup?
It really depends on what you’re trying to achieve. If you want the repo to be redundant, I’d suggest to look at kopia repo-sync, which will synchronize a given repo to anywhere else - even if the target repo has another format. I am using that to synchronize my local Kopia server’s repo to an Wasabi S3 bucket. This is the most efficient way to clone your repo.
If you do have two NAS at separate locations and you can spin-up Kopia servers on each of them, sure, they could backup data from each other. However, I’d strongly discourage trying to backup the Kopia repos as well - only the “regular” data.
That’s exactly the way, I have done that. If you want additional security measures, knock yourself out. Easiest thing would be, if both endpoints had fixed IPs, but if that’s not the case, you could also deploy some port knocking and have your Kopia clients knock before starting the snapshot.
However, this in not something Kopia itself supports, so that would have to be configured with OS level tools.
On the other hand, Kopia is that much of a niche product, that no “commodity” malware will be able to cope with it, so I deem the repo behind a reverse proxy safe enough for my purposes, given a strong enough password.
I’ve mulled this over a bit and one more question has come up: my friend would have to know my repository password, right? At the moment, the password to my repo is in my docker compose on my NAS, but in the new setup, my password would be in his docker compose on his NAS (and vice versa). So we would both have to trust each other, but also each other’s security measures. We would both like to avoid that.
Is there a way to run kopia server on my friend’s NAS with my repo locally on his NAS, without him knowing my repo password?
Yes, that’s correct. I actually thought, that you would simply deploy a 2nd NAS as his, but I can see, that this setup would require a lot of trust… which I actually couldn’t even muster, if the guy was ma best friend. We’r all only human after all.
Oh man, that’s such a shame. Do you know if this is something that could be changed in Kopia in the future? Is it worth a GitHub issue / feature request?
I imagine we’re not the only people who would like to set this up.
I probably read way too fast this thread and possible miss something, but… their is proven by time very good backup rule: 3-2-1 where:
One copy - is an actual working file
Second - local, on premises backup
Third - of site backup
So here is my 2 cents:
I see in your workflow only 1 & 3. What you can do, - is to buy any external drive(s) (or better yet slip an actual extra hard drive(s) into machine that is subject for backup) and make all backup/verification/policy locally then simply run kopia’s sync-to to any off site locations via SSH (that can be tighten to accept only specific connections from specified IP as well uses public keys to secure even more) that will sync only new changes. SSH is available now on all operation systems. This way you would have 3-2-1 backup, where you would have secure off site synchronized actual backup copy that is encrypted, you would have locally, on premises copy of your backup for fast restoration if needed and you would eliminate network’s bottle-neck.
One more thing, WebDAV on nextcloud is wayyyy to slow and is subject to choke on some events (it highly depends on how PHP server workers is set). If you would still continue to use WebDAV for transport, I suggest you to take a look at SFTPgo that can run on any platform, secure and it isn’t PHP, but the same GoLang as kopia and it actually supports SSH too at first place.
I don’t see, how that could be made to work. To secure a remote Kopia server, you would need to be able to remotely login and start it manually. This might safeguard your data, but then anything kind of auto-start is out of the question and that server could only ever be started up manually.
I was thinking more along the line of whether it could be possible to run kopia server without putting the repo password into the docker compose, but the client supplying it.
No, that won’t work. Kopia Server wouldn’t be running, because it can’t decrypt the repo - its kind of a chicken and egg problem. The key is to not let the remote clients have the repo password, but only their own access password. The repo password is for the instance that accesses the repo itself or on the behalf of remote clients.
There is no solution in Kopia for that and I doubt that there ever will be one, since it poses a significant security risk to the repo. Afaiks, the only way around that would be the options I pointed out already.
Easiest thing would be, if both endpoints had fixed IPs, but if that’s not the case, you could also deploy some port knocking and have your Kopia clients knock before starting the snapshot.