
Dans un premier temps, j’étais parti sur l’idée de mettre en place un cluster proxmox à deux noeuds non situé sur le même réseau. Cette démarche nécessitait la mise en place d’un pont VPN over internet entre les deux serveurs. Voyant à la lecture des différents articles et blog que ce type de cluster représentait un intérêt limité, j’ai juste gardé l’idée du VPN pour simplement monter un disque distant à travers ce VPN.
Architecture
On réalise l’architecture suivante (cf image ci-dessous) :
- un serveur proxmox auto-hébergé sur Tours, on le nomme proxmox37,
- un serveur proxmox hébergé chez online, nommé proxmox-dbox,
- proxmox37 est "planqué" derrière un parefeu ipfire (déclaré en DMZ sur le modem/routeur fibre) qui gère les règles de NAT
- un disque dur du serveur proxmox37 est déclaré en tant que "directory" et sert déjà pour les sauvegardes de ce cluster.
Le but est de monter ce disque qui héberge déjà les sauvegardes du proxmox37 sur le proxmox-dbox hébergé chez online. On va le monter en utilisant sshfs au travers d’un tunnel VPN que l’on va établir entre les deux serveurs proxmox en traversant les différents éléments de l’architecture réseau.
Mise en place du VPN
- Configuration de l’interface réseau virtuelle
- Utilisation du module dummy :
echo "options dummy numdummies=2" > /etc/modprobe.d/dummy.conf
Cela indique que si le noyau charge le module « dummy » (qui est une interface réseau virtuelle), et bien qu’il pense à en préparer au moins 2 : dummy0 et dummy1. - Chargement du module :
modprobe dummy - Vérification :
ifconfig -a | grep Link | grep -v inet6
renvoit par exemple :dummy0 Link encap:Ethernet HWaddr xx:xx:xx:xx:xx:xx dummy1 Link encap:Ethernet HWaddr xx:xx:xx:xx:xx:xx eth0 Link encap:Ethernet HWaddr xx:xx:xx:xx:xx:xx lo Link encap:Local Loopback vmbr0 Link encap:Ethernet HWaddr xx:xx:xx:xx:xx:xxEffectuer la configuration de manière identique sur proxmox37 et proxmox-dbox.
- Configuration réseau des serveurs proxmox,
- çà se passe au niveau du fichier /etc/network/interfaces , on ajoute :
auto openvpnbr0 iface openvpnbr0 inet static address 10.0.X.1 netmask 255.255.255.0 network 10.0.X.0 broadcast 10.0.X.255 bridge_ports dummy1 bridge_stp off bridge_fd 0 post-up route add -net 224.0.0.0 netmask 240.0.0.0 dev openvpnbr0La plage IP 10.X.X.X est à personnaliser selon votre envie, du moment qu’il est non routable
On va utiliser deux adresses ( item adress de la ligne 3) différentes pour chaque serveur : 10.0.X.1 pour proxmox37 et 10.0.X.2 pour proxmox-dbox. - Redémarrage du réseau :
/etc/init.d/network restart[1] - Vérification :
ifconfig openvpnbr0openvpnbr0 Link encap:Ethernet HWaddr 4e:bf:af:79:58:a3 inet addr:10.0.X.1 Bcast:10.0.X.255 Mask:255.255.255.0 inet6 addr: fe80::4cbf:afff:fe79:58a3/64 Scope:Link UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1 RX packets:17253551 errors:0 dropped:0 overruns:0 frame:0 TX packets:6858072 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:7431487763 (0.0 B) TX bytes:25175328547 (23.4 B) - Vérification que l’interface réponde en local :
ping 10.0.X.1
Doit renvoyer ceci, sinon y a un soucis :PING 10.0.X.1 (10.0.X.1) 56(84) bytes of data. 64 bytes from 10.0.X.1: icmp_req=1 ttl=64 time=0.242 ms 64 bytes from 10.0.X.1: icmp_req=2 ttl=64 time=0.137 ms
- çà se passe au niveau du fichier /etc/network/interfaces , on ajoute :
- Utilisation du module dummy :
- Configuration de Proxmox sur l’interface virtuelle
- SSH : on va limiter les clients potentiels pour l’accès en ssh sur le proxmox-dbox.
- Dans le fichier /etc/ssh/sshd_config on va activer/modifier les lignes suivantes :
ListenAddress xxx.xxx.xxx.xxx:2222 ListenAddress 10.0.X.1:22La première directive « ListenAddress » (en remplaçant les xxx) de manière à ce que ssh écoute sur l’ip « publique » du serveur et choisisez un port non standard (ici le port 2222).
- on redémarre le service
/etc/init.d/ssh restart
-** /etc/hosts : - votre fichier doit ressemble à çà sur proxmox37 :
127.0.0.1 localhost.localdomain localhost 192.168.X.Y pve37.cen-centrevaldeloire.org pve37 pvelocalhost - on va modifier la deuxième ligne (ou ajouter) :
10.10.37.1 pve37.cen-centrevaldeloire.org pve37 pvelocalhost - sur proxmox-dbox on met :
10.0.X.2 sd-99999.dedibox.fr dbox-cencvl
- Dans le fichier /etc/ssh/sshd_config on va activer/modifier les lignes suivantes :
- SSH : on va limiter les clients potentiels pour l’accès en ssh sur le proxmox-dbox.
A ce stade, un petit redémarrage de chaque noeud peut être utile.
- Installation de OpenVPN (serveur primaire)
- Sur chacun des serveurs qui sont des distributions debian :
apt-get install openvpn - Préparation des certificats.
- on se positionne sur le serveur proxmox37 qui dans la liaison VPN fera office de serveur. On installe easy-rsa :
apt-get install easy-rsa - on copie les fichiers de conf d’easy-rsa et on se positionne :
cp -R /usr/share/easy-rsa/ /etc/openvpn/easy-rsa cd /etc/openvpn/easy-rsa/ cp vars vars.dist - on modifie les 8 dernières lignes du fichier vars comme par exemple :
export KEY_COUNTRY="FR" export KEY_PROVINCE="Centre" export KEY_CITY="Tours" export KEY_ORG="Cen cvl" export KEY_EMAIL="email@cen-cvl.org" export KEY_OU="37" - génération des certificats, envoyer tour à tour les commandes suivantes qui vous renverront plein d’infos :
source ./vars ./clean-all ./build-dh ./pkitool --initca - Génération de la clé serveur, on envoie les commandes, la valeur ’promox-server’ est paramétrable à votre guise :
./pkitool --server proxmox-server openvpn --genkey --secret ./keys/ta.key - Génération de la clé cliente ;
./pkitool proxmox-client-1 - Sauvegarde des clés, on va créer des paquets prêt à "transporter" :
cd /etc/openvpn/easy-rsa/keys/ tar cvzf /root/proxmox-server-keys.tar.gz proxmox-server.crt proxmox-server.key ca.crt dh2048.pem ta.key tar cvzf /root/proxmox-client-1-keys.tar.gz proxmox-client-1.crt proxmox-client-1.key ca.crt ta.keyConservez précieusement vos clés car sans elles, vous ne pourrez pas faire grand chose.
- on se positionne sur le serveur proxmox37 qui dans la liaison VPN fera office de serveur. On installe easy-rsa :
- Sur chacun des serveurs qui sont des distributions debian :
- Configuration du serveur OpenVPN (serveur primaire)
- Mise en place fichier server.conf :
cd /etc/openvpn/ zcat /usr/share/doc/openvpn/examples/sample-config-files/server.conf.gz > server.conf - Edition du fichier server.conf qui doit ressemble à çà :
local xxx.xxx.xxx.xxx port yyyy proto udp dev tap0 ca ca.crt cert proxmox-server.crt key proxmox-server.key # This file should be kept secret dh dh2048.pem server-bridge 10.0.X.1 255.255.255.0 10.0.X.101 10.0.X.110 client-to-client duplicate-cn keepalive 10 120 tls-auth ta.key 0 # This file is secret comp-lzo max-clients 10 user nobody group nogroup persist-key persist-tun status openvpn-status.log log-append openvpn.log verb 3 mode server tls-server script-security 2 up "/etc/openvpn/up.sh" down "/etc/openvpn/down.sh" mssfix 1300 fragment 1300 - Les paramètres à ajuster sont :
- local : détermine sur quelle adresse IP « publique » le serveur OpenVPN doit écouter
Note : notre serveur proxmox37 est dans notre réseau local alors il faudra configurer du NAT sur le parefeu ipfire afin de pouvoir le joindre depuis l’extérieur, - port : par défaut OpenVPN écoute sur le port 1194 mais le changer n’est pas un luxe afin d’éviter les scans
- cert & key : précisez les fichiers qui correspondent au serveur que vous configurez (ici proxmox-server.crt et proxmox-server.key)
- server-bridge : le premier paramètre détermine l’adresse IP du serveur sur l’interface virtuelle que nous avons déclarée précédemment. (10.0.X.1), ensuite vient le masque de réseau (255.255.255.0) puis, à la manière d’un serveur DHCP, la plage d’adresses IP attribuée aux clients qui se connecteront sur ce serveur (de 10.0.X.101 à 10.0.X.110)
- local : détermine sur quelle adresse IP « publique » le serveur OpenVPN doit écouter
- Scritps up.sh et down.sh : ce sont les deux scripts qui seront lancés par OpenVPN lors du démarrage ou de l’extinction du VPN (attention, depuis debian 9 stretch, penser à installer le paquet net-tools sinon pas de "ifconfig" !)
- /etc/openvpn/up.sh
#!/bin/bash /sbin/ifconfig openvpnbr0 promisc /sbin/ifconfig tap0 up promisc /sbin/brctl addif openvpnbr0 tap0 - /etc/openvpn/down.sh
#!/bin/bash /sbin/brctl delif openvpnbr0 tap0 /sbin/ifconfig tap0 down -promisc /sbin/ifconfig openvpnbr0 -promisc - ne pas oublier de rendre les scripts executables :
chmod 0755 up.sh down.sh
- /etc/openvpn/up.sh
- Ajout des clés serveurs :
cd /etc/openvpn tar xvzf /root/proxmox-server-keys.tar.gz - Lancement du serveur openVPN :
/etc/init.d/openvpn restart - On vérifie les logs dans /etc/openvpn/openvpn.log qui devrait ressemble à çà
OpenVPN 2.1.3 x86_64-pc-linux-gnu [SSL] [LZO2] [EPOLL] [PKCS11] [MH] [PF_INET6] [eurephia] built on Oct 22 2010 NOTE: when bridging your LAN adapter with the TAP adapter, note that the new bridge adapter will often take on its own IP NOTE: the current --script-security setting may allow this configuration to call user-defined scripts Diffie-Hellman initialized with 2048 bit key /usr/bin/openssl-vulnkey -q -b 1024 -m <modulus omitted> Control Channel Authentication: using 'ta.key' as a OpenVPN static key file Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication TLS-Auth MTU parms [ L:1574 D:166 EF:66 EB:0 ET:0 EL:0 ] Socket Buffers: R=[133120->131072] S=[133120->131072] TUN/TAP device tap0 opened TUN/TAP TX queue length set to 100 /etc/openvpn/up.sh tap0 1500 1574 init Data Channel MTU parms [ L:1574 D:1300 EF:42 EB:135 ET:32 EL:0 AF:3/1 ] GID set to nogroup UID set to nobody UDPv4 link local (bound): [AF_INET]xxx.xxx.xxx.xxx:yyyy UDPv4 link remote: [undef] MULTI: multi_init called, r=256 v=256 IFCONFIG POOL: base=10.0.X.101 size=10 Initialization Sequence Completed
- Mise en place fichier server.conf :
- Configuration du client OpenVPN (serveur secondaire)
- Mise en place fichier client.conf
- copie du template :
cd /etc/openvpn/ cp -av /usr/share/doc/openvpn/examples/sample-config-files/client.conf - On édite le fichier « client.conf » qui, une fois tous les commentaires enlevés, doit ressembler à ça :
client dev tap1 proto udp remote xxx.xxx.xxx.xxx yyyy resolv-retry infinite nobind user nobody group nogroup persist-key persist-tun ca ca.crt cert proxmox-client-1.crt key proxmox-client-1.key ns-cert-type server tls-auth ta.key 1 comp-lzo verb 3 log-append openvpn.log script-security 2 up "/etc/openvpn/up-client.sh" down "/etc/openvpn/down-client.sh" mssfix 1300 fragment 1300 - Paramètreq à ajuster
- dev tapX : c’est l’interface que crééra openvpn pour sa connexion. Il est important de ne pas mettre tap0, qui est déjà utilisé pour le serveur VPN sur le serveur,
- "remote" : préciser l’adresse IP publique du serveur primaire (proxmox37) ainsi que le port sur lequel se connecter. Note : notre client proxmox est directement ouvert sur le web, donc pas de NAT à mettre en place de ce côté, uniquement du côté du parefeu ipfire de Tours,
- up et down : modifier le nom du script
- copie du template :
- Certificats et scripts, depuis le serveur proxmox37 :
scp -P 2222 /root/proxmox-client-1-keys.tar.gz xxx.xxx.xxx.xxx:/root/ scp -P 2222 /etc/openvpn/up.sh /etc/openvpn/down.sh xxx.xxx.xxx.xxx:/etc/openvpn/ - Modification des scripts de lancement et d’arret d’openvpn côté client :
- renommage :
cd /etc/openvpn mv up.sh upclient.sh mv down.sh downclient.sh - modification de l’interface : éditer les deux fichiers et remplacer systématiquement tap0 par tap1
- renommage :
- lancement du client openvpn
/etc/init.d/openvpn restart - les logs dans /etc/openvpn/openvpn.log devait ressembler à çà :
OpenVPN 2.1.3 x86_64-pc-linux-gnu [SSL] [LZO2] [EPOLL] [PKCS11] [MH] [PF_INET6] [eurephia] built on Oct 22 2010 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts /usr/bin/openssl-vulnkey -q -b 1024 -m <modulus omitted> Control Channel Authentication: using 'ta.key' as a OpenVPN static key file Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication LZO compression initialized Control Channel MTU parms [ L:1578 D:166 EF:66 EB:0 ET:0 EL:0 ] Socket Buffers: R=[133120->131072] S=[133120->131072] Data Channel MTU parms [ L:1578 D:1300 EF:46 EB:135 ET:32 EL:0 AF:3/1 ] Fragmentation MTU parms [ L:1578 D:1300 EF:45 EB:135 ET:33 EL:0 AF:3/1 ] Local Options hash (VER=V4): 'a257ef04' Expected Remote Options hash (VER=V4): '8f3da10b' NOTE: UID/GID downgrade will be delayed because of --client, --pull, or --up-delay UDPv4 link local: [undef] UDPv4 link remote: [AF_INET]xxx.xxx.xxx.xxx:yyyy TLS: Initial packet from [AF_INET]xxx.xxx.xxx.xxx:yyyy, sid=1c88df43 a5baa0cd VERIFY OK: depth=1, /C=FR/O=Mon organisation/CN=Mon organisation_CA/emailAddress=mon-email@mon-domaine.tld VERIFY OK: nsCertType=SERVER VERIFY OK: depth=0, /C=FR/O=Mon organisation/CN=proxmox-server/emailAddress=mon-email@mon-domaine.tld Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA [proxmox-server-1] Peer Connection Initiated with [AF_INET]xxx.xxx.xxx.xxx:yyyy SENT CONTROL [proxmox-server-1]: 'PUSH_REQUEST' (status=1) PUSH: Received control message: 'PUSH_REPLY,route-gateway 10.0.X.1,ping 10,ping-restart 120,ifconfig 10.0.X.101 OPTIONS IMPORT: timers and/or timeouts modified OPTIONS IMPORT: --ifconfig/up options modified OPTIONS IMPORT: route-related options modified TUN/TAP device tap0 opened TUN/TAP TX queue length set to 100 /sbin/ifconfig tap1 10.0.X.101 netmask 255.255.255.0 mtu 1500 broadcast 10.0.X.255 /etc/openvpn/up.sh tap1 1500 1578 10.0.X.101 255.255.255.0 init GID set to nogroup UID set to nobody Initialization Sequence Completed
- Mise en place fichier client.conf
- verification :
- depuis proxmox37 tester :
ping 10.0.X.2 - depuis proxmox-dbox tester :
ping 10.0.X.1
- depuis proxmox37 tester :
Sources :
Blog développeur neurasthénique
Blog de Victor Héry
Montage SSHFS
On part sur l’hypothèse que vous avez sur le serveur proxmox37 un disque monté en tant que répertoire. Pour le comment aller voir l’article de mise en place de proxmox, chapitre "Ajout d’un répertoire de sauvegarde sur un disque seul". Pour la suite de cet article, on considérera que ce volume est monté sur /mnt/backup.
Création d’un compte utilisateur spécifique : utiliser le compte root pour faire un montage sshfs n’est pas des plus prudents, aussi on va utiliser un compte utilisateur courant.
- sur le proxmox37 :
useradd -m monuser passwd monuser - on vérifie ses droits sur le dossier /mnt/backup, on peut même le rendre propriétaire du dossier :
chown -cvf cenc /mnt/backup - on va repérer pour la suite des opérations son UID :
cat /etc/passwd | grep cenc
monuser:x:1000:1000::/home/cenc:/bin/bash - le UID vaut 1000 ici (premier chiffre)
Passage sur le proxmox-dbox pour la suite.
- installation de sshfs sur le client
apt-get install sshfs - La aussi on va créer un compte utilisateur qui aura le même uid que sur le proxmox37
useradd -u 1000 -m monuser passwd monuser - Création du point de montage, définition du propriétaire et des droits :
mkdir /mnt/pve37backup chown -cRvf monuser /mnt/pve37backup chmod 775 /mnt/pve37backup/ - A ce stade on pourrait monter le disque, le soucis c’est que la commande de montage va nous demander le mot de passe de l’utilisateur, ce qui ne permet pas une automatisation du montage. Pour éviter cela, on va créer une paire de clé.
- En tant que root on lance :
ssh-keygenroot@proxmox-dbox:~# ssh-keygen Generating public/private rsa key pair. Enter file in which to save the key (/root/.ssh/id_rsa): <-- ENTER Enter passphrase (empty for no passphrase): <-- ENTER Enter same passphrase again: <-- ENTER Your identification has been saved in /root/.ssh/id_rsa. Your public key has been saved in /root/.ssh/id_rsa.pub. The key fingerprint is: b4:22:48:21:99:72:65:3e:1d:93:6f:9a:5c:5f:70:61 root@server1.example.com The key's randomart image is: +--[ RSA 2048]----+ |.o..o o. E. | |+..+ ..o ... | |... o ... o | | . . . .+. . | | . ...=S. . | | .+. . | | | | | | | +-----------------+ root@proxmox-dbox:~#Il est très important de ne pas entre de "passphrase" sinon le montage nécessitera une intervention humaine.
- ensuite on copy la clé sur le serveur proxmox37
ssh-copy-id -i /root/.ssh/id_dsa.pub monuser@10.0.X.1 - on vérifie sur proxmox37 que la clé est bien copiée :
cat $HOME/.ssh/authorized_keysssh-dss AAAAB3NzaC1kc3MAAACBAKqZRaiUXKRUhAECASfudNNdt6gcjer6eCzYCTO9lBwB83ZLY9h9kvUKDWX9vUEy121kMLsbMQUa13kh93meAAKNmVaBdWqVPsc/+E3GGE+oWtx5QzqaLCTuonE/IUJNFhr8FuFeBIDkZJ97bWD2tc+y8Fzr21lLXB2zqj7BwLK6kIAAACAVpZ/OOMDDpI+x4riz71zGHoTy2N/O+Qifp/EPUAGM1ZVehUuUVne0jfysjh/KpxCTo8IMNn65WGy/1xQrA2G/+JaizmBSKSoKwD7bWTcnpqqZCoVT85mWOjQPzPmOZhwEPOAfkMjnLxAxNk3gbdbAGI3KumGmqBfha+Fw1JdKCk= root@promox-dbox
- on peut faire un essai de montage manuel depuis proxomox-dbox pour vérifier que la clé marche bien sans demande de mot de passe :
sshfs -o idmap=user monuser@10.0.X.1 :/mnt/backup mnt/pve37backup
- En tant que root on lance :
- Rendre le montage automatique au boot
- La première solution consiste à utiliser /etc/fstab en ajoutant la ligne suivante :
sshfs#cenc@10.0.X.1:/mnt/backup /mnt/pve37backup fuse reconnect,_netdev,user,noatime,allow_other,uid=1000,gid=1000 0 0
Mais, malgré les différents paramétrage possible comme le "delay_connect" qu’on pourrait ajouter, il y a de grands risques que le montage ne se fasse pas car le réseau n’est pas encore lancé au moment du déclenchement des montages disques. D’où une deuxième solution. - Deuxième solution : lancer le montage avec le service /etc/rc.local qui est le dernier lancé. Il faut éditer le fichier /etc/rc.local et ajouter (avant la ligne "exit 0") :
/usr/bin/sshfs -o idmap=user monuser@10.0.X.1:/mnt/backup mnt/pve37backup - On vérifie que le montage est bien effectué :
mountmonuser@10.0.X.1 :/mnt/backup on /mnt/pve37backup type fuse.sshfs (rw,nosuid,nodev,noexec,noatime,user_id=0,group_id=0,allow_other)
- La première solution consiste à utiliser /etc/fstab en ajoutant la ligne suivante :
- Maintenant que notre disque est monté, il faut le rendre accessible dans proxmox pour les sauvegardes. On utilise l’interface web du proxmox-dbox :
- Datacenter->Stockage
- Dans la liste déroulante "ajouter" on choisit directory
Proxmox répertoire backup sshfsLudovic Lestrat - on donne un nom à l’ID, par exemple pve37bakcup
- on indique le chemin du point de montage sshfs : /mnt/pve37backup
- on choisit comme contenu "Fichiers de sauvegarde"
- on définit le nombre de sauvegardes max à conserver.
Problème rencontré :
La déclaration du répertoire de montage /mnt/pve37backup comme espace de stockage entraîne la création, s’il n’existe pas, d’un répertoire "dump". Dans la mise en place indiqué dans cet article, tout se passe bien et vu que le répertoire distant que l’on monte est déclaré sur un autre noeud proxmox comme répertoire de sauvegarde, le répertoire dump existe déjà et du coup on a accès aux sauvegardes de l’autre serveur proxmox (cf partie suivante "espace sauvegarde dans proxmox").
Mais que se passe-t-il quand on redémarre ?
- proxmox déclare le répertoire /mn/pve37backup comme "repertoire" de sauvegarde de proxmox et crée un dossier dump,
- comme le montage sshfs n’est pas encore en place (car il est dépendant du réseau), on se retrouve avec un dossier dump vide sur le point de montage /mnt/pve37backup
- le système échoue à monter le dossier distant car le dossier de montage /mnt/pve37backup n’est pas vide.
Solution actuelle
Après un redémarrage du serveur proxmox-dbox, il faut :
- aller supprimer la déclaration du répertoire "pve37backup" dans l’interface proxmox,
- supprimer le dossier "dump" :
rmdir /mnt/pve37backup/dump - remonter le disque reseau :
mount /mnt/pve37backup - re-déclarer le "repertoire" proxmox comme indiqué dans cet article ci-avant.
Solution à rechercher
Trouver si l’on peut changer l’ordre des services de façon à éviter ce problème.
Sinon, trouver comment scripter en shell la solution actuelle et l’executer dans /etc/rc.local
Logiquement un tel serveur n’est pas redémarré tous les jours. Ca peut poser problème surtout s’il y a une panne matériel et que l’administrateur ne fait pas le nécessaire juste après le redémarrage.
Sources :
HowtoForge
Ubuntu doc fr
Admin linux
Espace sauvegarde dans Proxmox
Avec cette configuration en place, sur le proxmox-dbox on voit et on accède à la fois au sauvegarde de ce noeud, mais aussi à celle du proxmox37. Du coup on peut :
- préparer des VM et CT sur le proxmox37 auto-hébergé, les sauvegarder puis les restaurer sur proxmox-dbox sur un nouvel vmid, le tout via l’interface graphique,
- sauvegarder les CT et VM de proxmox-dbox sur le serveur de Tours, se mettant à l’abri d’un éventuel dommage du data-center.
Ajout d’un espace de sauvegarde sur serveur FTP hébergeur
Pour compléter cette configuration, on peut aussi ajouter un autre espace de sauvegarde sur le proxmox-dbox en utilisant l’espace FTP compris dans le service d’hébergement comme espace de stockage. Pour cela, on utilise curlftps.
- Installation du paquet
apt-get install curlftpfs - création d’un point de montage
mkdir /mnt/ftpback - ajout d’une ligne dans /etc/fstab
curlftpfs#sd-XXXXX:mdp@dedibackup-dc3.online.net /mnt/ftpback fuse auto,rw,user,allow_other,uid=1000,_netdev,umask=0 0 0- "sd-XXX:mdp" est l’identifiant et le mot de passe fourni par l’hévergeur pour accéder à vore espace FTP
- "dedibackup-dc3.online.net" est le nom du serveur ftp de l’hébergeur
- /mnt/ftpback : le point de montage créé préalablement
- il sera monté au prochain démarrage, mais on peut déjà le faire à la main :
mount /mnt/ftpback - Il ne reste plus qu’à déclarer dans proxmox un "répertoire" de sauvegarde comme on l’a fait précédemment pour le montage sshfs.
[1] Il se peut que le redémarrage du service réseau ne suffise pas et que vous soyez obligé de redémarré tout le serveur