Copiar backups para outro servidor com rsync e cron

Wiki da comunidade Administradores de sistemas
1

I have a backup server that coordinates backups across many servers. I want my backup server to grab Discourse backups from my forum’s server.

I gave some thought to how I’d allow the backup server to access the backup files on the forum’s server. The best way I could come up with is allowing remote access as the www-data user (who owns Discourse’s backups).

I didn’t want to allow the backup server to shell into the forum’s server as root (for standard sysadmin reasons). I also wanted to avoid doing anything that I thought could cause Discourse to choke during backups or restores. I also wanted to avoid hosting another service on forum server.

Anyways, here’s how I did it.

Allow remote access as the www-data user

  1. Edit /etc/passwd and replace www-data’s shell with /bin/bash rather than /usr/sbin/nologin.
  2. Edit /etc/passwd again and replace www-data’s home directory with /home/www-data rather than /var/www (optional, but appealing to me).
  3. Add the backup server’s SSH key to /home/www-data/.ssh/authorized_keys.

rsync

Finally, on the backup server, I added an hourly cron command that ran the following 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 will have rsync ignore any backups that have already been
# copied.
# --delay-updates ensures that only complete backups ever make it into $DIR. If
# this isn't specified, partial backups could end up in $DIR, and because
# --ignore-existing won't perform any kind of equality check, the problem will
# not be corrected or detected.
rsync --ignore-existing --delay-updates "$HOST:/var/discourse/shared/standalone/backups/default/*" "$DIR"

Hopefully this proves useful to someone out there.

8 curtidas
2

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).

O que o acima faz?

Você quer dizer chave pública aqui?

1 curtida
3

Permite que o usuário www-data faça login com sucesso. Isso está mudando o “login shell”, que é uma boa palavra-chave para pesquisar e aprender mais.

Sim. Chaves privadas (basicamente) nunca devem ser copiadas/compartilhadas em qualquer lugar fora de sua máquina host.

1 curtida
4

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).

5

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.

2 curtidas
6

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.

1 curtida
7

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.

2 curtidas
8

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?

1 curtida