rdiff-backup-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Backward compatibility of next beta


From: Derek Atkins
Subject: Re: Backward compatibility of next beta
Date: Thu, 30 Jan 2020 11:01:49 -0500
User-agent: SquirrelMail/1.4.22-14.fc20

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?

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.  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).  It would also
prevent someone who "breaks in" to one server to gain access to the backup
server and corrupt backups from other servers.

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.

-derek

-- 
       Derek Atkins                 617-623-3745
       address@hidden             www.ihtfp.com
       Computer and Internet Security Consultant




reply via email to

[Prev in Thread] Current Thread [Next in Thread]