Thanks for the hint. That pushed me towards the command line option which we can schedule to do whenever: 
2 curtidas
Consegui fazer isso funcionar, mas parece que a caixa de seleção de uploads não era realmente necessária, nem entendi o propósito. Qual é o propósito? A única coisa que quero são backups para o s3 em vez de local para o meu servidor. O servidor só tem backups automáticos semanais.
O Json também teve problemas. Consegui fazer funcionar usando a referência de outro site. No entanto, ninguém conseguia fazer upload de imagens porque eu tinha a caixa de seleção de uploads marcada (como descrito aqui). Desmarcar essa caixa corrigiu o problema de upload de imagens para os usuários e suas fotos de perfil.
Qual é o propósito do upload de imagens? Estou seriamente esperando que as imagens estejam nos backups do s3.
Tive que refazer as instruções duas vezes porque não entendi “uploads” e fiz apenas um bucket. Então tive que refazer com 2 buckets e, em seguida, tive que remover a caixa de seleção para uploads. Pode ser bom se houvesse um tópico separado e mais simples para backups s3. e apenas backups.
{
"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 curtidas
Embora eu pense que esse tópico deveria ser atualizado para recomendar que a configuração do S3 seja movida para app.yml em vez do banco de dados, dessa forma você pode fazer uma restauração da linha de comando do banco de dados com apenas o arquivo yml e não ter que configurá-lo com um usuário e configuração s3 antes de fazer uma restauração.
1 curtida
Não tenho certeza do que você está falando. Meus backups estão funcionando, veja a imagem.
Eu uso s3 porque os backups do DigitalOcean são apenas semanais e, se o servidor travar e for excluído, não será útil.
Por outro lado, espero que restaurar do s3 ou de um bucket s3 baixado funcione bem.
Não estou fazendo upload das imagens e espero que os backups s3 estejam sendo copiados, incluindo imagens (embora pouquíssimas).
Geralmente: não.
Não faz muito sentido fazer backup de imagens em um bucket S3 para outro bucket S3?
2 curtidas
Você pode ser menos ambíguo? As instruções continham 2 buckets S3. Não consegui fazer isso funcionar. Eu tenho apenas um bucket S3. Espero que as imagens estejam incluídas nesse backup… isso está correto? Eu imagino que os backups locais funcionem da mesma forma, certo? Por favor, responda em frases completas sobre minhas perguntas. O tutorial também foi muito confuso.
1 curtida
O que há de ambíguo em “no”? (E o que não é ambíguo em “backups being backed up” 
)
Deixe-me tentar novamente.
Se você configurou o upload para o S3, então os uploads não estão incluídos no seu backup.
2 curtidas
Vamos usar o termo “imagens” em vez de uploads, mesmo que possa ser outra mídia.
Dessa forma, não confundimos o conteúdo de texto com um upload que estou enviando para o s3.
Então, os 62 MB de arquivos de backup no s3, como retratados e carregados neste tópico, não incluem imagens?
Então, como posso garantir que os backups tenham essas imagens?
Os backups locais também têm as imagens?
Quando configurei o s3 para “uploads (de mídia)”, o que também era ambíguo. Ninguém conseguia postar imagens porque elas eram rejeitadas pelo s3…
Existe uma maneira de ter backups diários locais e no s3?
Eu me importaria menos se 5 dias de imagens fossem perdidos, somos um grupo predominantemente baseado em texto.
Mas eu me importaria se 5 dias de texto fossem perdidos. O Digital Ocean só faz backups de 7 dias se você pagar por eles.
Portanto, mesmo que eu possa fazer backup diariamente, se o droplet for hackeado ou danificado, perderemos esses backups… Estou começando a pensar que não há muito valor agregado no s3.
Eu gostaria que houvesse backups simples, semelhantes ao WordPress, que me permitem fazer backup para minha conta do Google ou Dropbox.
Não, essa é uma má ideia. Se você enviar um arquivo de texto como anexo, ele também é um upload, o que causará confusão. E o texto em uma postagem é armazenado no banco de dados. Então, vou manter o termo uploads.
Se seus uploads estiverem no S3, eles não serão incluídos nos backups. Nesse caso, os backups contêm apenas uma cópia do banco de dados. Não importa se seus backups são locais ou no S3.
Se seus uploads não estiverem no S3, eles serão incluídos nos backups. Nesse caso, os backups contêm uma cópia do banco de dados e uma cópia dos uploads. Não importa se seus backups são locais ou no S3.
Se você estiver armazenando algo no S3, sejam uploads ou backups do banco de dados, eles não serão perdidos se o seu droplet DO for hackeado ou danificado. Então, não vejo seu ponto.
Como suas postagens são sobre backups e não sobre uploads de arquivos e imagens, estou movendo-as para outro tópico.
3 curtidas
Gostaria de mover automaticamente meus backups do S3 para o Glacier, mas estou confuso com as etapas vinculadas na primeira postagem, que não explicam muito, talvez porque haja coisas desatualizadas.\n\n
\n\nQuais opções devem ser marcadas aqui?
Posso perguntar novamente caso alguém tenha seguido estes passos e saiba sobre isso?
Além disso, você sabe o que causa essas flutuações nas taxas do S3?
Além disso, desde o lançamento do fórum (setembro de 2020), o tamanho dos backups aumentou cerca de 15%, mas as contas do S3 dobraram, de US$ 2,50 para US$ 5. Alguma ideia do porquê tanto?
É por isso que eu gostaria de usar o Glacier.
Editar: Segui os passos descritos aqui e verei como vai.
1 curtida
Bem, não funciona. 
Minha configuração de ciclo de vida:
Meu bucket S3:
Nenhum backup está no Glacier.
Então… Duas perguntas para aqueles que conseguiram realizar essa transição automatizada de S3 para Glacier:
-
O que pode estar errado na minha configuração?
-
A cobrança mínima de duração de armazenamento no Glacier é de 90 dias. Isso significa que se eu fizer 1 backup por dia, eventualmente serei cobrado por 90 backups no Glacier a cada mês?
Se for esse o caso, então essa solução do Glacier não será uma boa ideia, a menos que eu reduza muito a frequência dos meus backups.
1 curtida
Onde no VPS os backups são armazenados?
1 curtida
Adicionei isto ao OP:
2 curtidas
Podemos escolher a pasta de backup ou existe uma solução alternativa sem codificação?
Estou usando dados de armazenamento do meu provedor de hospedagem para que possa montar e usar como local, mas não deve ser salvo no caminho padrão.
1 curtida
Se você quiser que ele seja salvo em um local diferente, precisará alterar isso em seu app.yml
2 curtidas
Backups Automáticos no Backblaze B2
Aqui está como eu configurei para um site hipotético hospedado em example.com
- Crie uma conta no Backblaze (no momento, não é necessário inserir pagamento para <10GB, que é gratuito)
- Crie um bucket (Backblaze > Armazenamento em Nuvem B2)
- nome:
$nomedosite-discourse-$aleatoriopreenchido para 30 caracteres- neste exemplo:
example-discourse-g87he56ht8vg - o Discourse precisa que o nome do bucket contenha apenas letras minúsculas, números e hifens
- sugiro mantê-lo com 30 caracteres ou menos, pois isso aparece bem na interface web do Backblaze sem quebrar a linha
- neste exemplo:
- bucket privado
- ative a criptografia (SSE-B2)
- ative o bloqueio de objetos
- nome:
- Crie uma chave de aplicativo (Backblaze > Conta > Chaves de Aplicativo)
- nome da chave:
example-discourse - nome do bucket (Permitir acesso ao(s) Bucket(s)):
example-discourse-g87he56ht8vg - capacidades: ler e escrever
- deixe
nomePrefixevalidDurationSecondsem branco
- nome da chave:
- Configure as configurações do Discourse B2 (Discourse > Admin > Configurações)
backup_location:s3s3_backup_bucket:example-discourse-g87he56ht8vgs3_endpoint: isso é mostrado na página do bucket – certifique-se de adicionarhttps://no inícios3_access_key_id: (da etapa anterior)s3_secret_access_key: (da etapa anterior)- o Backblaze só mostra a chave uma vez (na criação)!
- aliás, você também pode definir essas variáveis como variáveis de ambiente no seu arquivo YAML do contêiner em vez disso. isso permitiria restaurar com apenas esse arquivo e nada mais:
env:
## Backups do Backblaze B2
# DISCOURSE_BACKUP_LOCATION: 's3' # descomente para recuperar via 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' # descomente para desativar e-mails durante um teste de restauração
## você pode restaurar sem nenhum dado além deste arquivo YAML do contêiner.
## descomente DISCOURSE_BACKUP_LOCATION acima, construa o contêiner (./launcher rebuild ...),
## e então execute isso dentro do contêiner (ele restaurará do bucket B2):
## discourse enable_restore
## discourse restore <example-com-...tar.gz> # escolha o nome do arquivo de restauração navegando na interface web do B2
## lembre-se de desativar a restauração depois
- Configure a retenção de backup
- Discourse:
backup_frequency: 1 (backups diários neste exemplo, mas você poderia fazer semanais)maximum_backups: ignore esta configuração – deixe o Backblaze cuidar disso
s3_disable_cleanup: true (Impede a remoção de backups antigos do S3 quando há mais backups do que o máximo permitido)
- Backblaze (vá para as configurações do seu bucket):
- Bloqueio de Objetos (Política de Retenção Padrão): 7 dias
- Configurações de Ciclo de Vida (personalizado):
fileNamePrefix:default/example-com(opcional)daysFromUploadingToHiding: 8 dias- isso deve ser o bloqueio de objeto + 1
daysFromHidingToDeleting: 1 dia
para resumir a retenção neste exemplo:
- Discourse:
- o Discourse cria backups a cada 1 dia
- cada arquivo de backup é imutável por 7 dias após o upload para o B2 (bloqueio de objeto). isso protege contra acidentes, ransomware, etc.
- 8 dias após o upload, o bloqueio de objeto no backup expira. como ele se torna mutável novamente, uma regra de ciclo de vida pode ocultar o arquivo de backup
- a próxima parte da regra de ciclo de vida exclui qualquer arquivo 1 dia após ser ocultado
então você obtém backups diários. o tempo de retenção é de uma semana durante a qual os backups não podem ser excluídos, não importa o quê. então os backups são excluídos 2 dias depois. então, na verdade, um backup vive por cerca de 9 dias.
espero que isso ajude alguém 
em segundo pensamento, talvez seja melhor deixar o Discourse cuidar da retenção (maximum_backups). dessa forma, seus backups não começarão a expirar automaticamente se o Discourse estiver inativo. você não gostaria que um relógio estivesse contando contra eles enquanto tenta se recuperar. se você seguisse esse caminho, poderia definir maximum_backups=8 e s3_disable_cleanup=false neste exemplo e não usar uma política de ciclo de vida no B2. você ainda usaria a política de bloqueio de objeto (7 dias), no entanto.
editar: na verdade, acho que você ainda precisa de uma política de ciclo de vida do B2 porque acho que os arquivos só ficam ‘ocultos’ e não são excluídos quando um cliente S2 os exclui. estou usando a política “Manter apenas a última versão do arquivo”, que é equivalente a daysFromHidingToDeleting=1, daysFromUploadingToHiding=null.
acho que pense sobre isso e decida qual abordagem é a certa para você.
aliás, percebo que há alguma discussão neste post. acho que é informativo como está, mas se alguém quiser, eu poderia fazer outro post um pouco mais simples com minhas recomendações reais.
6 curtidas
Se você colocar essas configurações em variáveis de ambiente, conforme descrito em Configurar um provedor de armazenamento de objetos compatível com S3 para uploads, você poderá restaurar seu site em um novo servidor a partir da linha de comando apenas com seu arquivo yml.
O restante parece um bom plano.
3 curtidas
discourse restore <backup.tar.gz>
isso procurará em seu bucket se você tiver as variáveis de ambiente definidas? muito legal, se sim.
e nesse caso, você também poderia configurá-las manualmente com export em bash no improvável caso de você ter que recuperar. isso é, se você não quiser manter segredos em seu yml de contêiner por algum motivo.
1 curtida
Apenas para confirmação, depois de migrar para backups S3 e testar que eles funcionam, posso excluir com segurança o conteúdo dessa pasta para recuperar o espaço utilizado?