[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
- Re: Backward compatibility of next beta, (continued)
- Re: Backward compatibility of next beta, Derek Atkins, 2020/01/28
- Re: Backward compatibility of next beta, EricZolf, 2020/01/29
- Re: Backward compatibility of next beta, Derek Atkins, 2020/01/30
- Re: Backward compatibility of next beta, Reio Remma, 2020/01/30
- Re: Backward compatibility of next beta, Derek Atkins, 2020/01/30
- Re: Backward compatibility of next beta, Arrigo Marchiori, 2020/01/31
- Re: Backward compatibility of next beta, Arrigo Marchiori, 2020/01/30
- Re: Backward compatibility of next beta, Frank Crawford, 2020/01/30
- Re: Backward compatibility of next beta, Derek Atkins, 2020/01/30
- Re: Backward compatibility of next beta, Patrik Dufresne, 2020/01/30
- Re: Backward compatibility of next beta,
Derek Atkins <=