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
PostgreSQL + dépôts bare]
        C2[Copie 2 : sauvegarde locale
/var/backups/gitrust]
        C3[Copie 3 : stockage distant
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
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¶

RPO et RTO réalistes¶

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

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.

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¶

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¶

• Sauvegarder et restaurer — procédures pas-à-pas
• Modèle de déploiement — HA et ses implications sur la sauvegarde
• Architecture globale — les trois sources de vérité