Thanks for the hint. That pushed me towards the command line option which we can schedule to do whenever: 
2 Mi Piace
Sono riuscito a farlo funzionare, ma sembra che la casella di controllo degli upload non fosse realmente necessaria, né ne capisco lo scopo. Qual è lo scopo? L’unica cosa che voglio sono i backup su s3 invece che locali per il mio server. Il server ha solo backup automatici settimanali…
Anche il Json ha avuto problemi… Sono riuscito a farlo funzionare usando un riferimento ad un altro sito web. Tuttavia, nessuno è riuscito a caricare immagini perché avevo selezionato la casella di controllo degli upload (come descritto qui)… Deselezionare quella casella ha risolto il problema di caricamento delle immagini per gli utenti e le loro foto profilo.
Qual è lo scopo del caricamento delle immagini? Spero vivamente che le immagini siano incluse nei backup s3.
Ho dovuto seguire le istruzioni due volte perché non avevo capito “uploads” e avevo creato solo un bucket. Poi ho dovuto rifare tutto con 2 bucket, e infine ho dovuto rimuovere la casella di controllo per gli upload. Potrebbe essere utile se ci fosse un argomento separato e più semplice per i backup s3… e solo per i backup.
{
"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 Mi Piace
Anche se penso che quell’argomento dovrebbe essere aggiornato per raccomandare che la configurazione S3 venga spostata in app.yml piuttosto che nel database, in questo modo è possibile eseguire un ripristino del database dalla riga di comando con solo il file yml e non è necessario configurarlo con un utente e una configurazione s3 prima di eseguire un ripristino.
1 Mi Piace
Non sono sicuro di cosa stai parlando. I miei backup funzionano, vedi l’immagine.
Uso s3 perché i backup di DigitalOcean sono solo settimanali e, se il server si blocca e viene eliminato, non è utile.
D’altra parte, spero che il ripristino da s3 o da un bucket s3 scaricato vada bene.
Non sto caricando le immagini e spero che i backup s3 vengano sottoposti a backup includendo le immagini (anche se molto poche).
In generale: no.
Non ha molto senso eseguire il backup delle immagini in un bucket S3 in un altro bucket S3?
2 Mi Piace
Puoi essere meno ambiguo?
Le istruzioni avevano 2 bucket S3. Non sono riuscito a farlo funzionare.
Ho solo un bucket S3. Spero che le immagini siano incluse in quel backup… è corretto?
Immagino che i backup locali funzionino allo stesso modo, giusto?
Per favore, rispondi in frasi complete riguardo alle mie domande. Anche il tutorial era molto confuso.
1 Mi Piace
Cosa c’è di ambiguo in “no”? (E cosa non è ambiguo in “i backup vengono sottoposti a backup” 
)
Ci riprovo.
Se hai configurato il caricamento su S3, i caricamenti non sono inclusi nel tuo backup.
2 Mi Piace
Usiamo il termine “immagini” invece di caricamenti, anche se può trattarsi di altri media.
In questo modo non confondiamo il contenuto testuale con un caricamento che sto caricando su s3.
Quindi i 62 MB di file di backup su s3, come illustrato e caricato in questo thread, non includono le immagini?
Quindi, come posso assicurarmi che i backup contengano questi?
Anche i backup locali contengono le immagini?
Quando ho configurato s3 per “caricamenti (di media)”, che era anche ambiguo. Nessuno poteva pubblicare immagini perché venivano rifiutate da s3…
C’è un modo per avere backup giornalieri sia locali che su s3?
Mi importerebbe poco se venissero perse 5 giorni di immagini, siamo principalmente un gruppo basato sul testo.
Ma mi importerebbe se venissero persi 5 giorni di testo. Digital Ocean fa solo backup di 7 giorni se paghi.
Quindi, anche se posso eseguire il backup giornalmente, se il droplet viene hackerato o danneggiato, allora perdiamo quei backup… Sto iniziando a pensare che non ci sia molto valore aggiunto in s3.
Vorrei che ci fossero backup semplici simili a WordPress che mi permettano di eseguire il backup sul mio account Google o Dropbox.
No, è una cattiva idea, se carichi un file di testo come allegato, è anche un caricamento, causerà confusione. E il testo in un post viene memorizzato nel database. Quindi mi attengo al termine caricamenti.
Se i tuoi caricamenti sono su S3, non sono inclusi nei backup. In tal caso i backup contengono solo una copia del database. Non importa se i tuoi backup sono locali o su S3.
Se i tuoi caricamenti non sono su S3, sono inclusi nei backup. In tal caso i backup contengono una copia del database e una copia dei caricamenti. Non importa se i tuoi backup sono locali o su S3.
Se stai archiviando qualcosa su S3, siano essi caricamenti o backup del database, non andranno persi se la tua droplet DO viene hackerata o danneggiata. Quindi non capisco il tuo punto.
Poiché i tuoi post riguardano i backup e non i caricamenti di file e immagini, li sto spostando in un altro argomento.
3 Mi Piace
Vorrei spostare automaticamente i miei backup S3 su Glacier ma sono confuso dai passaggi collegati nel primo post, che non spiegano molto, forse perché ci sono cose obsolete.
Quali opzioni dovrebbero essere selezionate qui? 
Posso chiedere di nuovo nel caso qualcuno abbia eseguito questi passaggi e ne sappia qualcosa?
Inoltre, sapete cosa causa queste fluttuazioni nelle tariffe S3?
Inoltre, dal lancio del forum (settembre 2020), la dimensione dei backup è aumentata di circa il 15%, ma le fatture S3 sono raddoppiate, da 2,50$ a 5$. Avete qualche idea sul perché così tanto?
Ecco perché vorrei usare Glacier.
Modifica: Ho seguito i passaggi descritti qui e vedrò come va.
1 Mi Piace
Beh, non va. 
La mia configurazione del ciclo di vita:
Il mio bucket S3:
Nessun backup è su Glacier.
Quindi… Due domande per coloro che sono riusciti a realizzare questa transizione automatizzata da S3 a Glacier:
-
Cosa potrebbe esserci di sbagliato nella mia configurazione?
-
L’addebito minimo per la durata di archiviazione in Glacier è di 90 giorni. Ciò significa che se eseguo 1 backup al giorno, alla fine mi verranno addebitati 90 backup in Glacier ogni mese?
Se questo è il caso, allora questa soluzione Glacier non sarà una buona idea, a meno che non riduca molto la frequenza dei miei backup.
1 Mi Piace
dove sono archiviati i backup nel VPS?
1 Mi Piace
Ho aggiunto questo all’OP:
2 Mi Piace
Possiamo scegliere la cartella dei backup o esiste una soluzione alternativa senza programmazione?
Sto utilizzando uno spazio di archiviazione dati dal mio provider di hosting che posso montare e utilizzare come locale, ma non è previsto che venga salvato nel percorso predefinito.
1 Mi Piace
Se si desidera salvarlo in un posto diverso, è necessario modificarlo in app.yml
2 Mi Piace
Backup Automatici su Backblaze B2
Ecco come l’ho configurato per un sito ipotetico ospitato su example.com
- Crea un account su Backblaze (al momento, non è necessario inserire dati di pagamento per i <10 GB gratuiti)
- Crea un bucket (Backblaze > Archiviazione Cloud B2)
- nome:
$sitename-discourse-$randomesteso a 30 caratteri- in questo esempio:
example-discourse-g87he56ht8vg - Discourse richiede che il nome del bucket contenga solo lettere minuscole, numeri e trattini
- Suggerisco di mantenerlo entro i 30 caratteri in modo che venga visualizzato bene nell’interfaccia web di Backblaze senza andare a capo
- in questo esempio:
- bucket privato
- abilita la crittografia (SSE-B2)
- abilita il blocco degli oggetti
- nome:
- Crea una chiave applicativa (Backblaze > Account > Chiavi App)
- keyName:
example-discourse - bucketName (Consenti accesso ai Bucket):
example-discourse-g87he56ht8vg - capabilities: read and write (lettura e scrittura)
- lascia vuoti namePrefix e validDurationSeconds
- keyName:
- Configura le impostazioni B2 di Discourse (Discourse > Admin > Settings)
backup_location:s3s3_backup_bucket:example-discourse-g87he56ht8vgs3_endpoint: questo viene mostrato nella pagina del bucket – assicurati di anteporrehttps://s3_access_key_id: (dal passaggio precedente)s3_secret_access_key: (dal passaggio precedente)- Backblaze ti mostra la chiave solo una volta (al momento della creazione)!
- tra l’altro, puoi anche impostare queste variabili d’ambiente nel tuo file yml del container. questo ti permetterebbe di ripristinare con solo quel file e nient’altro:
env:
## Backup Backblaze B2
# DISCOURSE_BACKUP_LOCATION: 's3' # decommenta per recuperare da cli
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' # decommenta per disabilitare le email durante un ripristino di prova
## puoi ripristinare senza dati oltre a questo file yml del container.
## decommenta DISCOURSE_BACKUP_LOCATION sopra, compila il container (./launcher rebuild ...),
## ed esegui questo all'interno del container (ripristinerà dal bucket B2):
## discourse enable_restore
## discourse restore <example-com-...tar.gz> # scegli il nome del file di ripristino sfogliando l'interfaccia web di B2
## ricorda di disabilitare il ripristino in seguito
- Configura la conservazione dei backup
- Discourse:
backup_frequency: 1 (backup giornalieri in questo esempio, ma potresti farli settimanali)maximum_backups: ignora questa impostazione – lascia che sia Backblaze a gestirla
s3_disable_cleanup: true (Impedisce la rimozione dei vecchi backup da S3 quando ci sono più backup del massimo consentito)
- Backblaze (vai alle impostazioni del tuo bucket):
- Object Lock (Retention Policy predefinita): 7 giorni
- Impostazioni Ciclo di Vita (personalizzate):
fileNamePrefix:default/example-com(opzionale)daysFromUploadingToHiding: 8 giorni- questo dovrebbe essere object lock + 1
daysFromHidingToDeleting: 1 giorno
per riassumere la conservazione in questo esempio:
- Discourse:
- Discourse crea backup ogni 1 giorno
- ogni file di backup è immutabile per 7 giorni dopo il caricamento su B2 (object lock). questo ti protegge da incidenti, ransomware, ecc.
- 8 giorni dopo il caricamento, l’object lock sul backup scade. poiché è di nuovo modificabile, una regola del ciclo di vita può nascondere il file di backup
- la parte successiva della regola del ciclo di vita elimina qualsiasi file 1 giorno dopo essere stato nascosto
quindi ottieni backup giornalieri. il tempo di conservazione è una settimana durante la quale i backup non possono essere eliminati a prescindere da tutto. poi i backup vengono eliminati 2 giorni dopo. quindi in realtà un backup vive per circa 9 giorni.
spero che questo aiuti qualcuno 
ripensandoci, forse è meglio lasciare che sia Discourse a gestire la conservazione (maximum_backups). in questo modo, i tuoi backup non inizieranno a scadere automaticamente se Discourse è offline. non vorresti che un orologio ticchetti su di essi mentre cerchi di recuperare. se scegliessi quella strada, potresti impostare maximum_backups=8 e s3_disable_cleanup=false in questo esempio e non usare una policy del ciclo di vita in B2. useresti comunque la policy dell’object lock (7 giorni), però.
edit: in realtà, penso che tu abbia ancora bisogno di una policy del ciclo di vita B2 perché penso che i file vengano solo “nascosti” e non eliminati quando un client S2 li elimina. sto usando la policy " Keep only the last version of the file ", che è equivalente a daysFromHidingToDeleting=1, daysFromUploadingToHiding=null.
immagino che dovresti pensarci su e decidere quale approccio è giusto per te.
tra l’altro, mi rendo conto che c’è un po’ di avanti e indietro in questo post. penso che sia informativo così com’è, ma se qualcuno vuole, potrei fare un altro post leggermente più semplice con le mie raccomandazioni effettive.
6 Mi Piace
Se li inserisci nelle variabili d’ambiente come descritto in Configura un provider di archiviazione oggetti compatibile con S3 per i caricamenti allora puoi ripristinare il tuo sito su un nuovo server dalla riga di comando con solo il tuo file yml.
Il resto sembra un buon piano.
3 Mi Piace
discourse restore <backup.tar.gz>
questo cercherà nel tuo bucket se hai impostato le variabili d’ambiente? molto bello se è così.
e in tal caso, potresti probabilmente anche impostarle manualmente con export in bash nell’improbabile eventualità che tu debba recuperare. cioè, se per qualche motivo non vuoi conservare i segreti nel tuo yml del container.
1 Mi Piace
Solo per conferma, una volta che mi sarò spostato sui backup S3 e avrò verificato che funzionano, potrò eliminare in sicurezza il contenuto di quella cartella per recuperare spazio utilizzato?