Thanks for the hint. That pushed me towards the command line option which we can schedule to do whenever: 
2 Me gusta
Logré que esto funcionara, pero parece que la casilla de verificación de cargas no era realmente necesaria, ni entiendo su propósito. ¿Cuál es el propósito? Lo único que quiero son copias de seguridad en s3 en lugar de locales para mi servidor. El servidor solo tiene copias de seguridad automáticas semanales…
El Json también tuvo problemas… Pude hacerlo funcionar usando la referencia de otro sitio web. Sin embargo, nadie pudo subir ninguna imagen porque tenía marcada la casilla de verificación de cargas (como se describe aquí)… Desmarcar esa casilla solucionó el problema de carga de imágenes para los usuarios y sus fotos de perfil.
¿Cuál es el propósito de la carga de imágenes? Espero sinceramente que las imágenes estén dentro de las copias de seguridad de s3.
Tuve que seguir las instrucciones dos veces porque no entendí “cargas” y solo hice un bucket. Luego tuve que hacerlo de nuevo con 2 buckets, y luego tuve que quitar la casilla de verificación para las cargas. Podría ser bueno si hubiera un tema separado más simple para las copias de seguridad de s3… y solo copias de seguridad.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:List*",
"s3:Get*",
"s3:AbortMultipartUpload",
"s3:DeleteObject",
"s3:PutObject",
"s3:PutObjectAcl",
"s3:PutObjectVersionAcl",
"s3:PutLifecycleConfiguration",
"s3:CreateBucket",
"s3:PutBucketCORS"
],
"Resource": [
"arn:aws:s3:::classicaltheravadabucket",
"arn:aws:s3:::classicaltheravadabucket/*",
"arn:aws:s3:::classicaltheravadabackupbucket",
"arn:aws:s3:::classicaltheravadabackupbucket/*"
]
},
{
"Effect": "Allow",
"Action": [
"s3:ListAllMyBuckets",
"s3:*"
],
"Resource": "*"
}
]
}
2 Me gusta
Aunque creo que ese tema debería actualizarse para recomendar que la configuración de S3 se mueva a app.yml en lugar de a la base de datos, de esa manera puedes hacer una restauración de la base de datos desde la línea de comandos solo con el archivo yml y no tener que configurarla con un usuario y configuración de S3 antes de hacer una restauración.
1 me gusta
No estoy seguro de lo que estás hablando. Mis copias de seguridad están funcionando, mira la imagen.
Uso s3 porque las copias de seguridad de Digital Ocean son solo semanales, y si el servidor falla y se elimina, no es útil.
Por otro lado, espero que restaurar desde s3 o desde un bucket s3 descargado esté bien.
No estoy subiendo las imágenes, y espero que las copias de seguridad de s3 se estén respaldando, incluidas las imágenes (aunque muy pocas).
En general: no.
¿No tiene mucho sentido hacer una copia de seguridad de imágenes en un bucket de S3 en otro bucket de S3?
2 Me gusta
¿Puedes ser menos ambiguo?
Las instrucciones tenían 2 cubos s3. No pude hacer que eso funcionara.
Solo tengo un cubo s3. Espero que las imágenes estén incluidas en esa copia de seguridad… ¿es correcto?
Me imagino que las copias de seguridad locales funcionan de la misma manera, ¿verdad?
Por favor, responde con oraciones completas sobre mis preguntas. El tutorial también fue muy confuso.
1 me gusta
¿Qué hay de ambiguo en «no»? (Y, ¿qué no es ambiguo en «las copias de seguridad están respaldadas»? ;))
Lo intentaré de nuevo.
Si ha configurado las cargas en S3, entonces las cargas no se incluyen en su copia de seguridad.
2 Me gusta
Usemos el término “imágenes” en lugar de cargas, aunque puede ser otro medio.
De esta manera, no confundiremos el contenido de texto con una carga que estoy subiendo a s3.
Entonces, ¿los 62 MB de archivos de copia de seguridad en s3, como se muestra y se carga en este hilo, no incluyen imágenes?
Entonces, ¿cómo me aseguro de que las copias de seguridad tengan estas?
¿Las copias de seguridad locales también tienen las imágenes?
Cuando configuré s3 para “cargas (de medios)”, que también era ambiguo. Nadie pudo publicar imágenes porque fueron rechazadas de s3…
¿Hay alguna forma de tener copias de seguridad diarias tanto locales como en s3?
Me importa poco si se pierden 5 días de imágenes, somos un grupo mayormente basado en texto.
Pero me importaría si se perdieran 5 días de texto. Digital Ocean solo hace copias de seguridad de 7 días si les pagas.
Así que, aunque puedo hacer copias de seguridad diarias, si el droplet es hackeado o dañado, entonces perdemos esas copias de seguridad… Estoy empezando a pensar que no hay mucho valor añadido en s3.
Ojalá hubiera copias de seguridad sencillas similares a WordPress que me permitieran hacer copias de seguridad en mi cuenta de Google o Dropbox.
No, esa es una mala idea. Si subes un archivo de texto como adjunto, también es una subida, lo que causará confusión. Y el texto en una publicación se almacena en la base de datos. Así que me quedo con el término subidas.
Si tus subidas están en S3, no se incluyen en las copias de seguridad. En ese caso, las copias de seguridad solo contienen una copia de la base de datos. No importa si tus copias de seguridad son locales o en S3.
Si tus subidas no están en S3, se incluyen en las copias de seguridad. En ese caso, las copias de seguridad contienen una copia de la base de datos y una copia de las subidas. No importa si tus copias de seguridad son locales o en S3.
Si almacenas algo en S3, ya sean subidas o copias de seguridad de la base de datos, no se perderán si tu droplet de DO es hackeado o dañado. Así que no entiendo tu punto.
Dado que tus publicaciones son sobre copias de seguridad y no sobre subidas de archivos e imágenes, estoy moviendo estas a otro tema.
3 Me gusta
Me gustaría mover automáticamente mis copias de seguridad de S3 a Glacier, pero estoy confundido por los pasos enlazados en la primera publicación, que no explican mucho, tal vez porque hay cosas obsoletas.
¿Qué opciones se deben marcar aquí? 
¿Puedo preguntar de nuevo en caso de que alguien haya seguido estos pasos y sepa algo al respecto?
Además, ¿sabe qué causa estas fluctuaciones en las tarifas de S3?
Además, desde el lanzamiento del foro (septiembre de 2020), el tamaño de las copias de seguridad ha aumentado aproximadamente un 15%, pero las facturas de S3 se han duplicado, de 2,50 a 5 . ¿Alguna idea de por qué tanto?
Por eso me gustaría usar Glacier.
Editar: He seguido los pasos descritos aquí y veré cómo va.
1 me gusta
Bueno, no va. 
Mi configuración del ciclo de vida:
Mi bucket S3:
No hay copias de seguridad en Glacier.
Entonces… Dos preguntas para aquellos que han podido lograr esta transición automatizada de S3 a Glacier:
-
¿Qué podría estar mal en mi configuración?
-
La carga mínima de duración de almacenamiento en Glacier es de 90 días. ¿Significa eso que si hago 1 copia de seguridad al día, eventualmente se me cobrarán 90 copias de seguridad en Glacier cada mes?
Si este es el caso, entonces esta solución de Glacier no será una buena idea, a menos que reduzca mucho la frecuencia de mis copias de seguridad.
1 me gusta
¿Dónde se almacenan las copias de seguridad en el VPS?
1 me gusta
Añadí esto a la OP:
2 Me gusta
¿Podemos elegir la carpeta de las copias de seguridad o hay una solución alternativa sin codificación?
Estoy usando datos de almacenamiento de mi proveedor de hosting para poder montarlos y usarlos como locales, pero no se supone que se guarden en la ruta predeterminada.
1 me gusta
Si quieres que se guarde en un lugar diferente, tendrías que cambiar eso en tu app.yml.
2 Me gusta
Copias de seguridad automáticas en Backblaze B2
así es como lo he configurado para un sitio hipotético alojado en example.com
- crea una cuenta en backblaze (por ahora, no es necesario introducir el pago para <10 GB, que es gratis)
- crea un bucket (backblaze > Almacenamiento en la nube B2)
- nombre:
$sitename-discourse-$randomrellenado hasta 30 caracteres- en este ejemplo:
example-discourse-g87he56ht8vg - discourse necesita que el nombre del bucket solo contenga letras minúsculas, números y guiones
- sugiero mantenerlo en 30 caracteres o menos, ya que se muestra bien en la interfaz web de backblaze sin envolver
- en este ejemplo:
- bucket privado
- habilita el cifrado (SSE-B2)
- habilita el bloqueo de objetos
- nombre:
- crea una clave de aplicación (backblaze > cuenta > claves de aplicación)
- nombre de clave:
example-discourse - nombre del bucket (Permitir acceso a Bucket(s)):
example-discourse-g87he56ht8vg - capacidades: leer y escribir
- deja en blanco namePrefix y validDurationSeconds
- nombre de clave:
- configura los ajustes de B2 de discourse (discourse > administrador > ajustes)
backup_location:s3s3_backup_bucket:example-discourse-g87he56ht8vgs3_endpoint: esto se muestra en la página del bucket; asegúrate de anteponerhttps://s3_access_key_id: (del paso anterior)s3_secret_access_key: (del paso anterior)- ¡backblaze solo te muestra la clave una vez (al crearla)!
- por cierto, también puedes configurar estas como variables de entorno en tu archivo yml del contenedor en su lugar. esto te permitiría restaurar con solo ese archivo y nada más:
env:
## Copias de seguridad de Backblaze B2
# DISCOURSE_BACKUP_LOCATION: 's3' # descomenta para recuperar desde la línea de comandos
DISCOURSE_S3_ENDPOINT: 'https://....backblazeb2.com'
DISCOURSE_S3_BACKUP_BUCKET: 'example-discourse-g87he56ht8vg'
DISCOURSE_S3_ACCESS_KEY_ID: '...'
DISCOURSE_S3_SECRET_ACCESS_KEY: '...'
# DISCOURSE_DISABLE_EMAILS: 'non-staff' # descomenta para deshabilitar correos electrónicos durante una restauración de prueba
## puedes restaurar sin más datos que este archivo yml del contenedor.
## descomenta DISCOURSE_BACKUP_LOCATION arriba, compila el contenedor (./launcher rebuild ...),
## y luego ejecuta esto dentro del contenedor (restaurará desde el bucket B2):
## discourse enable_restore
## discourse restore <example-com-...tar.gz> # elige el nombre del archivo de restauración navegando por la interfaz web de B2
## recuerda deshabilitar la restauración después
- configura la retención de copias de seguridad
- discourse:
backup_frequency: 1 (copias de seguridad diarias en este ejemplo, pero podrías hacerlo semanal)maximum_backups: ignora este ajuste, deja que backblaze se encargue
s3_disable_cleanup: true (Evita la eliminación de copias de seguridad antiguas de S3 cuando hay más copias de seguridad que el máximo permitido)
- backblaze (ve a la configuración de tu bucket):
- Bloqueo de objetos (Política de retención predeterminada): 7 días
- Ajustes del ciclo de vida (personalizado):
fileNamePrefix:default/example-com(opcional)daysFromUploadingToHiding: 8 días- esto debe ser el bloqueo de objetos + 1
daysFromHidingToDeleting: 1 día
para resumir la retención en este ejemplo:
- discourse:
- discourse crea copias de seguridad cada 1 día
- cada archivo de copia de seguridad es inmutable durante 7 días después de cargarlo en B2 (bloqueo de objetos). esto te protege contra accidentes, ransomware, etc.
- 8 días después de la carga, el bloqueo de objetos de la copia de seguridad expira. como vuelve a ser mutable, una regla del ciclo de vida puede ocultar el archivo de copia de seguridad
- la siguiente parte de la regla del ciclo de vida elimina cualquier archivo 1 día después de que se oculte
así obtienes copias de seguridad diarias. el tiempo de retención es de una semana durante la cual las copias de seguridad no se pueden eliminar sin importar qué. luego, las copias de seguridad se eliminan 2 días después. así que, en realidad, una copia de seguridad dura unos 9 días.
espero que eso ayude a alguien 
en segunda reflexión, quizás sea mejor dejar que discourse gestione la retención (maximum_backups). de esa manera, tus copias de seguridad no empezarán a caducar automáticamente si discourse está caído. no querrías que un reloj corriera sobre ellas mientras intentas recuperarte. si eligieras esa opción, podrías configurar maximum_backups=8 y s3_disable_cleanup=false en este ejemplo y no usar una política de ciclo de vida en B2. aún así usarías la política de bloqueo de objetos (7 días), sin embargo.
edición: de hecho, creo que todavía necesitas una política de ciclo de vida de B2 porque creo que los archivos solo se ‘ocultan’ y no se eliminan cuando un cliente S2 los elimina. estoy usando la política " Mantener solo la última versión del archivo ", que es equivalente a daysFromHidingToDeleting=1, daysFromUploadingToHiding=null.
supongo que piénsalo y decide qué enfoque es el adecuado para ti.
por cierto, me doy cuenta de que hay algunas idas y venidas en esta publicación. creo que es informativa tal como está, pero si alguien quiere, podría hacer otra publicación un poco más simple con mis recomendaciones reales.
6 Me gusta
Si los pones en variables de entorno como se describe en Configurar un proveedor de almacenamiento de objetos compatible con S3 para cargas entonces puedes restaurar tu sitio en un nuevo servidor desde la línea de comandos solo con tu archivo yml.
El resto parece un buen plan.
3 Me gusta
discourse restore <backup.tar.gz>
¿esto buscará en tu bucket si tienes las variables de entorno configuradas? bastante genial si es así.
y en ese caso, también podrías configurarlas manualmente con export en bash en el improbable caso de que tengas que recuperarlo. es decir, si no quieres mantener secretos en tu yml de contenedor por alguna razón.
1 me gusta
Solo para confirmar, una vez que me haya mudado a las copias de seguridad de S3 y haya probado que funcionan, ¿puedo eliminar de forma segura el contenido de esa carpeta para recuperar el espacio utilizado?