rdiff-backup - conseils

Le
Jean-Marc
--Signature=_Tue__3_May_2016_20_13_41_+0200_0e_g1/Wpcr_th+VB
Content-Type: text/plain; charset=UTF-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

salut la liste,

Je suis en train de réfléchir à la meilleure manière de=
mettre en route un système de bakup basé sur rdiff-backup [1] et=
un serveur qui tourne sous Jessie.

rdiff-backup fournit dans sa doc' un setup où le serveur initie les ba=
ckups [2].

En deux mots, c'est un serveur qui "pulle" les clients à partir d'un c=
ron.

Avantage :
- setup minimal sur les clients;
- centralisation des logs;

Désavantage :
- demande un serveur ssh sur tous les client;

Une autre option est de faire des pushes à partir des clients. Ce qui =
me semble plus logique.

J'aimerai avoir votre avis : d'un pull ou d'un push depuis les clients ? Qu=
el setup aurait votre préférence ?

Bonne soirée.

Jean-Marc <jean-marc@6jf.be>

[1] https://packages.debian.org/jessie/rdiff-backup
[2] http://arctic.org/~dean/rdiff-backup/unattended.html

--Signature=_Tue__3_May_2016_20_13_41_+0200_0e_g1/Wpcr_th+VB
Content-Type: application/pgp-signature

--BEGIN PGP SIGNATURE--
Version: GnuPG v2

iQIcBAEBCAAGBQJXKOpVAAoJEEBxy1wt6cT8EXIP/0IF0724D84WaKPupv+1au8g
h2WBCjHJfRIKddNVhpSUaRU++S5AVN8V4ZzvEC9y7MMMji0z5oPvSQvv5DbxQ0tB
DPkkrvHrhncq0aMJyD/YUNHBFgh+GlRlrCn76JWMzGFprSHnQn8B56cTmYwCzSL+
o6BouT86GWmpB/FmVg5KlwiGwAp1XRIdUyYYaKmAGsfgEWQAN3ZLncLjd8c6yjV/
lfD5oe7acLPldVbaUcF6TFiNz/zDBGjeGPMcPYkBPtF8DyqBYEDXuaxbms1p6bpU
mBwwB88xZ1sldzlf1E4WW+Bov5cbsbJsw0Ng/X2WAC6Tt0yoqMzQzsVBm9vF0gdu
3ejVZQy4c+g7HQQ3k74jUotiV/qalA5WukRo0KflSB7pDqp/nDWMdWS3CtNPU87M
KqMST8zRhx9sWKxdY9A+WqqQxr0iWBotJg2oX/f6b8Ci5ijmZmA2+KIKYKs9v1Hp
uWR5QPmLsG1HD0smfYnhQq87bH7qvS/Qkvol3g+ts0MxHSYQBM3OZrbRDab/1jrP
+6dowgGGJgzTzLCdQx5ufnuJUXIxIPm08NT2qkRbZjyTazT3DoFR647ZDhyZrnoj
ZxzYGcCs3Vn2g281O9ZsUgSGYH4ccEAPc5+JsL3ujRPGqZZjXBvlPpG1RB1V6yqT
bA42Vlq6+Fu/5LLHpOL2
=Tn14
--END PGP SIGNATURE--

--Signature=_Tue__3_May_2016_20_13_41_+0200_0e_g1/Wpcr_th+VB--
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
JF Straeten
Le #26397268
LO,

On Tue, May 03, 2016 at 08:13:40PM +0200, Jean-Marc wrote:

J'aimerai avoir votre avis : d'un pull ou d'un push depuis les
clients ? Quel setup aurait votre préférence ?



Ça dépend quand même beaucoup de la machine qui fait serveur de
backup...

Sur un NAS Intel SS4000-E (petit machin ARM), je lui avais fait faire
des pulls, à son aise, de manière séquentielle sur une série de
machines, pour que la charge dessus soit ± tout le temps la même...

Sinon, quand tous les clients balancent leur push, ça la mettait sur
les genoux, et le backup durait des plombes, avec certains parfois
toujours en cours à l'heure suivante, quand les suivants
recommençaient.

Pas glop...

Ou alors, il faut régler une fenêtre de temps différente sur chaque
client, mais alors c'est autant faire un pull et que le serveur de
backup se débrouille pour passer sur chacune à son tour...

Maintenant, si t'as deux Xeons E5 dans ton serveur de backup sur des
disques SAS, tu t'en fous un peu, c'est clair, et tu peux faire des
pushes :-)

Hih,


--

JFS.
Sébastien Dinot
Le #26397266
Bonsoir,

Jean-Marc a écrit :
En deux mots, c'est un serveur qui "pulle" les clients à partir d'un cron.

Avantage :
- setup minimal sur les clients;
- centralisation des logs;

Désavantage :
- demande un serveur ssh sur tous les client;

Une autre option est de faire des pushes à partir des clients. Ce qui me
semble plus logique.



Que nenni ! Le serveur de sauvegarde doit être le moins exposé possible
car il est précieux. Il est donc largement préférable que le serveur de
sauvegarde se connecte sur les serveurs à sauvegarder que le contraire.

Et pour durcir un peu la configuration sur les serveurs sauvegardés, il
faut faire en sorte que la clé utilisée ne soit acceptée que depuis l'IP
du serveur de sauvegarde, que les connexions interactives depuis
celui-ci soient interdites et que les commandes exécutables dans ce
contexte soient limitées via un petit script de filtrage.

Personnellement, j'utilise rdiff-backup ainsi pour sauvegarder depuis
des années une grosse vingtaine de serveurs et j'en suis pleinement
satisfait.

Sébastien



--
Sébastien Dinot,
http://sebastien.dinot.free.fr/
Ne goûtez pas au logiciel libre, vous ne pourriez plus vous en passer !
Christophe Moille
Le #26397267
--Kynn+LdAwU9N+JqL
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Le Tuesday 03 May 2016 à 20:13:40 (+0200), Jean-Marc a écrit :
salut la liste,

Je suis en train de réfléchir à la meilleure manière de mettre en route un système de bakup basé sur rdiff-backup [1] et un serveur qui tourne sous Jessie.

rdiff-backup fournit dans sa doc' un setup où le serveur initie les backups [2].

En deux mots, c'est un serveur qui "pulle" les clients à partir d'un cron.

Avantage :
- setup minimal sur les clients;
- centralisation des logs;

Désavantage :
- demande un serveur ssh sur tous les client;

Une autre option est de faire des pushes à partir des clients. Ce qu i me semble plus logique.

J'aimerai avoir votre avis : d'un pull ou d'un push depuis les clients ? Quel setup aurait votre préférence ?

Bonne soirée.

Jean-Marc


Tu peux regarder du côté de backupninja qui utilise, entre autre,
rdiff-backup pour faire des push depuis les clients. Globenet utilise à §a
depuis des années et on en est très satifaits.



--
"La science peut aussi s’employer à simplifier l’outil lage, à rendre
chacun capable de façonner son environnement immédiat, c’ est-à-dire
capable de se charger de sens en chargeant le monde de signes"
- Ivan Illich, La Convivialité(197 3)

--Kynn+LdAwU9N+JqL
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCgAGBQJXKQ8pAAoJEPtelkJAfN5Ea60P/jgEyKPFM7womhwyFAj8eN/w
3E23YSENxzF2275iPixs/NkOPcP2SspIVxciI2Fd6NUX0RZ4Js6AfnScOqjSYqWs
VOmhe9K+RKvpyjroZpUp07P9xWw7wJ42JZOeM3Lc5hKX0dPppX1V0DDNjS/Si/cW
O4eGg6gj6agdB/2Ek8AOdpIdmNhY9bcQZ1+C5ISM9TBL7s8n04YR9GHZMqDpFsT6
FE1j9RoZYGH2EWxz33jYV8F3aXRP2e4LEvatP1x8if90TXvMJbweduzJzHUIBvOE
kZjdFJaR0UFkXVC2ZvUaend1lq204D+DMtUjpJPdWdiN4dCK1fJHNUtEUVR0YA3p
hn2SfW0GcxMZIP9fxBqjargGBeoSfMqdpBJverQsPqDQJ+/30PCD8n5a7I217dfD
i0bPlMfhQqPqUYzO4KIvEPLlLOF+CLakNr6VDo+nwq9j0bhd4K0B9V755ZBNAg6C
UN81VZiwbozjkrfiLGammrpPL66kA1gMEh4WKTSeBrE8Jc+9z4q7cWKs0UkusCCA
W6lpmxhcXmWmm0bk5abOrGaLVoQKf0I1MdnPUWxR1usgYo4mv/lpcKVHR7PvQqpc
sMr3Fdyj5Adi37cyCMB5LWH/Q3E/waG6wW5Oxj5zBsuPBgJF1GH8s9MYsk5I+2Op
GlQfTPWRJwOKdpp9YyCJ
=Tk0A
-----END PGP SIGNATURE-----

--Kynn+LdAwU9N+JqL--
Gabriel Moreau
Le #26397308
Que nenni ! Le serveur de sauvegarde doit être le moins exposé possible
car il est précieux. Il est donc largement préférable que le serveur de
sauvegarde se connecte sur les serveurs à sauvegarder que le contraire.

Et pour durcir un peu la configuration sur les serveurs sauvegardés, il
faut faire en sorte que la clé utilisée ne soit acceptée que depuis l'IP
du serveur de sauvegarde, que les connexions interactives depuis
celui-ci soient interdites et que les commandes exécutables dans ce
contexte soient limitées via un petit script de filtrage.



100% d'accord. Je fonctionne ainsi.

gaby
--
Gabriel Moreau - IR CNRS http://www.legi.grenoble-inp.fr
LEGI (UMR 5519) Laboratoire des Ecoulements Geophysiques et Industriels
BP53, 38041 Grenoble Cedex, France
mailto: tel:+33.476.825.015
Jean-Marc
Le #26397340
--Signature=_Wed__4_May_2016_12_56_02_+0200_Jaz3jgCPoL9Ka1=5
Content-Type: text/plain; charset=UTF-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Tue, 3 May 2016 22:56:59 +0200
Sébastien Dinot
Que nenni ! Le serveur de sauvegarde doit être le moins expos é possible
car il est précieux. Il est donc largement préférable que le serveur de
sauvegarde se connecte sur les serveurs à sauvegarder que le contrai re.



OK, vendu !
Ce sera une config' Pull.


Et pour durcir un peu la configuration sur les serveurs sauvegardés, il
faut faire en sorte que la clé utilisée ne soit acceptée q ue depuis l'IP
du serveur de sauvegarde, que les connexions interactives depuis
celui-ci soient interdites et que les commandes exécutables dans ce
contexte soient limitées via un petit script de filtrage.



Un peu de détail avec ma compréhension de ce passage.
. connexion SSH restreinte à une connexion par clés uniquement;
. pas de connexion interactive = shell du user = /usr/sbin/nologin, voi re /bin/false;
. pour restreindre les commandes, il y a l'option 'command="..."' à insérer dans .ssh/authorized_keys;
. pour l'IP ou le nom du host, l'option from="..." de ce même fichie r;
. et on peut utiliser les options no-agent-forwarding et no-port-forwarding;

Dernier point, le paquet base-passwd [1] fournit un user backup (UID 34).
Est-ce un bon candidat ou dois-je créer mon propre user ?


Personnellement, j'utilise rdiff-backup ainsi pour sauvegarder depuis
des années une grosse vingtaine de serveurs et j'en suis pleinement
satisfait.



Merci pour l'info.


Sébastien




Jean-Marc
[1] https://packages.debian.org/jessie/base-passwd

--Signature=_Wed__4_May_2016_12_56_02_+0200_Jaz3jgCPoL9Ka1=5
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJXKdVCAAoJEEBxy1wt6cT8W/gQAK2vHwBZ3n32+vVypp5TU2rf
XPbCtH0NDUSaZ4zWUICwvv9el6i7s1g/1ARrGS7/P+Xu9QvVh42Z4agsT+Ez9P3W
ImpGqvXH3kXczJoFPnJREVqDHcU+jjo73AedTKmgvXAelLV64Vz75VuohdpSC8MN
545rC3hT7wmfAElfgnZ7BDMEMb/KTPTZ4o+B82dIyMXyb++18E+N38aNGLBA9Gpv
o2TBPtgnUSaMW2xRJI+D4TWESnZ4I4vRTpXJ6CNzni6AOJmBtHa49NlOijpmt3aQ
KbHtZANVkYOLrCpa6gTNMGV7JumpRFSskI1plAIRJBfWzLa9uI7xfWLVp5fs7Qoj
STA0tOMSmRGDE9gcvx0yhgwDfvlA59DXdXm7jyYIo6GBiTD6aBSzjTWH96tw5KFg
wYHfDs6M827zaU0Jd+ygBI8H/TR1tWamsh45iH+T0xAXPJG2RPxchsW2GrOqPg4K
o8xvDLUUgEkJck1BOnK91DNTKWv+bYGIY+j/6MqkwMYRUDYxQR+pSCfztsQClayh
Jcrc+C9bVTBzbwW8Aafr6LM6QazGQ5dtey7yW4OWjjRtf7WsBhkBVxGp3ncv/xfh
kzUalEgQIadfckp9IqrqvhHR7dpj2FYNgQz1nDvytptNiybE9/UJdP49zdUcPttr
4I82ulL+8Ko7hsiZi8kz
=5zoE
-----END PGP SIGNATURE-----

--Signature=_Wed__4_May_2016_12_56_02_+0200_Jaz3jgCPoL9Ka1=5--
Sébastien Dinot
Le #26397385
Jean-Marc a écrit :
Un peu de détail avec ma compréhension de ce passage.
. connexion SSH restreinte à une connexion par clés uniquement;



Oui.

. pas de connexion interactive = shell du user = /usr/sbin/nologin,
voire /bin/false;



Non. Dans le fichier /root/.ssh/authorized_keys, il faut indiquer sur la
ligne de la clé « no-pty » (pas de terminal donc pas de session
interactive).

Dans les faits, j'indique les restrictions suivantes :

------------------------------------------------------------------------
no-pty,no-port-forwarding,no-X11-forwarding,no-agent-forwarding
------------------------------------------------------------------------

cf. « man authorized_keys » pour les détails.

. pour restreindre les commandes, il y a l'option 'command="..."'
à insérer dans .ssh/authorized_keys;



Oui. Chez moi command="/root/.ssh/check-command.sh", script dont voici
le contenu :

------------------------------------------------------------------------
#!/bin/sh

PATH=/bin:/sbin:/usr/bin:/usr/sbin
LOGFILE=/var/log/remote-backup-commands.log

echo "[$(date '+%F %T')] '${SSH_ORIGINAL_COMMAND}'" >> $LOGFILE

if [ -z "${SSH_ORIGINAL_COMMAND}" ] ; then
echo "=> ERROR: Interactive session not allowed" | tee -a $LOGFILE
exit 1
fi

case "$SSH_ORIGINAL_COMMAND" in
/usr/bin/rdiff-backup *)
$SSH_ORIGINAL_COMMAND
echo "=> Done" >> $LOGFILE
;;
/root/bin/dump_databases.sh)
$SSH_ORIGINAL_COMMAND
echo "=> Done" >> $LOGFILE
;;
*)
echo "=> ERROR: Forbidden command" | tee -a $LOGFILE
;;
esac
------------------------------------------------------------------------

Le script /root/bin/dump_databases.sh, que mon script de sauvegarde
lance avant rdiff-backup effectue les opérations suivantes :

1. Génère une archive apt-clone contenant la liste des paquets installés
et les paquets non disponibles dans les dépôts Debian courants :

apt-clone clone --with-dpkg-repack /path/to/prefix

2. Dump des bases de données PostgreSQL, MySQL et LDAP


. pour l'IP ou le nom du host, l'option from="..." de ce même fichier;



Oui.

. et on peut utiliser les options no-agent-forwarding et
no-port-forwarding;



Oui.

Au final, la ligne correspondante dans le fichier /root/.ssh/authorized_keys ressemble à :

------------------------------------------------------------------------
from="1.2.3.4",no-pty,no-port-forwarding,no-X11-forwarding,no-agent-forwarding,command="/root/.ssh/check-command.sh" ssh-rsa AAAAB3NzaC1yc....
------------------------------------------------------------------------

Dernier point, le paquet base-passwd [1] fournit un user backup (UID 34).
Est-ce un bon candidat ou dois-je créer mon propre user ?



J'utilise le compte root. Je sais, c'est mal mais cela me simplifie la
tâche sachant que je n'autorise que les connexions par clés SSH et que
je blinde particulièrement cet accès octroyé au serveur de sauvegarde
qui est lui-même aussi durci que je le peux.

Sébastien


--
Sébastien Dinot,
http://sebastien.dinot.free.fr/
Ne goûtez pas au logiciel libre, vous ne pourriez plus vous en passer !
Vincent Danjean
Le #26397765
Le 04/05/2016 11:24, Gabriel Moreau a écrit :

Que nenni ! Le serveur de sauvegarde doit être le moins exposé possible
car il est précieux. Il est donc largement préférable que le serveur de
sauvegarde se connecte sur les serveurs à sauvegarder que le contraire.

Et pour durcir un peu la configuration sur les serveurs sauvegardés, il
faut faire en sorte que la clé utilisée ne soit acceptée que depuis l'IP
du serveur de sauvegarde, que les connexions interactives depuis
celui-ci soient interdites et que les commandes exécutables dans ce
contexte soient limitées via un petit script de filtrage.



100% d'accord. Je fonctionne ainsi.



Pareil, mais avec backuppc. Et comme j'ai plusieurs machines, avec des
serveur backuppc différents, j'ai fait des paquets debian pour
automatiser l'installation sur les clients, comme celui-ci :
http://moais.imag.fr/membres/vincent.danjean/debian/pool/main/v/vdanjean-backuppc/

ATTENTION : seul le paquet *source* peut être intéressant. Si
quelqu'un installe mon paquet binaire (ie sans changer la clé
publique), il m'autorise à backupper tout son système...

J'ai aussi un script + quelques indications pour mettre en place
la même chose sur MacOS X.

A+
Vincent

--
Vincent Danjean GPG key ID 0xD17897FA
GPG key fingerprint: 621E 3509 654D D77C 43F5 CA4A F6AE F2AF D178 97FA
Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo: deb http://people.debian.org/~vdanjean/debian unstable main

--
Vincent Danjean GPG key ID 0xD17897FA
GPG key fingerprint: 621E 3509 654D D77C 43F5 CA4A F6AE F2AF D178 97FA
Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo: deb http://people.debian.org/~vdanjean/debian unstable main
Daniel Caillibaud
Le #26398097
Le 05/05/16 à 01:15, Sébastien Dinot
SD> J'utilise le compte root. Je sais, c'est mal mais cela me simplifie la
SD> tâche sachant que je n'autorise que les connexions par clés S SH et que
SD> je blinde particulièrement cet accès octroyé au serveur de sauvegarde
SD> qui est lui-même aussi durci que je le peux.

C'est pas forcément mal, ça dépend de ce que tu veux faire.

Si c'est pour tout backuper (clés privées de la machine comprises par ex), c'est indispensable
(ou un user ayant autant de droits que root, donc ça revient au mà ªme).

Si c'est pour backup de data, un user dédié est plus fiable (on e st sûr qu'il aura pas accès à
certaines données sensibles qu'on ne veut pas voir dans ce backup "cou rant", comme des clés
privées).

--
Daniel

Plus les galets ont roulés, plus ils sont polis.
Pour les cochers, c'est le contraire.
Alphonse Allais
Publicité
Poster une réponse
Anonyme