GitHub devrait être la première chose que vous sauvegardez

Ce classement est un vestige d'une autre époque. GitHub est désormais le système d'enregistrement le plus précieux et le plus rapide dans la plupart des entreprises d'ingénierie, et il doit figurer en tête de la liste des priorités en matière de sauvegarde, devant le courrier électronique, les partages de fichiers et la plupart des applications hébergées dans le cloud.

Pourquoi GitHub s'est hissé au sommet

Ce qui vit dans GitHub a changé. Un org GitHub moderne contient le plan d'exploitation de l'entreprise : code d'application, infrastructure en tant que code, pipelines CI/CD, configurations de déploiement, runbooks, politiques de sécurité, SDK orientés client, invites d'IA et, de plus en plus, les définitions d'agents qui automatisent l'ingénierie au jour le jour. Perdre un repo signifiait autrefois perdre du code. Aujourd'hui, la perte d'un repo peut signifier la perte de la spécification du fonctionnement de l'entreprise.

Les modes de défaillance ont empiré. Les protections natives de GitHub (protection des branches, réplication, fenêtre de 90 jours pour les références supprimées) sont réelles, mais étroites. Elles ne permettent pas de récupérer un " force push " que GitHub considère comme légitime parce qu'il provient d'un compte de service authentifié. Ils ne récupèrent pas un agent qui réécrit .github/workflows dans une boucle qui détruit les artefacts de publication. Elles ne récupèrent pas un jeton d'accès personnel compromis utilisé pour supprimer 200 branches à 3 heures du matin.

Ce qu'une sauvegarde GitHub doit réellement survivre

Les événements destructeurs qui comptent ne sont pas pour la plupart malveillants. Ils sont banals, et l'ère des agents les a rendus plus courants :

• Un agent de nettoyage supprime des branches qui semblaient périmées mais qui ne l'étaient pas.
• Un agent de refactorisation force le passage à main après un mauvais rebasement.
• Un script de migration réécrit l'historique à travers une douzaine de dépôts.
• Un jeton d'agent compromis est utilisé pour supprimer des branches, des étiquettes ou des versions avant que quiconque ne le remarque.
• Un flux de travail CI exécute une commande git destructrice générée par un agent.

Dans tous les cas, le dommage semble légitime pour GitHub. Il a été authentifié. Il a été autorisé. Les protections propres à GitHub n'ont aucun moyen de savoir que le push était erroné.

Un exemple théorique

Une société financière de taille moyenne gère 18 dépôts sur GitHub, sauvegardés chaque nuit. Ils ont un agent de codage qui exécute des tests et applique des correctifs automatisés à travers l'org, authentifié avec un compte de service qui détient une portée d'administrateur sur le monorepo principal, parce que les permissions à grain fin étaient un projet du trimestre à venir.

La récupération prend trois jours. Deux des correctifs ne peuvent pas être reconstruits proprement et doivent être réécrits à partir de zéro. Une sauvegarde horaire aurait permis de limiter la perte à 47 minutes de travail.

Que rechercher dans une solution de sauvegarde GitHub

Si GitHub est votre priorité n°1 en matière de sauvegarde, la solution doit comporter quatre éléments :

Une cadence de sauvegarde agressive. Les outils de sauvegarde utilisent le terme RPO (objectif de point de récupération). En clair, il s'agit de la quantité de travail que vous êtes prêt à perdre en cas de panne, mesurée en temps. Si votre sauvegarde est effectuée chaque nuit, votre RPO est de 24 heures. Pour GitHub à l'ère de l'agent, une sauvegarde nocturne est trop lente. L'heure est le seuil à ne pas dépasser. Trente minutes sont acceptables pour les monorepos critiques. Demandez à n'importe quel fournisseur quelle est sa cadence minimale, et si elle s'applique à l'ensemble du repo (y compris les problèmes, les PR et les paramètres) ou uniquement au code.

Couverture complète de la surface. La seule sauvegarde du code transforme un incident de quatre heures en un incident de quatre jours. Vous avez besoin des problèmes, des PR, des discussions, des flux d'actions, des versions, des objets LFS, des règles de protection des branches et des paramètres au niveau de l'organisation, comme l'appartenance à une équipe et l'installation d'applications. La seule perte de .github/workflows peut signifier la perte de la configuration des agents dont vous dépendez.

Immutabilité. Un jeton d'administrateur compromis qui peut supprimer un repo peut souvent supprimer la sauvegarde aussi, si le système de sauvegarde fait confiance aux mêmes informations d'identification. Les copies aériennes ou verrouillées ne sont pas facultatives. Elles font la différence entre une mauvaise journée et un cauchemar de reconstruction à partir des ordinateurs portables des développeurs.

Recouvrement testé. Restaurez une version non critique de bout en bout au moins une fois par trimestre. Mesurez le temps que cela prend réellement. Une sauvegarde à partir de laquelle vous n'avez jamais effectué de restauration n'est qu'une supposition, pas un plan.

Le changement

La plupart des organisations sauvegardent GitHub en partant du principe qu'il s'agit d'un dépôt de code auquel sont rattachés des artefacts secondaires. Ce n'est plus ce qu'est GitHub. C'est le système opérationnel le plus rapide que la plupart des entreprises utilisent, et la vitesse à laquelle il accumule de la valeur a dépassé la posture de sauvegarde dont la plupart des équipes ont hérité.

Portez GitHub en haut de la liste des priorités. Une cadence de sauvegarde agressive, une couverture complète de la surface, l'immuabilité et une récupération testée sont les caractéristiques qui font de cette priorité une réalité. Sans cela, "nous sauvegardons GitHub" est une case à cocher, pas un plan.

Pour les entreprises, la sauvegarde de GitHub est une priorité.