No hay una frecuencia correcta, solo una consecuencia. El intervalo entre copias es exactamente cuánto trabajo perderás en el peor caso. Decide cuánto se le permite valer a ese número y el calendario se deduce de ahí.

Hazte la pregunta en voz alta

Si todo desapareciera ahora mismo y la copia más reciente fuera de anoche, ¿qué se ha perdido? En un sitio de presentación: nada. En una tienda: los pedidos de hoy, es decir, clientes que pagaron y de quienes no queda constancia.

Puntos de partida razonables

  • Sitio de presentación, que cambia una vez al mes: una copia completa semanal ya es generosa.
  • Blog o sitio de noticias: cada noche.
  • Tienda o sistema de reservas: archivos cada noche, base de datos cada hora.
  • Cualquier cosa que cobre de forma continua: archivos cada noche, base cada 15 minutos o envío continuo de registros.

Los archivos y la base no necesitan el mismo calendario

Los archivos cambian cuando despliegas. Las filas cambian cada minuto. Copiarlos por separado hace que la tarea frecuente y cara sea la pequeña.

# hourly, database only
15 * * * * /usr/bin/mysqldump --single-transaction --quick shop \
  | gzip > /srv/backup/db-$(date +\%H).sql.gz

# nightly, everything
30 2 * * * /usr/local/bin/restic backup /var/www /srv/backup
--single-transaction toma una instantánea coherente de InnoDB sin bloquear el sitio. Sin ella, una tienda con tráfico queda bloqueada durante todo el volcado; consulta Exportar sin bloquear el sitio.

Y antes de cada cambio

Un calendario no cubre la actualización que estás a punto de aplicar. Haz una copia antes; consulta Copia de seguridad antes de cada actualización.

Más a menudo solo es mejor hasta el punto en que nadie comprueba que haya funcionado. Una copia nocturna verificada gana a una copia cada hora que lleva fallando en silencio desde marzo; consulta Leer el registro de una copia fallida.