Backup y restore

NamiDB guarda todo en el bucket — manifest, WAL, SSTs, schema. No hay tabla externa de locks, ni servicio separado de metadata, ni estado por tenant viviendo en ningún otro lado.

El backup es aws s3 sync. El restore es aws s3 sync en la dirección opuesta.

Backup por namespace

aws s3 sync \
  s3://my-bucket/data/tenant-acme/ \
  ./backups/tenant-acme-2026-05-19/

Replicación cross-region / cross-bucket

aws s3 sync \
  s3://my-bucket/data/ \
  s3://my-backup-bucket-dr/data/

Esto se puede hacer online — los lectores y escritores pueden estar activos durante el sync. El peor caso es que el backup capture una versión del manifest levemente más vieja que la que está en vivo. Las semánticas de snapshot + epoch fencing de NamiDB garantizan que el estado capturado es internamente consistente.

Restore

Para restaurar un snapshot a un bucket nuevo:

aws s3 sync ./backups/tenant-acme-2026-05-19/ s3://my-new-bucket/data/tenant-acme/

Después, abrir el namespace en la nueva URI. NamiDB lee el manifest y arranca normalmente.

Migrar entre backends

Misma idea — sync entre dos URIs cualesquiera:

# file:// → s3://
aws s3 sync /var/lib/namidb/prod/ s3://my-bucket/data/prod/

# s3:// → file://
aws s3 sync s3://my-bucket/data/prod/ /var/lib/namidb/prod/

# s3:// → gs:// (usar gcloud rsync)
gsutil -m rsync -r s3://my-bucket/data/prod/ gs://my-bucket/data/prod/

Después del sync, apuntar el cliente a la nueva URI. El grafo es el mismo.

¿Y las escrituras in-flight durante un restore?

Restaurar mientras hay writers activos los va a fencear vía epoch CAS — el manifest contra el que el writer está corriendo es sobrescrito, el siguiente intento de commit del writer devuelve 412 Precondition Failed y el writer re-bootstrapea. No hay corrupción posible porque el manifest es la única raíz autoritativa.

Para un restore limpio, parar los writers, hacer el sync y después volver a levantar los writers.