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
Edit /etc/passwd and replace www-data’s shell with /bin/bash rather than /usr/sbin/nologin.
Edit /etc/passwd again and replace www-data’s home directory with /home/www-data rather than /var/www (optional, but appealing to me).
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.
Wow!!
Apprezzerei molto di più se spiegassi i passaggi forniti di seguito in modo un po’ più dettagliato, in modo che gli utenti alle prime armi come me non possano fare nulla di sbagliato (e anche per farsi un’idea di cosa sta facendo ogni passaggio).
Consente all’utente www-data di accedere con successo. Questo sta cambiando la “login shell”, che è una buona parola chiave da cercare per saperne di più.
Sì. Le chiavi private non dovrebbero (praticamente) mai essere copiate/condivise al di fuori della loro macchina host.
Dato che sei una persona che cerca in modo un po’ nuovo, ci potrebbe essere anche un modo semplice per trasferire il nostro backup del server locale su diversi bucket S3, come Google S3, iDrive S3 tramite cron job?
(So che possiamo configurarlo direttamente per il bucket S3 di AWS utilizzando la sua chiave e il suo segreto).
Se configuri i backup S3, questi vengono caricati automaticamente su S3, anche se hanno tutti i caricamenti o nessuno, quindi a meno che tu non abbia caricamenti su S3, hai più copie di tutti i caricamenti nei file di backup.
Questo lo so già e finora, da quando ho iniziato 6 anni fa, ho utilizzato proprio questa configurazione (di caricare tutti i media e i backup nel bucket AWS).
Ma stavo chiedendo quanto sopra per un problema di tipo diverso che sto affrontando.
Ora, ho impostato la creazione di backup (che includono i media ‘Uploads’) sul server Ubuntu locale. Ma (come discusso in un altro thread), non sono in grado di ripristinare da quei backup (grandi 1 GB). Manca qualcosa/c’è un problema. Quindi stavo pensando di usare il bucket di Google e di abbandonare del tutto AWS.
Non vedo la differenza tra AWS S3 e quelli di Google. Ma forse https://restic.net/ ti aiuterà? È un programma di backup che può eseguire il backup nei bucket S3.
Non sono sicuro di quale sia il tuo problema di ripristino.
Per chiunque arrivi a questo thread come me, vorrei spiegare ulteriormente questo primo post dell’argomento.
Questo è uno script bash, che può essere incollato “così com’è” in un file chiamato qualsiasi cosa, ma con estensione .sh
La prima riga dello script imposta semplicemente l’ambiente per l’esecuzione dello script, per quanto riguarda quale shell o ambiente utilizzare: #!/usr/bin/env bash: questo dice al sistema di utilizzare l’interprete bash trovato tramite il comando env.
flag (set -xe):
-x: abilita il debug, il che significa che ogni comando e i suoi argomenti verranno stampati sul terminale prima di essere eseguiti. Questo è utile per il debug dello script.
-e: causa l’uscita immediata dello script se un comando restituisce uno stato diverso da zero (indicando un errore). Questo è utile per impedire allo script di continuare dopo un fallimento.
E nel prossimo importante passaggio, Variabili (HOST="$1" DIR="$2"):
HOST="$1": assegna il primo argomento passato allo script ($1) alla variabile HOST. Cioè, quando questo script viene eseguito, richiederà un input all’utente e qualsiasi primo input ($1) inserito dall’utente, verrà passato/considerato come valore ‘Host’ (da dove i dati verranno forse copiati).
DIR="$2": assegna il secondo argomento passato allo script ($2) alla variabile DIR. Cioè, qualsiasi (percorso di directory) verrà inserito dall’utente dopo aver inserito il primo valore, (chiamato $2') verrà preso dallo script come ‘Dir- directory di destinazione’.
Se qualcuno è interessato posso spiegare anche i restanti 2 passaggi, ma basti dire che il passaggio successivo controlla semplicemente che l’utente fornisca i valori corretti di host e directory di destinazione quando richiesto. Altrimenti (ultimo passaggio) restituirebbe 1 come output di errore.
La cosa principale che vorrei ribadire è che questo è uno script che, quando eseguito, richiederà all’utente l’host (da dove copiare i dati) e la directory di destinazione (dove incollare i dati). E includeresti il percorso a questo file nel tuo file cron, che potrebbe eseguire questo file script quante volte al giorno imposteresti nel file cron.
Ma quello che non sono riuscito a capire è dove sono i comandi effettivi di copia e incolla (o backup)? Come avverrà la sincronizzazione effettiva?