Hello Derek, Sorry for the delay of response. I wanted to take the time to properly answer your questions.
This design is built specifically for our Minarca clients. The central server is not aware of the location of each client. Clients might be mobile behind a NAT, or firewall. So our central server is receiving connections. About the security conserns. We isolate each users repository based on the SSH keys. If one client is compromised, only the associated repo is compromised. Any how, is the client is compromised, all the data is accessible to the hacker. To mitigate the repository corumptions, either because of a hack or any reason, we have zfs snapshot to recover. In you case, a hacker could eventually, do modification to rdiff-backup code to corupmt the backup. On Thu., Jan. 30, 2020, 11:01 a.m. Derek Atkins, <[email protected]> wrote: > Patrik, > > On Thu, January 30, 2020 10:29 am, Patrik Dufresne wrote: > > > > I'm in the same boat as many of you, I have more than two hundred servers > > using rdiff-backup directly or through Minarca and it's impossible to > > migrate all of them at once. I've been thinking about a migration plan > for > > some time now and I have a general idea that I can't wait to put in > place. > > I'm planning to work on a solution end-February. The general idea is to > > pre-compile rdiff-backup 1.2.8 and 2.0.0 as individual executable and > > deploy both of them on the central server as rdiff-backup-1.2.8 and > > rdiff-backup-2.0.0. Then reconfigure the SSH server using a script to > > either call rdiff-backup-1.2.8 by default and call rdiff-backup-2.0.0 > > based > > on some condition. > > I'm curious -- do you have each of your 200 servers call into the > centralized backup server? Or do you have your backup server "reach out" > to the 200 servers? > Our deployment of rdiff-backup is solely based on Minarca as a centralized server. So all our "clients" are connecting to the centralized server. It's built this way because our clients are distributed, behind NAT, some of them are mobile and some of them are Windows. With these constraints, we can't have a centralized server reaching the clients. > > I actually have it set up so that the backup server reaches out to the > servers being backed up. I did it this way to limit the access to the > backups themselves, and that the servers being backed-up could be "dumb" > about their backups. It makes sense if the computer you are backing up are always reachable without NAT and if all of them are Linux. > Specifically, all the "private keys" necessary to > backup a device are sitting on the backup server and not on the servers > being backed up (modulo that server's existing SSH key). To ease the SSH key exchange, we provide Minarca Client to our users. After installing Minarca clients, the user must enter it username and password to establish a connection with the Minarca centralized server. During this process, it exchanges the SSH keys through a web service over Https with the Minarca Server. > It would also > prevent someone who "breaks in" to one server to gain access to the backup > server and corrupt backups from other servers. > To mitigate this Minarca Server provide an SSH entry point that restricts each user into its own space. In other words, if one client gets compromised, only it's data get compromised. A malicious user cannot get access to other backup. I'm also looking for a way to add additional layers of security using containers. > In my case, I could have a configuration that "knows" the version running > on the server being backed up and calls the appropriate incarnation of > rdiff-backup on the backup server. But I would rather this be automated, > so I don't have to pay that close attention and ensure both ends are > properly synced manually. > I'm definitely looking toward a similar solution where it's seamless. The more I'm thinking of it, we may need to change the code in rdiff-backup to help us. What would really help is having rdiff-backup calling a different executable in the remote schema. Instead of calling "rdiff-backup" it should call rdiff-backup2.0.0. And rdiff-backup could be a symbolic link to the default version, either 1.2.8 or 2.0.0. That would really simplify the migration process for everyone. @EricZolf <[email protected]> Do you think it's feasible ? It would mitigate all the migration issue and API incompatibilities. We could also call "rdiff-backup2" (with only the major version) and bump the major version only when an API incompatibility get introduced in the code. > -derek > > -- > Derek Atkins 617-623-3745 > [email protected] www.ihtfp.com > Computer and Internet Security Consultant > >
