En el món del desenvolupament de programari, tenir un mirall de Git s'ha convertit en una pràctica gairebé automàtica. Un comandament, un prompt, un sospir d'alleujament: ja tenim còpia. Però aquesta sensació de seguretat és enganyosa si mai no s'ha provat la ruta de fallada. La diferència entre una còpia i un pla de recuperació real no està en el comandament que la genera, sinó en la verificació que realment funciona quan més es necessita.
Molts equips confien en un guió simple: git clone --mirror seguit de git push --mirror. Això demostra que el model tècnic és viable, però no resol el problema operatiu. Qui gestiona les credencials? Què passa si el destí està al mateix proveïdor i pateix una caiguda global? I els fitxers grans de Git LFS? Un mirall que no s'ha restaurat mai és només una il·lusió òptica.
L'error més freqüent és mantenir la rèplica dins del mateix domini de fallada. Si el mirall està al mateix compte de GitHub, a la mateixa regió d'AWS o sota el mateix proveïdor de núvol, una interrupció del servei principal deixa també inaccessible la còpia. La recuperació no és simplement tenir un altre remot; és tenir un remot que estigui fora del radi d'explosió de l'incident. Aquí és on entra la decisió d'escollir proveïdors diferents o almenys zones de disponibilitat separades.
Un altre aspecte crític és la política de mirroring. Exacte o additiu? Un mirall exacte replica cada esborrat i cada reescriptura d'història. Si algú elimina una branca per error, el mirall l'elimina també. Això pot ser desitjable si es busca un clon idèntic a punt per utilitzar-se com a failover immediat. Però si l'incident és un esborrat accidental, el mirall exacte destrueix l'evidència. Un backup additiu conserva les branques esborrades i permet recuperar un estat anterior, però al cost que el destí no sigui una rèplica neta. No hi ha una resposta universal. L'important és triar deliberadament i, sobretot, provar el resultat.
El cas de Git LFS mereix un paràgraf a part. Molts equips assumeixen que si el mirall es completa sense errors, els fitxers grans també hi són. Fals. LFS emmagatzema el contingut fora de l'objecte Git normal. Un mirall pot mostrar tots els punters però mancar dels fitxers reals. L'única manera de verificar-ho és clonar des del destí i executar git lfs pull. Si no es fa abans que el proveïdor original caigui, l'equip es queda sense els actius crítics: models d'IA, datasets, vídeos o binaris.
L'autenticació és un altre punt cec. Un guió que corre amb variables d'entorn en una màquina local pot fallar si canvien els tokens o si l'equip de CI no té accés configurat al destí. Cal documentar qui pot redirigir els desenvolupadors i els pipelines de CI/CD cap a la rèplica, i provar aquest flux periòdicament. No es tracta de burocràcia, sinó d'evitar prendre decisions polítiques mentre la pipeline de producció està bloquejada.
Una llista de comprovació pràctica per a repositoris crítics hauria d'incloure: proveïdor principal, proveïdor de reserva, si el mirall és exacte o additiu, freqüència de sincronització, estat del contingut LFS, persones autoritzades per activar el failover i data de l'últim test de restauració. Aquesta llista no és un paper per arxivar: és la línia que separa un incident controlat d'un desastre.
A Q2BSTUDIO, com a empresa de desenvolupament de programari i tecnologia, treballem amb equips que necessiten anar més enllà de les solucions casolanes. Ajudem a dissenyar arquitectures de recuperació que integrin mirroring cross-provider amb serveis al núvol com AWS o Azure, garantint que el destí estigui en un domini de fallada diferent. També apliquem principis de ciberseguretat per protegir les credencials i els fluxos d'autenticació, i utilitzem intel·ligència artificial i agents IA per automatitzar la detecció d'anomalies en les sincronitzacions. El nostre enfocament combina el desenvolupament d'aplicacions a mida amb la integració de BI i Power BI per monitoritzar l'estat dels miralls en temps real.
La lliçó final és simple: un mirall de Git no és recuperació fins que es prova la ruta de fallada. Si l'equip no ha clonat des del destí, no ha tret LFS, no ha executat una build des de la rèplica ni ha mesurat el temps de commutació, llavors no té un pla de recuperació. Té una còpia. I quan ocorre la caiguda, la diferència es fa evident. No espereu que el proveïdor principal estigui caigut per descobrir que el vostre mirall no servia. Proveu-lo ara.
