Cómo hacer una copia de seguridad de Plex sin capturar una base de datos incoherente

Eva Wong es la Redactora técnica y manitas residente en ZimaSpace. Una geek de toda la vida con pasión por los homelabs y el software de código abierto, se especializa en traducir conceptos técnicos complejos en guías accesibles y prácticas. Eva cree que el autoalojamiento debe ser divertido, no intimidante. A través de sus tutoriales, empodera a la comunidad para desmitificar las configuraciones de hardware, desde construir su primer NAS hasta dominar los contenedores Docker.

Para realizar una copia de seguridad completa de los datos de la aplicación Plex, detén Plex antes de copiar o crear una instantánea del sistema de archivos; para la base de datos principal únicamente, la copia de seguridad programada de Plex es el método compatible con la aplicación.

Plex escribe bases de datos, metadatos, preferencias y caché mientras el servidor está en ejecución, por lo que un trabajo de copia de seguridad genérico puede capturar archivos en momentos distintos. Eso no significa que todas las copias de seguridad en directo estén dañadas, pero sí que es más difícil confiar en una copia sin formato, a menos que la aplicación o la capa de almacenamiento coordinen la coherencia. Decide primero si necesitas la base de datos principal de Plex o el estado completo del servidor; después, utiliza un método que se ajuste a ese alcance y verifica una vía de restauración antes de dar por completa la copia de seguridad.

Separa la copia de seguridad de la base de datos principal de la copia de seguridad completa de los datos del servidor

Las tareas programadas de Plex pueden crear copias de seguridad de las bases de datos principales que almacenan el estado de reproducción y la información de coincidencias. Esto resulta útil para recuperar la base de datos, pero Plex indica explícitamente que no sustituye la copia de seguridad del directorio completo de datos de Plex Media Server. Trata esas dos copias como herramientas de recuperación diferentes, en lugar de asumir que un solo archivo lo cubre todo.

La documentación de copias de seguridad de Plex recomienda realizar una copia del directorio principal de datos del servidor y señala que la caché puede excluirse en algunas plataformas. Define deliberadamente el conjunto de archivos que se incluirán para que la caché temporal no aumente innecesariamente el archivo, mientras se mantienen protegidos los datos críticos de la base de datos y los metadatos.

Si tu objetivo es «restaurar el servidor exactamente como estaba», incluye el árbol persistente de datos de la aplicación y cualquier configuración específica de la plataforma que requiera Plex. Si solo quieres «recuperar el estado de reproducción y la base de datos principal de la biblioteca», la copia de seguridad programada de la base de datos puede ser una alternativa más pequeña y específica.

Detén Plex antes de realizar una copia sin formato del sistema de archivos

Para una copia de seguridad sencilla a nivel de archivos, detén el contenedor de Plex y confirma que se haya cerrado antes de copiar o crear una instantánea de la ruta de datos persistentes. Mantén el tiempo de inactividad al mínimo: detén el servicio, captura el punto coherente, reinícialo y, después, deja que la copia externa más lenta continúe desde la instantánea si tu sistema de archivos admite ese flujo de trabajo.

La documentación de la API de copias de seguridad de SQLite muestra por qué copiar una base de datos en directo es un problema de coordinación y no solo de tamaño de archivo. Una copia de seguridad compatible con la aplicación o una instantánea creada con el servicio detenido proporciona un estado de base de datos definido; copiar a ciegas archivos de base de datos, WAL y metadatos que están cambiando ofrece menos certeza sobre el punto de recuperación.

No detengas Plex durante horas mientras una copia de seguridad grande recorre un almacenamiento lento si tu NAS puede crear una instantánea instantánea. El patrón más seguro consiste en una breve pausa de escritura para establecer la coherencia, seguida de un flujo de trabajo de instantánea o archivado que permita que el servicio vuelva a estar disponible mientras la copia se traslada a otro lugar.

Aplica reglas de recuperación diferentes a los registros, la caché y los datos persistentes

La caché y los registros detallados pueden cambiar rápidamente y normalmente no necesitan la misma retención que la base de datos y los metadatos de Plex. Separar esas rutas hace que las copias de seguridad sean más pequeñas y que el límite de restauración sea más claro. También evita que un árbol de registros o caché demasiado voluminoso consuma el espacio reservado para el estado de la aplicación.

La guía de ZimaSpace para separar los registros de los contenedores de los datos de las aplicaciones explica por qué el estado de la aplicación, los registros y la caché tienen ciclos de vida y requisitos de recuperación diferentes. Plex se beneficia de la misma política, aunque los tres comiencen en una sola configuración de contenedor.

Si cambias el alcance de la copia de seguridad, realiza una prueba de restauración en una copia desechable o en un contenedor aislado. Una política de copias de seguridad no se valida solo con una carga correcta; se valida cuando Plex puede abrir la base de datos y los metadatos recuperados con el estado esperado del servidor.

Verifica la copia de seguridad restaurando un estado conocido

Elige un pequeño conjunto de datos que puedas verificar después de una restauración: el nombre del servidor, una biblioteca, un elemento visto, un elemento visto parcialmente y una configuración que conozcas. Una restauración de prueba debería recuperar esos datos sin pedirle a Plex que cree un servidor nuevo ni que reconstruya la biblioteca a partir de los archivos multimedia.

Plex documenta un procedimiento para restaurar una base de datos que comienza deteniendo el servidor y reemplazando la base de datos activa por una copia de seguridad. Aunque tu método de copia de seguridad completa sea diferente, el límite de detener el servicio antes de reemplazar la base de datos es una regla de recuperación útil.

Si la prueba de restauración falla, corrige el método de copia de seguridad antes de aumentar la retención o automatizar más copias. Recurre a la reparación de la base de datos solo cuando no se pueda restaurar una copia de seguridad verificada; no sobrescribas la última copia recuperable mientras experimentas con una base de datos activa dañada.

Soporte y Consejos

Más para leer

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.