Réplication au niveau bloc vs sauvegarde au niveau fichier : aide à la décision pour infrastructures hétérogènes

Dans des infrastructures hétérogènes, deux mondes se confrontent souvent dans le quotidien des sauvegardes et du DR (Disaster Recovery, c’est‑à‑dire la reprise après une panne majeure) : la réplication au niveau bloc et la sauvegarde au niveau fichier. Les deux donnent l’impression que « les données sont en sécurité » — mais résolvent des problèmes différents. Qui évalue correctement réplication au niveau bloc vs. sauvegarde au niveau fichier évite des idées reçues typiques comme « la réplication est une sauvegarde » ou « la sauvegarde de fichiers suffit aussi pour les bases de données ». Cet article fournit une aide à la décision pour les administrateurs, system engineers et pRESTataires IT : conditions préalables, risques, étapes de vérification, mise en œuvre et stratégie de repli réaliste — y compris les écueils spécifiques à MariaDB.

Begriffe sauber trennen: Was wird eigentlich geschützt?

Réplication au niveau bloc réplique des blocs de stockage (p. ex. au niveau SAN, iSCSI ou d’un storage array) d’un système source vers une cible. Elle opère en dessous du système de fichiers : au mécanisme de réplication, il est indifférent qu’un bloc appartienne à un disque de VM, à un fichier de données MariaDB ou à un fichier de log. Avantage : mise en miroir très rapide de volumes entiers, souvent avec des RPOs (Recovery Point Objective = perte de données maximale en durée) faibles et des RTOs (Recovery Time Objective = durée avant reprise d’exploitation) courts.

Sauvegarde au niveau fichier sauvegarde des fichiers et des arborescences (p. ex. via agents, SMB/NFS, rsync ou logiciel de sauvegarde), souvent avec versioning et rétention. Avantage : RESTauration ciblée de fichiers individuels, meilleur contrôle des versions et intégration souvent meilleure dans des concepts immutable/air‑gap (protection contre une manipulation ultérieure).

Important : les deux approches peuvent utiliser des Snapshots. Un Snapshot est une image à un instant donné (généralement Copy-on-Write) d’un volume ou d’un système de fichiers. Les snapshots ne remplacent pas les sauvegardes lorsqu’ils se trouvent sur le même stockage ou peuvent être compromis par la même attaque.

Warum Replikation nicht automatisch ein Backup ist

La question centrale n’est pas de savoir si les données existent « deux fois quelque part », mais si vous pouvez les RESTaurer de façon fiable à un instant défini. La réplication reproduit aussi les erreurs : suppression accidentelle, chiffrement par ransomware, corruption logique des données ou déploiement erroné sont répliqués rapidement et fidèlement vers la cible. C’est utile pour la haute disponibilité (HA), mais souvent fatal pour la RESTauration.

Une sauvegarde au niveau fichier avec versions peut précisément apporter une réponse ici : vous pouvez revenir à l’état antérieur au sinistre, même si le dommage a été « proprement » répliqué. Le prix : les RESTaurations complètes de systèmes sont souvent plus lentes, et la cohérence n’est pas garantie pour les bases de données sans mécanisme adapté.

Entscheidung nach Zielbild: HA, DR, Archiv, Compliance

Dans la pratique, un classement simple aide avant de discuter des outils :

• Haute Verfügbarkeit (HA): L’objectif est une indisponibilité minimale. La réplication au niveau bloc ou les mécanismes de cluster sont efficaces ici, car ils permettent un basculement rapide.
• Reprise après sinistre (DR): L’objectif est la remise en service après une défaillance de site ou de stockage. La réplication est pertinente, mais seulement si un point de consistance „sauberer“ et une possibilité de retour en arrière existent.
• Sauvegarde/RESTauration: L’objectif est la RESTauration même après des erreurs logiques ou une attaque. Les sauvegardes au niveau fichier, les référentiels d’objets, le stockage immuable et les copies hors site sont ici centraux.
• Archivage/Rétention/Conformité: L’objectif est la conservation longue durée, la traçabilité et la retrouvabilité. Les sauvegardes au niveau fichier avec index/métadonnées et des pools de conservation séparés sont généralement plus appropriées.

Dans des environnements hétérogènes (Windows/Linux, VMs/Bare Metal, NAS/SAN, On-Prem/Cloud, stacks applicatifs différents) est presque toujours une combinaison judicieuse : réplication pour des remises en service rapides de certains systèmes plus sauvegarde pour des parcours de RESTauration versionnés et auditables.

Réplication au niveau bloc en production : prérequis et écueils

La réplication au niveau bloc fonctionne bien lorsque vous clarifiez les hypothèses d’infrastructure et d’exploitation. Prérequis typiques :

• Identité & cohérence: La cible doit pouvoir prendre en charge les volumes répliqués dans un état cohérent. Sans quiescence applicative (court „Einfrieren“ des écritures) vous risquez des systèmes de fichiers ou des bases de données incohérents.
• Réseau & latence: La réplication est axée sur les E/S. La bande passante, le RTT (Round-Trip-Time) et la perte de paquets déterminent le RPO et la stabilité. La réplication asynchrone tolère la latence, la synchronisation est sensible et peut augmenter les latences d’écriture.
• Protection contre le split-brain: En cas de défaillance, les deux côtés ne doivent pas être « actifs » et écrire. Le split-brain (deux primaires actives) conduit presque toujours à une perte de données ou à des scénarios de fusion difficiles.
• Orchestration: Le basculement n’est pas seulement « Volume mounten ». DNS, IPs, Load Balancer, Secrets, Zertifikate, démarrages d’applications, dépendances (p. ex. AD, NTP, Monitoring) doivent être documentés dans un Runbook ou automatisés.

Écueils typiques dans une infrastructure hétérogène :

• Erreurs d’ordre: Les datastores des VM sont basculés, mais la base de données et le serveur applicatif démarrent dans le mauvais ordre. Résultat: récupération longue, états incohérents.
• Dépendances cachées: Un serveur de licences, un endpoint PKI interne ou un collecteur syslog central manque dans le segment DR – et les applications bloquent au démarrage.
• Chaînes de snapshots: Les snapshots de stockage en combinaison avec la réplication peuvent conduire à de longues « chaînes » ; cela complique les rollbacks et augmente la surcharge I/O.
• Réplication sans rétention: Il n’y a pas de « retour à hier 02:00 ». Alors la réplication n’est qu’un moyen plus rapide d’aboutir à un état erroné.

Étapes de vérification pour la réplication (Preflight)

Avant de présenter la réplication comme voie DR (en interne ou chez le client), vous devriez cocher au minimum ces points de contrôle :

• Point de cohérence défini: Comment assurez-vous la cohérence applicative (par ex. vidage de la base de données, gel du système de fichiers, snapshot VM avec quiesce) ?
• Runbook de basculement disponible: Qui fait quoi, dans quel ordre, avec quels contrôles ?
• Plan de retour (failback) prévu: Comment ramener les données sans split-brain ni longue indisponibilité ?
• Capacité d’isolation: Pouvez-vous, en cas d’incident, arrêter la réplication pour préserver une cible « propre » ?
• Fenêtre de test: Y a-t-il des tests réguliers (au moins partiels), pas seulement sur le papier ?

Sauvegarde au niveau fichier en exploitation: forces, limites, erreurs typiques

La sauvegarde au niveau fichier est souvent la couche de base la plus réaliste dans des environnements hétérogènes, car elle fonctionne proche de la plateforme : Windows-Server, Linux, partages NAS, données applicatives, répertoires de configuration. Les principaux avantages résident dans la versionnage, la RESTauration sélective et la rétention.

Les erreurs opérationnelles les plus courantes sont moins des problèmes d’outil que des problèmes de processus :

• Fichiers ouverts et verrous: Sans VSS (Volume Shadow Copy Service, Windows-service de snapshot) ou mécanismes comparables, les fichiers sont sauvegardés « en cours d’écriture ». Cela peut rendre la sauvegarde inutilisable.
• ACL et métadonnées: NTFS-ACLs, droits POSIX, xattrs (Extended Attributes) ou SMB-Ownership sont perdus si la sauvegarde n’est pas capable de préserver les métadonnées. La RESTauration a alors l’air « correcte », mais les autorisations sont cassées.
• Domaines de RESTauration trop vastes: Un seul job sauvegarde « tout ». En cas de besoin, la RESTauration prend trop de temps parce qu’il manque priorisation et parallélisation.
• Pas de test de RESTauration: Les backups sont considérés comme « verts », mais personne n’a jamais vérifié si une RESTauration cohérente fonctionne.

Règle pratique: les sauvegardes doivent refléter la cible de RESTauration

Quiconque a besoin d’une RESTauration système rapide devrait combiner les sauvegardes au niveau fichier avec des images/sauvegardes VM. Qui a besoin de fichiers individuels rapidement (par ex. des PDF de contrat supprimés par erreur) a besoin de versionnage et d’un moteur de recherche/indexation. Qui craint les ransomwares a besoin de copies immuables et hors site ainsi que d’identifiants séparés.

MariaDB au centre: pourquoi la cohérence de la base de données peut faire basculer la décision

Dans la catégorie MariaDB, la question suivante décide souvent : « Comment récupérer un état cohérent — et jusqu’où peut-on remonter dans le temps ? » MariaDB est compatible MySQL et utilise typiquement InnoDB (moteur de stockage avec journal de transactions). Pour les bases de données, une copie de fichiers sans étapes coordonnées est risquée : vous sauvegardez alors des fichiers de données et des journaux dans un état intermédiaire.

La réplication au niveau bloc peut fonctionner pour MariaDB si vous générez des snapshots cohérents au niveau applicatif (c.-à-d. en suspendant/flushant brièvement les écritures de manière contrôlée) et répliquez le snapshot. La sauvegarde au niveau fichier peut fonctionner si elle est consciente de la base de données (par ex. dumps logiques pour petites BD ou sauvegardes physiques avec un outil adapté).

Pièges typiques de MariaDB pour la réplication au niveau bloc

• La cohérence après crash n’est pas équivalente à la cohérence applicative : un snapshot cohérent vis‑à‑vis d’un crash équivaut à une « coupure de courant ». InnoDB peut récupérer de nombreuses situations, mais pas tous les scénarios sont propres, et les durées de récupération sont difficiles à prévoir.
• Binary Logs (Binlog) : pour le Point-in-Time-Recovery (PITR), vous avez besoin des Binlogs. La réplication seule ne permet pas un « retour à 10:17 » si les données de 10:20 ont déjà été répliquées.
• Version/Migration : une mise à niveau de MariaDB ou une migration de schéma logiquement erronée sera répliquée. Sans sauvegarde gérant les versions, pas de retour en arrière propre.

Pièges typiques de MariaDB pour les sauvegardes au niveau fichier

• « Copier simplement /var/lib/mysql » : en production, cela est souvent incohérent. Même si cela « marche » parfois, ce n’est pas une méthode fiable.
• Absence de Binlogs : sans Binlogs, il ne RESTe que la RESTauration au point du snapshot. Le PITR n’est plus possible, le RPO devient plus grossier.
• Absence de test de RESTauration : une sauvegarde n’est bonne que lorsqu’un RESTore sur une instance de test, incluant démarrage, vérifications et requêtes applicatives, fonctionne de manière reproductible.

Matrice de décision : quelle méthode (ou les deux) et quand ?

Pour le quotidien, une matrice pragmatique aide. Pas de théorie, mais de la logique opérationnelle :

• RTO très court (minutes) : réplication au niveau bloc ou réplication de VM + orchestration. Le niveau fichier seul est généralement trop lent pour une RESTauration complète du système.
• RPO très court (secondes à quelques minutes) : la réplication est efficace, mais n’a de sens qu’avec un « tampon temporel » supplémentaire (rétention des snapshots) ou une sauvegarde séparée, sinon vous répliquez le dommage.
• Beaucoup de petits cas de RESTauration (fichiers utilisateurs) : sauvegarde au niveau fichier avec gestion des versions, index et RESTauration correcte des permissions (ACLs/xattrs).
• Menace ransomware élevée : sauvegardes au niveau fichier/dépôt avec stockage immuable, comptes séparés et copie hors ligne/hors site. La réplication peut compléter, mais elle n’est pas une protection si elle réplique sans frein le chiffrement.
• Hétérogène, de nombreuses plateformes : niveau fichier en couche de base ; réplication ciblée pour quelques workloads critiques (p. ex. VMs de base de données centrales) et seulement avec un concept de test et de rollback.
• MariaDB avec exigence PITR : sauvegarde physique + Binlogs (PITR) ou une autre méthode basée sur le journal des transactions. La réplication peut fournir l’état de base, mais ne remplace pas la capacité de remonter dans le temps.

Mise en œuvre en pratique : points de contrôle que vous devez documenter

Indépendamment du produit, les artefacts suivants sont décisifs. S’ils manquent, la solution n’est souvent pas reproductible en cas de sinistre :

• Inventaire système : Quels volumes/partages contiennent quelles données (application, DB, logs, uploads, config) ?
• Classe de protection par workload : RPO/RTO cible, conservation, chiffrement, hors site.
• Dépendances : DNS, identité (AD/LDAP), NTP, certificats, Secrets, Monitoring, chemins de stockage/réseau centralisés.
• Runbooks : Failover, RESTore, Failback, Stop-the-Bleed (arrêter la réplication), points de communication et de validation.

Checklist : Test de RESTauration minimal (techniquement probant)

Un test de RESTauration n’a pas besoin d’être un exercice complet, mais il exige des critères de réussite clairs :

• Intégrité : sommes de contrôle/hash ou contrôles d’échantillonnage de fichiers (au niveau file-level).
• Démarrage/Boot : la VM/l’hôte démarre, les services sont opérationnels, les logs sont plausibles.
• Vérification applicative : pour MariaDB p. ex. établissement de connexion, requêtes simples, cohérence des tables.
• Temps : durée mesurée de la RESTauration (réelle, pas estimée).
• Documentation : Qu’est-ce qui a été différent de l’attendu ? Quelle dépendance manquait ?

MariaDB-How-to: Sauvegarde + Binlog-PITR comme couche de base fiable

Pour MariaDB, une approche éprouvée consiste en des sauvegardes complètes physiques régulières combinées à une sauvegarde continue/régulière des binlogs. Ainsi, vous pouvez revenir à un point de sauvegarde complet puis rembobiner jusqu’à peu avant l’incident (PITR). En pratique, l’outil couramment utilisé est Percona XtraBackup (sauvegarde physique à chaud pour InnoDB). Ce n’est pas un « détail interne de framework », mais de l’art opératoire : sauvegarde cohérente, étapes de RESTauration planifiables.

Exemple de schéma de procédure (Linux, générique ; adaptez les chemins/utilisateurs). Cela montre délibérément la structure — en production, vous devez stocker les credentials de manière sécurisée (p. ex. dans une my.cnf accessible uniquement à root, Vault, ou Backup-Agent-Secrets) et définir correctement les droits.

1) Sauvegarde complète avec XtraBackup (physique, cohérente)

#!/usr/bin/env bash
set -euo pipefail

BACKUP_BASE="/backup/mariadb"
TS="$(date +%F_%H%M%S)"
TARGET="$BACKUP_BASE/full_$TS"

mkdir -p "$TARGET"

# Remarque : ne pas laisser les identifiants en clair dans le script.
# Utilisez p. ex. un my.cnf protégé sous /root/.my.cnf

xtrabackup --backup --target-dir="$TARGET"

# L'étape --prepare rend la sauvegarde RESTaurable (applique les redo-logs)
xtrabackup --prepare --target-dir="$TARGET"

# Optionnel : marqueur d'intégrité
echo "$TS" > "$TARGET/backup.completed"

2) Sauvegarde des binlogs (base pour le Point-in-Time-Recovery)

Pour que le PITR fonctionne, il faut que les binlogs soient activés et copiés régulièrement vers une destination séparée et versionnée. Les binlogs sont les journaux de modifications continus (transactionnel / statement), qui permettent de rejouer les modifications après une sauvegarde complète.

#!/usr/bin/env bash
set -euo pipefail

BINLOG_DIR="/var/lib/mysql"
ARCHIVE_DIR="/backup/mariadb/binlogs"

mkdir -p "$ARCHIVE_DIR"

# Lister tous les binlogs actuels
mysql -N -e "SHOW BINARY LOGS;" | awk '{print $1}' | while read -r f; do
  src="$BINLOG_DIR/$f"
  if [[ -f "$src" ]]; then
    # Copie avec métadonnées, mais sans écraser (le versionnage dans un repo serait préférable)
    cp -n "$src" "$ARCHIVE_DIR/" || true
  fi
done

# Optionnel : lancer la rotation des binlogs (pour qu'un log « terminé » soit déplacé vers l'archive)
mysql -e "FLUSH BINARY LOGS;"

3) RESTore + PITR (Konzept und Prüfschritte)

Un PITR n’est efficace que dans la mesure où vos tests le sont. Lors d’un RESTore, vous RESTaurez d’abord la sauvegarde complète, démarrez MariaDB dans un environnement contrôlé, puis rejouez les Binlogs jusqu’à un instant défini ou jusqu’à une position déterminée. Vérifications typiques : démarrage sans boucles de crash-recovery, contrôles de plausibilité dans les données applicatives, rapprochement de la dernière transaction attendue.

Important pour la décision « réplication vs. sauvegarde » : ce voyage temporel n’est possible avec une simple réplication de blocs que si, côté réplication, vous disposez également d’un versioning/d’une rétention des snapshots et que vous pouvez isoler suffisamment rapidement lors d’un incident. En pratique, un repository de sauvegarde séparé constitue souvent la couche de base la plus robuste.

Réalité des rançongiciels : ce qui peut mal tourner dans les deux modèles

Les rançongiciels ne sont plus un cas particulier, mais un critère de conception. Pour les deux approches :

• Réplication : les données chiffrées se répliquent rapidement. Sans réplication retardée, rétention des snapshots sur la cible et un processus de « stop » en cas d’incident, la cible DR peut devenir inutilisable.
• Sauvegarde au niveau fichier : les sauvegardes peuvent être supprimées ou chiffrées si un attaquant obtient les identifiants de sauvegarde ou l’accès au repository. Stockage immuable (WORM/immutabilité), comptes séparés et copies hors ligne/hors site sont essentiels.

Un schéma opérationnel viable est : réplication pour la disponibilité, sauvegarde pour la RESTaurabilité. Accompagnez-le d’un runbook d’incident « Stop-the-bleed » : arrêter la réplication, interrompre les jobs de sauvegarde, révoquer et régénérer les identifiants, créer une fenêtre pour la forensique, puis RESTaurer ciblé à partir d’un point propre.

Stratégie de repli : que faire si le chemin prévu échoue ?

La stratégie de repli signifie : vous prévoyez le moment où un RESTore échoue ou où un failover révèle des dépendances inattendues. Un plan robuste comporte des niveaux :

• Niveau 1 : redémarrage sur l’état répliqué (rapide, mais le risque d’erreurs logiques subsiste).
• Niveau 2 : rollback sur un snapshot cible (si rétention disponible et snapshot antérieur à l’incident).
• Niveau 3 : RESTauration depuis le repository de sauvegarde (versionné/immuable, indépendant du stockage répliqué).
• Niveau 4 : RESTauration partielle (p. ex. MariaDB via PITR, fichiers depuis les versions, serveurs applicatifs recréés depuis un template/IaC).

Pour que cela ne RESTe pas théorique, définissez à l’avance : qui décide du niveau, quelle priorité de données s’applique (p. ex. d’abord MariaDB, puis les uploads, puis le reporting), et quelle durée maximale d’indisponibilité est acceptable. Surtout dans des environnements mixtes, une RESTauration « tout ou rien » est rarement optimale.

Recommandation pour une infrastructure hétérogène : une cible pragmatique

Si vous RESTructurez aujourd’hui ou consolidez un setup existant, cette cible est en pratique bien exploitable :

• Couche de base : sauvegarde au niveau fichier / dépôt avec versioning, rétention claire et copie offsite (règle 3-2-1 : 3 copies, 2 médias, 1 hors site).
• Pour les systèmes critiques : réplication au niveau bloc (ou réplication de VM) avec méthode de consistance définie et rétention des snapshots sur la cible.
• Pour MariaDB : sauvegarde physique complète + archivage des Binlogs pour PITR, plus tests réguliers de RESTauration sur instance de test.
• Exploitation : monitoring/alerting sur le succès des jobs, leur durée, le volume de données, le niveau de remplissage du repository et les tests de RESTauration – pas seulement « job vert ».

Cela réduit la pression des tests DR: vous n’avez pas à reconstruire chaque système entièrement à partir des sauvegardes lorsque la réplication permet une reprise rapide des activités. En parallèle, vous RESTez en mesure de revenir à un point propre si le dommage logique a déjà été répliqué.

Conclusion : la réplication au niveau bloc vs la sauvegarde au niveau fichier n’est pas une question dogmatique

La décision réplication au niveau bloc vs sauvegarde au niveau fichier se prend, dans une infrastructure hétérogène, en fonction des objectifs opérationnels : la réplication est un levier puissant pour obtenir des RTOs courts et des basculements rapides, mais sans gestion des versions et sans capacité d’isolation vous répliquez également le dommage. Les sauvegardes au niveau fichier fournissent des versions, des RESTaurations sélectives et une meilleure rétention – elles échouent toutefois si la consistance (en particulier pour MariaDB) et les tests de RESTauration ne sont pas pris au sérieux.

Si vous ne retenez qu’une règle pratique : réplication pour la disponibilité, sauvegardes pour la RESTaurabilité – et testez les deux régulièrement, avec un runbook „Stop-the-bleed“ clair et une stratégie de repli graduée.

Pour ce sujet, la sauvegarde immuable et la protection contre les ransomwares sont également importantes. L’article remet ces aspects en perspective de manière compréhensible et montre ce qui compte au quotidien.