Copias de seguridad

Evita que backups mal hechos borren RAW, XMP y catálogos

Actualizado en July 2026

Imagen relacionada con evita que backups

Un backup mal configurado puede borrar archivos RAW, sidecars XMP y catálogos de Lightroom, dejando portafolios inaccesibles justo cuando más falta hacen. Sucede en WordPress cuando hay mucho volumen, por plugins de galería conflictivos o cuando el sistema de copia trata los medios grandes como contenidos recreables en vez de activos irremplazables.

Los backups para portfolios fotográficos deben preservar imágenes en alta resolución, metadatos EXIF/IPTC/XMP y catálogos de Lightroom; usar almacenamiento S3/Backblaze B2 con multipart upload y deduplicación, permitir restauración selectiva de medios grandes y ofrecer compatibilidad con plugins de galerías. Revisar configuraciones y realizar pruebas de restauración valida la estrategia y reduce riesgo y coste inesperado.

Índice

Anuncio

Backups para portfolios fotográficos: factores clave

El plan de backups debe preservar imágenes en alta resolución, metadatos EXIF/IPTC/XMP y catálogos.

Qué incluye lo mínimo viable

Debe incluir la exportación de la base de datos (SQL), copia íntegra de wp-content/uploads y los archivos sidecar (.xmp). Use checksums por archivo para validar integridad y evitar copias corruptas; además, almacene esos checksums de forma accesible (archivo .sha256 por cada objeto o un manifest CSV/JSON con ruta+sha256+fecha) y automatice la comparación tras la copia con la misma herramienta que hizo el upload (rclone check, aws s3api head-object con metadata propia o utilidades de SDK).

Retención y versionado adecuados

Mantenga versiones incrementales diarias y copias completas semanales. Conserve 30-90 días para ediciones activas y un archivo anual en frío con checksum.

Métricas que importan al decidir

Defina RPO máximo de 24 horas para trabajo activo y RTO según necesidad de disponibilidad. Para un estudio que entrega fotos al día siguiente, el RTO debe ser de horas, no de días.

Evita que backups mal hechos borren RAW, XMP y catálogos

Perfiles concretos y soluciones recomendadas

El tamaño de los originales y la velocidad de restauración marcan la estrategia. Aquí hay tres perfiles habituales con pasos claros.

Portfolio freelance con < 500 GB activos

Recomendación: plugin de backup + Backblaze B2 con deduplicación por hash. Mantener copia local semanal y pruebas trimestrales de restore.

Estudio profesional 0.5–5 TB activos

Recomendación: S3 (eu-west-1) con lifecycle a Glacier y multipart upload. Habilitar server-side encryption (SSE-KMS) y roles IAM limitados.

Agencia o multisite con catálogos

Recomendación: solución gestionada (BlogVault, ManageWP) con integración S3 y backups asíncronos. Asegurar exportes de catálogos externos (Lightroom) y rutas de plugins de galería.

Anuncio

Errores frecuentes que rompen catálogos y metadatos

El error más frecuente en este punto es confiar solo en backups de base de datos. La mayoría de plugins hacen DB+media parciales y dejan fuera sidecars XMP.

Qué suele omitir la mayoría de guías

Ignoran los directorios de plugins de galería como NextGEN o FooGallery. Esos plugins guardan relaciones y tamaños que deben incluirse en la copia.

Restauración parcial que falla

Un caso habitual: se restaura la base de datos pero faltan los sidecars XMP; el catálogo Lightroom pierde etiquetas. El resultado: buscar y reetiquetar miles de imágenes manualmente.

No basta con conservar los originales: algunos procesos de regeneración de miniaturas y ciertos plugins de optimización pueden eliminar o no preservar EXIF/IPTC/XMP. Esto significa que, aunque el original RAW/TIFF esté a salvo, las versiones JPEG que usa la web pueden perder etiquetas, coordenadas GPS o créditos IPTC si se re-procesan con herramientas que aplican -strip o reescriben metadata.

Por eso, además de guardar sidecars .xmp y el RAW original, conviene comprobar periódicamente que las miniaturas mantienen los campos críticos (autor, copyright, título, IPTC) con una herramienta de lectura de metadatos (por ejemplo una comprobación con exiftool) y establecer workflows en los que la regeneración se haga en staging y se valide antes de aplicar al sitio en producción.

Qué almacenar exactamente y por qué

La carpeta wp-content/uploads completa debe formar parte del backup. No convertir RAW/TIFF a JPEG en el proceso de copia.

Archivos obligatorios

Metadatos y catálogos

Exportar catálogos de Lightroom regularmente en formato .lrcat o como exportes XMP. Incluir esos ficheros en la copia offsite.

Conservación de versiones activas: conservar al menos 90 días de incrementales para trabajo en curso y un archivo anual con checksums SHA256 para archivos originales.

Herramientas y configuraciones recomendadas

Combine un plugin de WordPress con un proveedor cloud que admita multipart upload y políticas lifecycle. El plugin debe poder incluir rutas personalizadas y ejecutar comandos WP-CLI.

Plugins útiles y límites prácticos

UpdraftPlus, BlogVault y VaultPress permiten backups programados y restore selectivo. Verifique que incluyan la carpeta uploads completa y permitan excluir miniaturas generadas.

Criterios para elegir el proveedor cloud

Priorizar coste/GB, egress y región EU por cumplimiento GDPR. Backblaze B2 suele ser la opción más barata para almacenamiento masivo.

Comparativa rápida de proveedores

Proveedor Coste aproximado Egress Multipart Región EU
Backblaze B2 ~$0.005/GB-mes (2024) $0.01/GB Sí (EU disponible)
AWS S3 Standard ~$0.024/GB-mes (2024) Variable, más caro eu-west-1, eu-central-1
Google Cloud ~$0.02/GB-mes (2024) Variable

Anuncio

Flujo de backup para portfolios

1. Orígenes
RAW/TIFF + JPEG + XMP + catálogos (.lrcat)
2. Pre-proceso
Checksum SHA256, deduplicación por hash
3. Upload
Multipart upload a S3/B2, encriptado SSE
4. Lifecycle
30 días S3-IA, 365 días Glacier/Archivo

Configuración práctica: S3 y Backblaze B2 paso a paso

Estos pasos sirven para subir originales grandes sin perder metadatos y con integridad verificada. Use claves con permisos mínimos y rotarlas según política de seguridad.

S3: pasos clave y comandos

Crear bucket en eu-west-1 y activar versionado y SSE-KMS. Configurar lifecycle para mover objetos a S3-IA y Glacier.

Bash aws s3api create-bucket --bucket mi-bucket-portfolio --region eu-west-1 --create-bucket-configuration LocationConstraint=eu-west-1 aws s3api put-bucket-versioning --bucket mi-bucket-portfolio --versioning-configuration Status=Enabled

Habilitar multipart para archivos mayores de 100 MB. Comprobar ETag o calcular MD5 para validar integridad.

Backblaze B2

Crear application key con permisos limitados. Usar rclone para subir con multipart y deduplicación local previa.

Bash rclone config create b2 backblaze b2_account_id YOUR_ID b2_account_key YOUR_KEY rclone sync /ruta/uploads b2:mi-bucket-portfolio/uploads --b2-chunk-size 100M --checksum

Usar --checksum para que rclone compare hashes antes de subir y evitar duplicados.

Cuando se trabaja con ficheros muy grandes conviene distinguir entre la verificación que ofrece el proveedor y la verificación que necesita un fotógrafo. En AWS S3, la ETag que devuelve un objeto no es un MD5 fiable cuando se ha usado multipart upload: para archivos subidos en varias partes la ETag refleja internamente la composición por partes y no coincide con el checksum SHA256 o MD5 del fichero completo. Por eso, además de usar multipart correctamente (partes mínimas de 5 MB y tamaños de chunk coherentes con rclone/SDK), es buena práctica generar un manifiesto local de checksums (por ejemplo un archivo companion nombre.jpg.sha256 con el sha256sum) y subirlo junto al objeto, o almacenar el checksum en metadata/object-tags durante el proceso de subida.

Backblaze B2, por su parte, expone SHA1 en su API y herramientas como rclone pueden comparar checksums antes de subir (--checksum); sin un manifiesto propio no se puede confiar en ETag para validar integridad tras un multipart upload.

Restauraciones selectivas y validación de integridad

La restauración selectiva evita rehacer toda la web y reduce tiempos y costes. Si falla la integridad, hay que volver a descargar el objeto original.

Pasos para restaurar un RAW/TIFF suelto

Identificar el checksum en el índice de backups y localizar el objeto en el bucket. Descargar con AWS CLI o rclone y validar el checksum local.

Bash aws s3 cp s3://mi-bucket-portfolio/uploads/2024/03/foto.CR2 ./foto.CR2 sha256sum foto.CR2

Copiar el archivo a wp-content/uploads con permisos correctos y regenerar miniaturas si es necesario. Usar WP-CLI para regenerar miniaturas: wp media regenerate --only-missing.

Checklist de pruebas de restore

Anuncio

Costes, deduplicación y retención para fotógrafos

La deduplicación por hash reduce transferencias y coste de almacenamiento. El movimiento a almacenamiento frío reduce coste mensual pero eleva tiempo de recuperación.

Cómo calcular costes orientativos

2 TB activos, retención 90 días. Backblaze B2 (~$0.0,005 $/GB-mes) resulta más barato que S3 para grandes volúmenes.

Estrategia práctica para ahorrar

Hacer deduplicación local por hash antes del upload y comprimir sin pérdida cuando proceda. Mover archivos antiguos a archivo frío tras 365 días.

Integración con galerías y catálogos

No solo se respaldan imágenes; se respaldan relaciones que guardan las galerías. Incluir en la copia las rutas de plugins y los metadatos asociados.

NextGEN y FooGallery

Respaldar carpetas dentro de wp-content/plugins relacionadas con la galería. Respaldar tablas específicas en la base de datos que guardan relaciones y metadatos.

Catálogos Lightroom y sidecars XMP

Exportar catálogos .lrcat y sidecars XMP periódicamente. Los sidecars enlazan edits y etiquetas a los originales; sin ellos se pierden las ediciones.

Lightroom guarda el catálogo (.lrcat) y las previsualizaciones en la carpeta donde el usuario crea el catálogo; además genera archivos de bloqueo (.lrcat.lock) mientras está abierto. Para respaldos fiables conviene incluir las copias automáticas que Lightroom crea (las backups zipeadas con fecha desde Catalog Settings → Backup), y asegurar que el proceso de backup no copie el .lrcat mientras Lightroom está en uso (las copias en caliente pueden quedar corruptas). Otro punto clave es la sincronización de sidecars: si en Lightroom no está activada la opción «Automatically write changes into XMP», las ediciones quedan solo en el .lrcat; por tanto, los sidecars .xmp solo existen si se habilita esa opción o se exportan manualmente.

Automatizar un flujo que copie los .lrcat respaldados y los sidecars, y que respete el cierre del catálogo, reduce el riesgo de copiar catálogos incompletos o corruptos y facilita restauraciones coherentes entre originales y metadatos.

Opinión y matiz técnico

Una copia completa con versionado y checksums funciona bien, pero solo si se prueban restauraciones periódicas; sin pruebas, la copia es un archivo inservible. Por eso se recomienda validar 1 archivo grande y 10 archivos medios cada trimestre, además de conservar un registro de checksums.

Para una auditoría técnica y presupuesto adaptado, está disponible el servicio de mantenimiento especializado que incluye pruebas de restauración y configuración de S3/B2.

No aplica si los originales no se alojan en WordPress (por ejemplo Cloudinary, SmugMug o CDN externo), o si el sitio solo muestra imágenes ligeras y no guarda RAW/XMP. En esos casos, centralice backups en el proveedor de almacenamiento original.

Anuncio

Preguntas frecuentes

¿Qué debo respaldar además de la base de datos?

Respaldar la carpeta completa wp-content/uploads y los sidecars XMP. Sin esos ficheros, los catálogos y metadatos quedan incompletos.

¿Cómo asegurar que no se pierden etiquetas e IPTC?

Incluir sidecars .xmp y exportes de catálogo en cada ciclo de backup. Verificar EXIF/IPTC en las pruebas de restauración.

¿Sirven los plugins gratuitos como UpdraftPlus?

Sí, sirven para backups básicos, pero conviene revisar límites con archivos grandes. Para volúmenes altos se recomienda versión de pago o solución gestionada.

¿Con qué frecuencia probar restauraciones?

Probar restauraciones parciales trimestralmente y completas cada 12 meses. Las pruebas detectan corrupción y fallos en las políticas lifecycle.

¿Cómo reducir costes sin perder integridad?

Hacer deduplicación por hash y lifecycle hacia almacenamiento frío. Comprimir sin pérdida cuando se acepte para el workflow.

¿Cómo afecta el RGPD a estos backups?

Los backups con datos personales deben cumplir Reglamento (UE) 2016/679 y LOPDGDD 2018. Asegurar control de accesos, cifrado y plazos de supresión cuando procedan.

El plan concreto

Paso 1: automatizar export diario de la base de datos con WP-CLI y guardar en destino offsite. Paso 2: sincronizar uploads con rclone a Backblaze B2 usando checksum y chunk-size para multipart. Paso 3: configurar lifecycle y versionado en el bucket; mantener 90 días de incrementales. Paso 4: programar pruebas trimestrales de restore parcial y auditoría anual de integridad.

Referencias y evidencia visual: la guía oficial de WordPress sobre backups y la documentación de precios de Backblaze B2 ofrecen detalles técnicos y ejemplos de configuración. Documentación WordPress sobre backups y Precios Backblaze B2.

RESUMIR CON IA: Extrae lo importante

Comparte este artículo:

Josu Barrios

Josu Barrios

Somos especialistas en mantenimiento WordPress para empresas, profesionales y tiendas online. Contamos con experiencia en seguridad web, optimización de rendimiento, actualizaciones, copias de seguridad y resolución de incidencias técnicas, ayudando a que cada sitio funcione de forma rápida, estable y protegida. Nuestro enfoque combina soporte técnico profesional, buenas prácticas de seguridad y seguimiento continuo para ofrecer un servicio fiable, transparente y orientado a resultados reales.