GitRust GitRust
Connexion

Eric / documentation

strategie-sauvegarde.md 7793 octets

Comprendre la stratégie de sauvegarde adaptée à gitrust

Ce que vous allez comprendre

  • Appliquer la règle 3-2-1 aux trois sources de vérité de gitrust (base de données, dépôts bare, clé SSH hôte)
  • Analyser les RPO et RTO réalistes pour une instance gitrust mono-machine
  • Évaluer les compromis entre pg_dump classique et réplication WAL en continu

Le problème concret

Votre serveur gitrust est hors service suite à une défaillance disque. Vous avez une sauvegarde de la base de données, mais pas des dépôts bare. Ou l'inverse. Combien de temps pour remettre l'instance en service ? Combien de données perdez-vous ?

L'analogie

Imaginez gitrust comme un cabinet d'architecte :

  • La base de données est le registre des contrats et des clients (qui possède quoi, les métadonnées)
  • Les dépôts bare sont les tiroirs de plans (les fichiers réels)
  • La clé SSH hôte est la plaque officielle à l'entrée (l'identité du cabinet)

Si vous avez le registre mais pas les tiroirs, vous savez que le projet « Maison Martin » existe mais vous n'avez plus les plans. Si vous avez les tiroirs mais pas le registre, vous avez des dossiers anonymes sans savoir à qui ils appartiennent. Les deux doivent être sauvegardés ensemble.

Le modèle

La règle 3-2-1 appliquée à gitrust

graph TB
    subgraph "3 copies"
        C1[Copie 1 : données en production<br/>PostgreSQL + dépôts bare]
        C2[Copie 2 : sauvegarde locale<br/>/var/backups/gitrust]
        C3[Copie 3 : stockage distant<br/>S3 / NAS / autre serveur]
    end

    subgraph "2 supports différents"
        S1[Disque SSD serveur principal]
        S2[Disque NAS ou volume objet]
    end

    subgraph "1 copie hors site"
        O1[Datacenter différent<br/>ou cloud object storage]
    end

    C1 --> S1
    C2 --> S1
    C3 --> S2
    S2 --> O1

Les 3 copies :

  1. Production (données en vie sur le serveur)
  2. Sauvegarde locale (/var/backups/gitrust sur le même serveur ou volume attaché)
  3. Sauvegarde distante (rsync vers NAS, rclone vers S3, etc.)

Les 2 supports : le disque du serveur principal + un support physiquement distinct.

1 hors site : en cas d'incendie, d'inondation ou de compromission du datacenter, une copie doit être inaccessible depuis le réseau principal.

Les trois sources de vérité de gitrust

SourceTaille typiqueConsistanceFréquence recommandée
PostgreSQL (pg_dump)Quelques Mo à plusieurs GoCohérente à un instant T (--format=custom)Quotidien minimum, idéalement 2x/jour
Dépôts bare (rsync)Dizaines de Mo à plusieurs ToCohérente par dépôt (Git garantit l'atomicité des packs)Quotidien minimum
Clé SSH hôte (ssh_host_ed25519_key)< 1 KoImmuable après le premier démarrageUne seule fois, puis conserver en lieu sûr

RPO et RTO réalistes

RPO (Recovery Point Objective) : quantité maximale de données perdues.

StratégieRPO
pg_dump quotidien à 2h≤ 24 h de données perdues
pg_dump toutes les 6 h≤ 6 h de données perdues
WAL streaming (wal-g)≤ quelques secondes

Pour la cible principale de gitrust (équipes 3-20 personnes), un RPO de 24 h est généralement acceptable. Si votre équipe code intensément la nuit, envisagez 2 sauvegardes quotidiennes.

RTO (Recovery Time Objective) : temps pour remettre l'instance en service après incident.

ScénarioRTO estimé
Restauration sur la même machine (disque remplacé)30-60 min
Restauration sur une nouvelle VM (même datacenter)15-30 min
Restauration sur une nouvelle VM (nouveau datacenter)60-90 min (transfert des sauvegardes)

pg_dump vs réplication WAL

graph LR
    subgraph "pg_dump (snapshot)"
        A1[pg_dump à 2h00] --> B1[Fichier .dump]
        B1 --> C1[Transfert vers NAS]
        C1 --> D1[RPO ≤ 24h]
    end

    subgraph "WAL streaming (continu)"
        A2[PostgreSQL primary] -->|WAL segments| B2[wal-g / pgbackrest]
        B2 -->|continu| C2[Stockage objet S3]
        C2 --> D2[RPO ≤ quelques secondes]
    end

pg_dump — recommandé pour commencer :

  • Simple à mettre en place et à tester
  • Fichier standalone restaurable avec pg_restore
  • RPO = interval entre deux dumps
  • Fonctionne même si PostgreSQL est sous charge (cohérence transactionnelle garantie par PostgreSQL)

WAL streaming (wal-g, pgbackrest) — pour les cas avancés :

  • RPO quasi nul (Point-in-Time Recovery)
  • Nécessite un stockage objet (S3, MinIO)
  • Complexité opérationnelle significativement plus élevée
  • Indispensable si votre activité impose un RPO < 1 h

Recommandation : commencez par pg_dump quotidien + rsync. Migrez vers WAL streaming uniquement si votre SLA l'exige.

Cohérence entre base de données et dépôts bare

La sauvegarde la plus dangereuse est celle qui est partiellement réussie : base sauvegardée, dépôts non sauvegardés (ou l'inverse).

Un dépôt existe à deux endroits :

  • En base : repositories.disk_path enregistre le chemin
  • Sur disque : le dossier .git bare contient les objets Git

Pour éviter l'incohérence, sauvegardez toujours les deux dans la même fenêtre temporelle. Le script backup.sh recommandé effectue les deux en séquence :

# Ordre correct : d'abord la DB, puis les dépôts
pg_dump → fichier .dump
rsync repos → destination

En pratique, le décalage entre les deux (quelques secondes/minutes) est acceptable : un dépôt créé entre les deux sauvegardes sera absent du rsync mais présent en base — une re-synchronisation après restauration suffit.

Tester la restauration (le drill)

Une sauvegarde non testée n'est pas une sauvegarde — c'est une espérance.

Planifiez un drill trimestriel sur une VM éphémère :

  1. Copier les fichiers de sauvegarde sur la VM
  2. Installer gitrust et PostgreSQL
  3. Restaurer avec les procédures documentées dans Sauvegarder et restaurer
  4. Vérifier : connexion admin, liste des dépôts, git clone d'un dépôt connu
  5. Mesurer le temps effectif → comparer avec votre RTO cible
  6. Documenter les étapes imprévues → améliorer le script

Le drill révèle les problèmes invisibles : fichier de sauvegarde corrompu, script qui suppose un chemin qui n'existe pas, mot de passe PostgreSQL non documenté.

Alternatives et compromis

ApprocheRPOComplexitéCoût
pg_dump quotidien + rsync≤ 24 hFaibleFaible
pg_dump 2x/jour + rsync≤ 12 hFaibleFaible
WAL streaming + rsync≤ 1 minÉlevéeMoyen (stockage objet)
Réplication PostgreSQL (HA) + rsync≤ quelques sTrès élevéeÉlevé

Pour les équipes de 3-20 personnes avec gitrust, la première ligne est le bon point de départ.

Vérifier votre compréhension

  1. Vous utilisez pg_dump quotidien à 2h00. Un développeur pousse 3 jours de travail le mercredi soir à 23h45. Le serveur tombe à minuit. Que perdez-vous, et pourquoi ?

  2. Quelle est la différence entre RPO et RTO ? Lequel est le plus facile à améliorer avec une architecture mono-machine ? Lequel nécessite une refonte architecturale ?

Pour aller plus loin