Si eres autoalojado, debes mantener copias de seguridad fuera del sitio por si ocurre algún problema catastrófico con tu servidor. Imagina que tu proveedor de servidores quiebra un día sin previo aviso, o que de alguna manera logras borrar /var/discourse, eliminando toda tu instalación.
Lo mínimo indispensable
Asegúrate de que las copias de seguridad estén habilitadas.
Configuraciones del sitio a considerar:
enable backups: activado (activado por defecto)backup frequency: ¿Cuántos datos estás dispuesto a perder? (Predeterminado: 7 días). @pfaffman recomienda uno díabackup time of day: ¿Cuándo deseas que tu foro esté en modo solo lectura mientras se realiza la copia de seguridad?backup with uploads: activado, a menos que tengas las subidas almacenadas en otro lugar o las respaldes de otra manera. (Predeterminado: activado)maxiumum backups: ¿Qué tan paranoico eres? ¿Cuánto espacio en disco tienes? (Predeterminado: 5)
Esto te permitirá restaurar una copia de seguridad reciente en caso de que tu base de datos se corrompa, pero no te protegerá si tu servidor de Discourse desaparece.
Copias de seguridad remotas
Para restaurar tu sitio en un nuevo servidor, como mínimo necesitas la copia de seguridad que crea Discourse. Será mucho más fácil configurar un nuevo servidor si tienes los contenedores en /var/discourse//containers.
Exactamente cómo mantener copias de seguridad fuera del sitio está un poco fuera del alcance de este documento, pero un método es usar una herramienta como rsync para copiar los datos a un servidor remoto. Hay docenas de guías para hacerlo; encuentra una que tenga sentido para ti.
Los archivos en /var/discourse/containers cambian con poca frecuencia, por lo que respaldarlos manualmente solo cuando realizas cambios no es tan doloroso. Por lo general, contienen tu configuración SMTP y plugins, que son razonablemente fáciles de reconstruir de memoria, pero preferirías no tener que hacerlo en una emergencia. Si eso llegara a ocurrir, aún podrías poner las cosas en marcha nuevamente faltando algunos plugins y con el correo roto, y resolver el resto mientras el sitio funciona de manera precaria.
Copias de seguridad en S3
La forma más conveniente de mantener copias de seguridad fuera del sitio es enviarlas a S3, como se describe en Set up file and image uploads to S3. Si haces eso y guardas tu configuración de S3 en algún lugar donde puedas encontrarla (o en tu archivo app.yml), podrás restaurar tu sitio directamente desde S3 cuando tengas configurado el nuevo servidor.
Es posible incrustar configuraciones en tu archivo app.yml. Si incluyes algo como esto en la sección env de tu app.yml, estas configuraciones desaparecerán de la interfaz web y podrás restaurar una copia de seguridad desde la línea de comandos en Restore a backup from the command line sin tener que crear una cuenta de administrador e iniciar sesión.
DISCOURSE_S3_ACCESS_KEY_ID: 'clave'
DISCOURSE_S3_SECRET_ACCESS_KEY: 'secreto'
DISCOURSE_BACKUP_LOCATION: 's3'
DISCOURSE_ENABLE_S3_UPLOADS: true
DISCOURSE_S3_BACKUP_BUCKET: 'mi-bucket-de-respaldo'
DISCOURSE_S3_REGION: 'us-west-1'
Si también tienes subidas en S3 y confías en que tu proveedor de S3 sea estable, podrías configurar Discourse para que respalde solo la base de datos (ver configuración anterior). Esto evitará que almacenes múltiples copias de todas tus subidas. Si eliges esta opción, debes realizar una restauración de prueba para asegurarte de que todas tus subidas están realmente en S3.
La práctica hace al maestro
Aunque tener una copia de tu copia de seguridad más reciente es lo mínimo que necesitarás para restaurar en una crisis, si quieres estar realmente seguro de que tus copias de seguridad funcionan, deberías probarlas al menos una vez, si no es de forma periódica. Inicia un nuevo servidor y verifica si puedes restaurar desde una copia de seguridad.