Backups: o que aprendemos o día que un hosting caeu sen avisar
O día que case perdemos oito meses de contido dun cliente foi un martes calquera. O hosting compartido onde tiñan o WordPress —un provedor barato que contrataran eles mesmos antes de traballar con nós— tivo un fallo de disco e non houbo forma de recuperar nada da man do provedor. Non gardaban copias de máis de 24 horas. Cando nos chamaron xa era tarde.
Ben, non perdemos os oito meses do todo: tiñamos unha copia de hai tres semanas porque tocaramos o modelo pouco antes e eu garda sempre unha copia manual antes de meter man en produción. Pero esas tres semanas de entradas, pedidos e comentarios de clientes esfumáronse. Foi a última vez que deixei a xestión de backups en mans do hosting doutro sen comprobalo primeiro.
Desde entón aplicamos a mesma regra a cada proxecto novo, teña hosting propio ou do cliente: backup diario automatizado, gardado fóra do servidor onde vive o sitio (normalmente un bucket de S3 á parte, ás veces Backblaze se o orzamento é axustado), con polo menos 14 días de retención. Montalo custa pouco (un cron con mysqldump e rsync, ou un plugin decente se é WordPress) e aínda así a metade dos clientes que herdamos non tiñan nada disto configurado.
O que máis me sorprende non é a falta de backups en si. É a falta de curiosidade. Ninguén pregunta “e se cae?” ata que cae. E cando pasa, o custo real non é só o contido perdido: son as horas reconstruíndo a man, a confianza do cliente en que a súa web é algo serio e non un afeccionado cun dominio, e as decisións que se toman con présa e sen orzamento real detrás.
Con este cliente en concreto acabamos migrando todo a un VPS xestionado por nós, con backups automáticos e unha instantánea semanal completa do servidor. Custoulle máis ao mes que o hosting de tres euros que tiña antes, e discutímolo, claro. Pero cando lle expliquei que estaba pagando por non ter que vivir outra vez ese martes, entendeuno rápido.
Hai algo un pouco perverso en como se vende o hosting barato: parece que a única variable que importa é o prezo, cando en realidade estás comprando unha promesa de recuperación que case nunca se proba ata que fai falta. Agora, con calquera proxecto novo, facemos unha restauración real antes de dar o sitio por rematado. Non abonda con que o backup exista, ten que funcionar cando o precisas de verdade. Fixémolo mal unha vez e tardamos catro horas en decatarnos de que o backup automático levaba dous meses fallando en silencio porque ninguén miraba os logs.
Cantos dos sitios que xestionades vós teñen un backup que nunca probastes a restaurar?