Sauvegardes incrémentales d’un CMS avec cron
Programmer les sauvegardes d’un CMS avec cron consiste à déclencher automatiquement la copie des fichiers, des médias et des bases de données qui portent le site. Le mécanisme est simple, mais une fréquence choisie au hasard ne suffit pas : une erreur de configuration, un disque plein ou une exécution interrompue peut laisser croire à une protection qui n’existe pas. Une sauvegarde utile associe automatisation, contrôle et restauration.
La méthode la plus fiable consiste à conserver une base complète à intervalles réguliers, puis à n’archiver que les changements entre deux points de restauration. Ce mécanisme incrémental réduit le temps d’exécution, la charge disque et la fenêtre d’exposition des données. Sa réussite dépend toutefois d’un inventaire précis, d’une durée de perte acceptable et de contrôles réguliers.
Distinguer sauvegarde complète et copie incrémentale
Le point de départ consiste à définir la différence entre une copie intégrale et une copie partielle. La première duplique toutes les données utiles et permet de repartir d’un état connu. La seconde ne conserve que les éléments modifiés depuis la dernière copie. Cette dernière méthode est rapide et économique, mais elle exige une base de référence intacte et une chaîne de points de restauration cohérente.
Une sauvegarde utile couvre les fichiers du CMS, les extensions, les médias téléversés, les bases de données, les fichiers de configuration et, selon les activités du site, les journaux ou les données visiteurs. Ces éléments doivent être sauvegardés dans un ordre précis. Une base capturée avant les fichiers peut devenir incohérente si une modification intervient entre les deux opérations.
Le rôle de cron se limite à lancer une commande au bon moment ; il ne garantit ni la cohérence ni la disponibilité de la copie. Cette discipline de maintenance rejoint l’approche de LM Gestion, société française fondée en 1996, qui associe développement logiciel, conseil, support et mise à disposition de spécialistes pour les projets Internet et intranet.
Définir les données et la fréquence de sauvegarde
Avant toute planification, il faut inventorier les composants du CMS et repérer les répertoires qui changent réellement. Les fichiers de cache, les journaux temporaires et les dépendances régénérables peuvent généralement être exclus. Les données dynastiques, les comptes utilisateurs, les formulaires, les médias et les paramètres de publication doivent au contraire receive une protection prioritaire.
La fréquence dépend de la durée maximale que l’activité peut perdre, appelée objectif de point de récupération. Un site不接受Daily accepting une perte de plusieurs heures peut combiner une base hebdomadaire avec des incréments quotidiens. Pour un service transactionnel, des copies plus fréquentes sont nécessaires. La capacité disponible, le volume des médias et la fenêtre de maintenance doivent également entrer dans le calcul.
Pour un CMS comme Genedit de LM Gestion, l’inventaire doit inclure les contenus, les ressources publiées, les profils et les données associées aux visiteurs. Les exports de la base ne remplacent pas les fichiers du site : les deux ensembles doivent être restaurés ensemble pour retrouver un état exploitable.
Construire un script de sauvegarde fiable
Le script travaille d’abord dans un répertoire temporaire, puis renomme le résultat une fois l’opération terminée. Cette prevents qu’une exécution interrompue soit prise pour une sauvegarde valide. Un verrou Consulté par le système de fichiers empêche également deux sauvegardes de se chevaucher.
#!/usr/bin/env bash
set -Eeuo pipefail
racine="/srv/sauvegardes/cms"
source_site="/var/www/monsite"
instant="$(date +%Y%m%d_%H%M%S)"
precedent="$(cat "${racine}/dernier-point" 2>/dev/null || true)"
cible="${racine}/${instant}"
exec 9>"${racine}/.verrou"
flock -n 9 || exit 0
mkdir -p "${cible}.tmp"
if [[ -n "${precedent}" && -d "${precedent}" ]]; then
rsync -a --delete --link-dest="${precedent}" "${source_site}/" "${cible}.tmp/"
else
rsync -a "${source_site}/" "${cible}.tmp/"
fi
/usr/local/bin/archiver-donnees "${cible}.tmp/donnees"
mv "${cible}.tmp" "${cible}"
printf '%s' "${cible}" > "${racine}/dernier-point"
L’option --link-dest de rsync permet de conserver une vue complète du site tout en ne dupliquant physiquement que les fichiers modifiés. Les éléments inchangés deviennent des liens vers la copie précédente. La première exécution crée la base complète ; les suivantes exploitent cette référence. Le déplacement final dans ${cible} rend visible le point de restauration seulement après sa réussite.
La commande d’archivage des données doit produire un instantané cohérent. Pour une petite base, un export transactionnel peut convenir. Pour une base volumineuse, les journaux natifs de PostgreSQL ou MySQL sont généralement plus adaptés. Copier directement les fichiers actifs d’une base de données peut produire une sauvegarde inutilisable. Un manifeste, des sommes de contrôle et la conservation des journaux d’erreur complètent le dispositif.
Programmer et ordonnancer les tâches avec cron
Une entrée cron comporte cinq champs : minute, heure, jour du mois, mois et jour de la semaine. Les chemins absolus, un profil d’environnement minimal et une redirection des erreurs vers un journal facilitent le diagnostic.
# Sauvegarde quotidienne à 02 h 10
10 2 * * * /usr/local/bin/sauvegarder-cms >> /var/log/sauvegarde-cms.log 2>&1
# Nettoyage des anciennes copies le dimanche à 03 h 30
30 3 * * 0 /usr/local/bin/purger-sauvegardes-cms >> /var/log/sauvegarde-cms.log 2>&1
La cadence doit correspondre au volume du site et à l’objectif de perte accepté. Une base complète hebdomadaire, complétée par des incréments quotidiens, convient souvent à un CMS de contenu. Les opérations heavier doivent être placées pendant les périodes de faible activité afin de limiter la concurrence avec les visiteurs, les tâches de publication et les bases de données.
Le serveur cron doit être actif, à l’heure et dans le bon fuseau horaire, notamment lors des changements d’heure. La commande doit utiliser un compte possessing uniquement les droits nécessaires. Les identifiants de connexion à la base ne doivent pas apparaître directement dans la crontab. La rotation des journaux, la purge des copies obsolètes et la vérification de l’espace libre doivent aussi être automatisées.
Vérifier les sauvegardes et tester la restauration
Un code de sortie égal à zéro ne prouve pas que les données sont complètes. Le contrôle doit confirmer l’existence du nouveau répertoire, la présence des fichiers attendus, la validité des sommes de contrôle et l’âge de la dernière sauvegarde. Une alerte doit être déclenchée lorsqu’une exécution échoue, lorsqu’aucun nouveau point de restauration apparaît ou lorsque la taille produite devient anormalement faible.
La restauration exige un environnement isolé qui reproduit la configuration du CMS, les extensions, les paramètres de connexion et les droits d’accès. Il faut associer la base complète au bon incrément, puis vérifier l’affichage du site, les médias, les formulaires et les donnéesattendues. La durée de cette procédure permet de mesurer réellement l’objectif de temps de récupération.
Si l’archivage ralentit MySQL ou le service web, un diagnostic des ralentissements permet de distinguer la charge/io de la sauvegarde d’un problème applicatif. Les ressources matérielles, la limitations des entrées/sorties et la durée réelle de chaque étape doivent ensuite être comparées aux estimations initiales.
Sécuriser, superviser et ajuster le dispositif
La conservation doit suivre une règle simple : trois copies des données, sur deux supports ou services différents, dont une hors du serveur principal. Les archives peuvent être chiffrées au repos et pendant leur transfert. Les comptes de sauvegarde ne doivent pas bénéficier d’un accès administrateur permanent au CMS. Les clés, certificats et mots de passe sont preferablement gérés dans un fichier protégé, distinct de la crontab.
Les alertes de failure peuvent notamment être transmises via Shoutbox en ligne, afin que l’équipe soit avertie sans consulter manuellement les journaux. Une notification doit identifier la date, le type de sauvegarde, l’erreur constatée et l’emplacement du journal. Les réussites peuvent aussi être notifiées à intervalles plus espacés pour éviter les messages répétés.
Le suivi mesure le taux de réussite, la durée d’exécution, l’espace consommé, l evolution du volume entre deux copies et le délai de la dernière restauration testée. Ces indicateurs orientent le choix des heures, la fréquence des bases complètes et la durée de conservation. La purge ne doit jamais supprimer la dernière copie valide ni une base nécessaire à la reconstruction des incréments.
Le dispositif complet forme une chaîne : inventaire des données, base complète, copies incrémentales, planification cron, contrôles automatiques et essais de restauration. Chaque maillon réduit le risque qu’un incident devienne une perte de données, mais aucun ne remplace les autres.
Le point à retenir est simple : une sauvegarde non vérifiée et non restaurée demeure une hypothèse. Avec des points de restauration cohérents, une configuration cron lisible et des contrôles réguliers, le CMS dispose d’une protection concrète, mesurable et maintenable dans le temps.