ovz-db-1

    Better late than sorry: la release stable est disponible

    Pour me contacter, consultez le fichier README

    Release :

    • Name : openvz-diff-backups
    • Licence : GPLv3
    • Branch : stable
    • Version : 1.0.2.8 (2023-07-01)

    Systèmes supportés :

    • OpenVZ (Legacy / 7)
    • Virtuozzo (6 / 7)
    • Proxmox (2 / 3)

    Logiciels requis :

    • bash
    • openssh (client)
    • rsync
    • bc
    • bzip2 (ou mieux : pbzip2)
    • dig

    Debian :

    apt-get install openssh-client rsync bc bzip2 dnsutils pbzip2

    CentOS :

    yum install openssh-clients rsync bc bzip2 bind-utils

    Installation :

    1. Téléchargez la dernière version stable : openvz-diff-backups_v1.0.2.8-stable.tar.gz
    2. Vérifiez son intégrité (sha256) : openvz-diff-backups_v1.0.2.8-stable.sha256.txt
    3. Décompressez l’archive dans le dossier : /usr/local/sbin/openvz-diff-backups-stable/
    4. Créez un lien symbolique : ln -s /usr/local/sbin/openvz-diff-backups-stable/openvz-diff-backups /usr/local/sbin/
    5. Fin de l’histoire, c’est prêt.

    Mise à jour

    Autant de fois que nécessaire, lancez la commande :

    openvz-diff-backups update all auto

    Dès que vous voyez apparaître le message suivant, c’est terminé.

    Your release is up to date. Yay!

    Description rapide

    openvz-diff-backups est un outil hybride permettant d’effectuer des sauvegardes incrémentales et/ou complètes pour chaque container OpenVZ (les formats simfs et ploop sont supportés).

    Toutes les opérations/transferts nécessitent SSH donc le stockage des sauvegardes est soit local (ex : localhost, même serveur**), soit distant (ex : mon-serveur-de-backups.fr ou l’adresse IPV[4|6] de la destination).

    La destination pouvant être un serveur dédié, un NAS sous Linux, un VPS sous OpenVZ, un VPS sous KVM, etc.

    ** Certains « trichent » en utilisant un montage externe (NFS, SSHFS ou autre) directement sur le serveur hôte mais ce genre de pratique est déconseillée (sauf si les IOPS du montage externe sont acceptables/bons/excellents).

    Sauf cas particulier, le support de destination nécessite un système Linux/Unix, un shell (bash, sh, ash, autre), rsync et un serveur compatible SSH pour accepter les connexions entrantes.

    Fonctionnalités (version courte)

    openvz-diff-backups permet de :

    • sauvegarder un/plusieurs/tous les containers OpenVZ
    • supprimer les anciennes sauvegardes selon leurs dates
    • répliquer les sauvegardes (push ou pull)
    • restaurer/cloner/migrer les containers d’un serveur à un autre

    Trois modes de sauvegardes sont disponibles :

    • cold : sauvegarde à froid (si le container est actif, il sera éteint puis redémarré)
    • hold : sauvegarde à chaud (ne sauvegarde que les données du container, comme vzdump)
    • live : sauvegarde à chaud (les données ainsi que l’intégralité de la RAM du container sont sauvegardés)

    Les sauvegardes live sont fortement recommandées car lors d’une restauration, le container OpenVZ reprendra son activité avec l’état complet de ses processus ainsi que la mémoire qui lui était allouée.

    Note : lors de migration vers des systèmes hôtes différents (ex : Proxmox / Virtuozzo 6 / OpenVZ Legacy vers OpenVZ 7), cela ne fonctionnera pas car le format de stockage de la RAM des containers n’est pas compatible (OpenVZ vs CRIU).

    Dans ce cas, et d’une manière générale pour toute migration impliquant des plates-formes totalement différentes, utilisez des sauvegardes à froid.

    Performances (première sauvegarde)

    Note : par défaut, openvz-diff-backups bride les transferts SSH à 100 Mbit/s (soit 12.5 Mo/seconde) mais cette limite est configurable.

    La première sauvegarde (full backup) d’un container OpenVZ nécessite le transfert complet des données, ce qui peut être long.

    Exemple : un container de 100 Go nécessitera environ 3 heures de traitement (soyons large), à raison d’un transfert de 12.5 Mo/seconde, pour être sauvegardé initialement.

    Note : l’option « turbo » (oui, je sais, le nom est totalement calamiteux…) permet d’exploiter la connexion SSH à sa vitesse maximale, idem pour les transferts vers les systèmes de fichiers.

    En résumé, la vitesse de la première sauvegarde dépendra des performances de la connexion SSH et des systèmes de stockage utilisés : HDD, SSD, NFS, Ceph, autre (que ce soit pour le serveur hôte ou pour le support de destination).

    Performances (sauvegardes suivantes)

    Les sauvegardes ultérieures (incremental backup) transféreront uniquement le delta des données modifiées.

    C’est à ce moment précis qu’openvz-diff-backups devient réellement intéressant.

    En usage quotidien (ex : des sauvegardes une fois, deux fois, quatre fois par jour), les performances dépendront principalement des IOPS nécessaires pour scanner les inodes des fichiers contenus dans chaque container OpenVZ.

    Autrement dit, et sauf cas particuliers, le débit de la connexion SSH n’est plus le facteur déterminant, d’où la limitation par défaut des transferts à 100 Mbit/s.

    Performances (cas d’exemple)

    A titre indicatif, sauvegarder ~1 To de données éparpillées dans ~50 containers OpenVZ nécessite entre 90 et 120 minutes.

    Note : Ce délai peut fortement varier suivant la nature des containers OpenVZ (simfs / simfs + LVM2 / ploop), de leurs données et de la puissance des serveurs de backups utilisés (CPU/RAM/DISK).

    Stockage requis (première sauvegarde)

    « Simple, basique » : l’espace nécessaire requis sera égal à la taille du container OpenVZ à sauvegarder.

    Stockage requis (sauvegardes suivantes)

    Les sauvegardes étant incrémentales, un container OpenVZ qui n’est que peu/pas/plus modifié (idle, éteint ou suspendu) consommera un espace de stockage quasi nul.

    A l’inverse, un container OpenVZ dont les donnés sont régulièrement et fortement modifiées chaque jour nécessitera un espace disque conséquent à chaque nouvelle sauvegarde.

    Il est donc assez difficile de prévoir à l’avance l’espace disque requis pour stocker toutes les sauvegardes.

    Stockage requis (cas d’exemple)

    Toujours à titre indicatif, sauvegarder ~1 To de données utiles deux fois par jour avec un historique de 7 jours (plus les sauvegardes hebdomadaires et mensuelles) nécessite aux alentours de ~1.5 To.

    En cas de doute et si vous voulez prévoir large : identifiez la taille des données utiles à sauvegarder et multipliez par deux.

    Réplication des sauvegardes

    Afin de redonder les backups, il est nécessaire/pertinent/préférable de transférer les différentes sauvegardes vers une seconde/tierce destination.

    openvz-diff-backups propose deux modes de réplication :

    • push : upload des backups vers une destination tierce (serveur dédié/VPS/NAS/etc)
    • pull : download des backups depuis une destination tierce (locale ou distante, peu importe)

    Note : pour l’instant, le mode « pull » (comme le mode « push ») nécessite le droit d’écriture sur le système source (création d’un répertoire « lock » afin de poser un verrou exclusif).

    Il s’agit d’une sérieuse limitation empêchant d’utiliser un accès SSH read-only en mode « pull » : si vous avez des idées pour corriger le souci, je suis preneur…

    Restauration des containers (version courte)

    Les sauvegardes cold ont la meilleure portabilité, surtout si le système de destination est fortement différent du système source (ex : Proxmox 2/3 vers OpenVZ 7).

    Les sauvegardes hold sont, de mon point de vue, à proscrire : la mémoire des containers OpenVZ n’est pas restaurée, ce qui peut vraiment être problématique (ex : MySQL/PostgreSQL/autre).

    Les sauvegardes live sont idéales car elle permettent de « ressusciter » un container OpenVZ à l’instant T de sa sauvegarde (système de fichiers et état complet des processus et de la mémoire utilisée).

    Pour faire court, si vous souhaitez restaurer des containers OpenVZ sur le même serveur ou sur une machine équivalente (CPU/RAM), utilisez en priorité les sauvegardes « live » : l’état du container sera entièrement restauré**.

    ** Ou comment obtenir un « uptime » de 100% pour tous vos container OpenVZ, même en cas de reboot/panne/incident/migration… (Les logs des containers OpenVZ vont cependant vous trahir !)

    Le mot de la fin (pour l’instant)

    Si vous avez des questions, je suis disponible donc n’hésitez pas !