Récupération de données
Récupération de données à Lannion
À Lannion, arrêtez GitLab. Conservez la base PostgreSQL, les dépôts, le stockage d'objets, les téléversements, les artefacts LFS, la configuration, les secrets et les sauvegardes. Le laboratoire acquiert les supports, rapproche les dépendances sur des copies puis valide les projets, les commits et les fichiers.
Diagnostic et devis
Diagnostiquer GitLab sans nettoyer les objets
Le diagnostic distingue la panne d’un média, l’absence d’un volume, une corruption PostgreSQL, un dépôt incomplet, un stockage d’objets partiel, des secrets perdus et une sauvegarde désynchronisée. Ces défauts peuvent produire la même erreur d'accès tout en exigeant des séquences de récupération très différentes.
La base est étudiée sur une copie pour relever les projets, les espaces de noms, les chemins de stockage, les utilisateurs, les tickets et les références. Les dépôts sont parcourus sans opération destructive afin d'identifier les commits, les références, les objets manquants et les bundles. Les fichiers annexes gardent leur provenance et leur empreinte.
- Disques durs contenant base PostgreSQL, dépôts Git ou répertoires GitLab
- SSD et NVMe portant les volumes de données, le registre d’images, les artefacts ou le cache
- Serveurs physiques avec système, configuration, données et sauvegardes séparés
- NAS et ensembles RAID utilisés pour les dépôts, le stockage d’objets ou les sauvegardes
Attention
Éviter restore, réplication et garbage collection
- Ne lancez pas git gc ou la collecte des objets sur les sources
- Ne restaurez pas une archive par-dessus l'unique instance exploitable
- Ne réinitialisez aucun des composants concernés: gitlab-secrets.json ou les clés de chiffrement
- Ne reconnectez pas un nœud divergent à la réplication avant acquisition
Toute opération susceptible de supprimer des objets, modifier les références ou réécrire la base reste différée jusqu'à la création de copies protégées. La priorité est de préserver chaque branche avant d'établir un état cohérent.
Comment ça marche
Des supports figés aux projets GitLab validés
- Arrêtez Puma, Sidekiq, Gitaly, PostgreSQL, registry, runners et tâches planifiées. Ne lancez ni nouvelle sauvegarde, ni restore, ni garbage collection, ni réplication. Notez l'heure de l'incident, la version GitLab, les erreurs et chaque opération déjà tentée.
- Inventoriez la plateforme complète. Conservez la base PostgreSQL, les dépôts, le stockage d'objets, les téléversements, les artefacts, les paquets, le registre, les objets LFS, les pages, la configuration, les secrets, les clés, les certificats, les runners et les sauvegardes. Distinguez chaque nœud, chaque volume, chaque bucket, chaque instantané et chaque copie externe.
- Le laboratoire qualifie la stabilité physique de chaque support avant l'analyse applicative. Un HDD instable, un SSD absent, un RAID dégradé, un magasin de données corrompu ou un bucket partiel imposent des acquisitions différentes. La salle blanche ne concerne qu'un disque dur mécanique à ouvrir.
- Lorsque la lecture est suffisamment stable, des images bit à bit ou copies protégées sont créées sur un stockage sain. Les erreurs restent consignées et les originaux sont retirés du flux d'analyse. Les montages, scans Git, requêtes SQL et essais utilisent ensuite des duplications dédiées.
Nos expertises
Supports et composants examinés pour GitLab
Préparer le devis
Préparer la plateforme sans lancer de collecte
Une préparation contrôlée protège les objets et références encore disponibles. Ne cherchez pas à nettoyer ou restaurer la plateforme avant la création de copies.
- À arrêter: services GitLab, runners, réplications et tâches planifiées
- Noter l'heure de panne et toutes les opérations déjà tentées
- À identifier: version, édition, mode d'installation et topologie
- À conserver: PostgreSQL, repositories, uploads, LFS et artifacts
- À préserver: configuration, secrets, certificats et clés autorisées
Notre expertise
Une méthode centrée sur les dépendances GitLab
GitLab distribue son état entre une base relationnelle, des dépôts Git, plusieurs stockages d'objets, des fichiers de configuration et des secrets. Une copie du répertoire des dépôts ne restitue pas automatiquement les tickets, les permissions, les téléversements ou le registre d’images. La collecte commence donc par la carte complète des dépendances.
Les opérations postérieures à la panne sont datées. Une restauration incomplète, un redémarrage de Gitaly, un git gc, une réplication ou une rotation de secrets peut modifier ce qui reste. Cette chronologie sépare l'incident initial des changements provoqués par les tentatives de remise en service.
- Arrêt
- Stopper services et jobs
- Base
- À préserver: PostgreSQL
- Dépôts
- À garder ensemble: objets et chemins
- Validation
- À contrôler: projets et commits
Prise en charge
Préparer un dossier GitLab depuis Lannion
Cette page répond aux demandes provenant de Lannion sans déclarer de laboratoire local. La localisation organise le parcours du dossier; les opérations techniques dépendent des supports, des accès légitimes et de la qualification réalisée avant devis.
Laissez serveurs et stockages hors ligne après l'incident. Étiquetez nœuds, volumes et rôles. Joignez la version GitLab, le mode d'installation, les messages d'erreur, la topologie, les chemins de données et la chronologie de chaque commande ou restauration déjà lancée.
Dépendances GitLab à relier
Rapprocher base, dépôts, objets et secrets
Le périmètre utile inclut PostgreSQL, les dépôts, les téléversements, les objets LFS, les artefacts, les paquets, le registre d’images, la configuration, les secrets autorisés, les certificats, les sauvegardes et les instantanés. Chaque élément garde sa provenance afin de reconstruire un état et d'expliquer les écarts entre les branches disponibles.
Une archive ancienne peut être plus cohérente qu'un snapshot récent si ce dernier ne contient qu'une partie du stockage. Les identifiants, versions, chemins, commits et timestamps guident le rapprochement; la date du fichier ne suffit pas à établir la bonne génération.
- Base À conserver: PostgreSQL et ses identifiants de projets.
- Git À préserver: repositories, refs, commits et objets.
- Objets À garder ensemble: uploads, LFS, artifacts et registry.
Carte
Orientation à Lannion selon la plateforme et le stockage
FAQ
Questions fréquentes sur GitLab et la récupération
Faut-il lancer git gc sur les dépôts endommagés?
Non sur les sources. La collecte peut supprimer des objets encore atteignables par une branche incomplète ou une référence perdue. Les repositories sont d'abord acquis puis analysés sur une copie.
Une sauvegarde GitLab suffit-elle à tout restaurer?
Pas toujours. Selon la configuration, stockage d’objets, registry, configuration, secrets ou certificats peuvent rester hors archive. Le contenu du backup est rapproché des autres composants avant tout essai.
Peut-on récupérer seulement les dépôts Git?
Oui si leurs objets et références sont exploitables. Ils peuvent être restitués sous forme de dépôts ou bundles, mais issues, permissions, uploads et autres données dépendent aussi de PostgreSQL et des stockages annexes.
Pourquoi conserver gitlab-secrets.json?
Certains champs et jetons dépendent de secrets propres à l'instance. Ce fichier ne contourne pas une protection; il fait partie des dépendances légitimes à préserver et peut conditionner une validation complète.
Diagnostic et devis
Qualifier les dépendances avant de restaurer GitLab
Décrivez la version, la topologie, les dépôts, les objets, les sauvegardes, les secrets autorisés, les symptômes et les opérations déjà tentées. Ces éléments permettent de cadrer les acquisitions et les rapprochements utiles, puis d'établir le devis après examen sans préjuger du résultat.