Tenho um servidor de backup que coordena backups em vários servidores. Quero que meu servidor de backup busque os backups do Discourse no servidor do meu fórum.
Pensei em como permitir que o servidor de backup acesse os arquivos de backup no servidor do fórum. A melhor solução que encontrei foi permitir acesso remoto como o usuário www-data (que é o dono dos backups do Discourse).
Não queria permitir que o servidor de backup acessasse o servidor do fórum via shell como root (por motivos padrão de administração de sistemas). Também queria evitar qualquer coisa que pudesse causar problemas no Discourse durante os backups ou restaurações. Além disso, queria evitar hospedar outro serviço no servidor do fórum.
De qualquer forma, foi assim que fiz.
Permitir acesso remoto como o usuário www-data
Edite /etc/passwd e substitua o shell do www-data por /bin/bash em vez de /usr/sbin/nologin.
Edite /etc/passwd novamente e substitua o diretório home do www-data por /home/www-data em vez de /var/www (opcional, mas me pareceu mais adequado).
Adicione a chave SSH do servidor de backup em /home/www-data/.ssh/authorized_keys.
rsync
Por fim, no servidor de backup, adicionei um comando cron horário que executa o seguinte script:
#!/usr/bin/env bash
set -xe
HOST="$1"
DIR="$2"
if [ -z "$HOST" ] || [ ! -d "$DIR" ]; then
echo "$0 HOST DIR"
exit 1
fi
# --ignore-existing fará com que o rsync ignore qualquer backup que já tenha sido
# copiado.
# --delay-updates garante que apenas backups completos sejam transferidos para $DIR. Se
# isso não for especificado, backups parciais podem acabar em $DIR, e como
# --ignore-existing não realiza nenhum tipo de verificação de igualdade, o problema
# não será corrigido nem detectado.
rsync --ignore-existing --delay-updates "$HOST:/var/discourse/shared/standalone/backups/default/*" "$DIR"
Uau!!
Embora eu apreciasse muito mais se você tivesse explicado os passos abaixo com um pouco mais de detalhe para que usuários novatos como eu não pudessem fazer nada de errado (e também tivessem uma ideia do que cada passo está fazendo).
Como você é uma pessoa que busca novas maneiras, existe uma maneira simples de transferir nosso backup de servidor local para diferentes buckets S3, como Google S3, iDrive S3, por meio de cron jobs?
(Sei que podemos configurá-lo diretamente para o bucket S3 da AWS usando sua chave e segredo).
Se você configurar backups do S3, eles serão enviados para o S3 automaticamente, embora tenham todos os uploads ou nenhum. Portanto, a menos que você tenha uploads no S3, terá várias cópias de todos os uploads nos arquivos de backup.
Isso eu já sei e, até agora, desde o início, há 6 anos, eu usava essa configuração (de fazer upload de todas as mídias e backups para o bucket da AWS).
Mas eu estava perguntando o acima para um tipo diferente de problema que estou enfrentando.
Agora, configurei para criar backups (que incluem mídia ‘Uploads’) no servidor local do Ubuntu. Mas (como está sendo discutido em outro tópico), não consigo restaurar a partir desses backups (de 1 GB). Algo está faltando/dando problema. Então, eu estava pensando em usar o bucket do Google e abandonar a AWS completamente.
Não vejo a diferença entre o AWS S3 e os do Google. Mas talvez o https://restic.net/ possa te ajudar? É um programa de backup que pode fazer backup para buckets S3.
Não tenho certeza qual é o seu problema de restauração.
Para quem chegar a este tópico como eu, gostaria de explicar um pouco mais este primeiro post do tópico.
Este é um script bash, que pode ser colado ‘como está’ em um arquivo com qualquer nome, mas com a extensão .sh
A primeira linha do script apenas define o ambiente para a execução do script, como qual shell ou ambiente deve ser usado: #!/usr/bin/env bash: Isso diz ao sistema para usar o interpretador bash encontrado através do comando env.
Flags (set -xe):
-x: Habilita a depuração, o que significa que cada comando e seus argumentos serão impressos no terminal antes de serem executados. Isso é útil para depurar o script.
-e: Faz com que o script saia imediatamente se algum comando retornar um status diferente de zero (indicando um erro). Isso é útil para evitar que o script continue após uma falha.
E na próxima etapa importante, Variáveis (HOST="$1" DIR="$2"):
HOST="$1": Atribui o primeiro argumento passado para o script ($1) à variável HOST. Ou seja, quando este script for executado, ele exigirá alguma entrada do usuário, e qualquer primeira entrada ($1) que o usuário fornecer, será passada/considerada como o valor ‘Host’ (de onde os dados talvez serão copiados).
DIR="$2": Atribui o segundo argumento passado para o script ($2) à variável DIR. Ou seja, qualquer (caminho de diretório) que o usuário inserir após fornecer o 1º valor, (chamado de $2) será considerado pelo script como o ‘Diretório-alvo’.
Se alguém estiver interessado, posso explicar os 2 passos restantes também, mas basta dizer que o próximo passo apenas verifica se o usuário fornece os valores corretos de host e diretório de destino quando solicitado. Caso contrário (último passo), retornaria 1 como saída de erro.
A principal coisa que reiterarei é que este é um script, que quando executado, exigirá do usuário o host (de onde os dados devem ser copiados) e o diretório de destino (onde os dados devem ser colados). E você incluiria o caminho para este arquivo em seu arquivo cron, que pode executar este arquivo de script quantas vezes por dia você definir no arquivo cron.
Mas o que falhei em entender é onde estão os comandos reais de copiar e colar (ou backup)? Como ocorrerá a Sincronização real?