Automatizzo il mio backup rsyncper evitare guasti e rendere prevedibili i recuperi. Con un chiaro Lavori cronTrasporto SSH ed esecuzioni incrementali, proteggo in modo efficiente server web, database e configurazioni.
Punti centrali
- AutomazioneI lavori a tempo riducono gli errori e gli sforzi.
- EfficienzaIl trasferimento delta risparmia larghezza di banda e memoria.
- SicurezzaSSH, gestione delle chiavi e obiettivi fuori sede.
- StrategiaConservazione GFS e obiettivi RPO/RTO chiari.
- TrasparenzaTest di registrazione, monitoraggio e ripristino.
Perché automatizzo i backup
Proteggo costantemente i sistemi produttivi perché un singolo guasto può portare all'arresto di interi progetti e io Disponibilità vuole garantire. Un backup programmato alle 02:00 sostituisce il lavoro manuale soggetto a errori e garantisce uno stato pulito dei dati. Definisco obiettivi chiari per ogni server: Quanto è accettabile la perdita di dati (RPO) e quanto velocemente deve avvenire il ripristino (RTO). Questi obiettivi influenzano la pianificazione, l'obiettivo di archiviazione e le opzioni, in modo da poter salvaguardare le operazioni in modo affidabile. In particolare per i server web, riduco al minimo calcolabile i rischi di difetti hardware, ransomware o cancellazioni accidentali.
rsync spiegato brevemente: funzionalità e punti di forza
rsync trasferisce solo le modifiche, utilizza un efficiente sistema di Trasferimento Delta ed evita le copie non necessarie. Questo riduce significativamente i tempi di esecuzione, il carico di rete e l'IO sul sistema di destinazione. Lavoro in modalità archivio (-a) in modo che i permessi, gli orari, i proprietari e i collegamenti simbolici rimangano coerenti. Uso -delete per mantenere aggiornati i mirror, ma faccio attenzione all'uso previsto e lo combino con directory separate per il versioning. Uso SSH per il trasporto, percorsi diretti per i lavori locali e aggiungo la compressione (-z) e il limite di larghezza di banda (-bwlimit) se necessario.
Automazione con Cron: passo dopo passo
Inizio con uno script semplice, perché chiaro Linee di base può essere ampliato in seguito. Per prima cosa installo rsync, se manca, e creo una directory di lavoro sicura per i log e lo stato. Quindi scrivo uno script con sorgenti, destinazione e opzioni sensibili, comprese le esclusioni. Il cronjob viene eseguito ogni giorno o ogni ora, a seconda dell'RPO, e scrive i file di log per la valutazione e gli avvisi. Un'esecuzione a secco (-n) prima della prima esecuzione produttiva previene le cancellazioni indesiderate.
Installazione di # (Debian/Ubuntu)
sudo apt-get install rsync
# Minimo eseguito localmente
rsync -a /data/www/ /backup/www/
# Mirror remoto via SSH con cancellazioni
rsync -a --delete -e "ssh -i /root/.ssh/backup_key" /data/www/ backup@backuphost:/srv/backups/www/
# Cron: ogni giorno alle 02:00.
0 2 * * * * /usr/local/bin/rsync-backup.sh >> /var/log/rsync-backup.log 2>&1
Impostare i backup SSH in modo sicuro
Utilizzo chiavi SSH con diritti limitati perché Gestione delle chiavi riduce la superficie di attacco. Sul sistema di destinazione, limito i comandi utilizzando chiavi_autorizzate e uso un utente di backup separato. Fail2ban, regole del firewall e opzioni SSH restrittive (ad esempio, PasswordAuthentication no) aumentano la sicurezza. Memorizzo la chiave host in modo che il man-in-the-middle non abbia alcuna possibilità. Se siete alla ricerca di un inizio strutturato, potete trovare idee collaudate su Automatizzare i backup.
Tirare invece di spingere: i vantaggi della sicurezza nella pratica
Dove possibile, lascio il Rollup del server di backup invece di passare al server di produzione. In questo modo i sistemi di produzione non hanno chiavi in uscita e un server Web compromesso non può cancellare i backup fuori sede. Sulla destinazione, limito la chiave in authorized_keys con opzioni restrittive e un comando forzato.
# Esempio di chiavi autorizzate sulla destinazione di backup
from="10.0.0.10",no-agent-forwarding,no-pty,no-port-forwarding,no-X11-forwarding,command="/usr/local/bin/rsync-serve-backups"
/home/backup/.ssh/authorised_keys
Lo script chiamato consente solo le chiamate al server rsync e imposta i limiti di percorso. Questo è il modo in cui ottengo un Principio dei diritti minimisenza complicare il funzionamento.
Versioning e archiviazione con hard link
Per diversi stand ho costruito cartelle giornaliere, settimanali e mensili con -link-dest, perché Collegamenti diretti Risparmia memoria e semplifica i ripristini. Ogni generazione si riferisce a file identici e invariati del backup precedente; i file nuovi o modificati finiscono fisicamente nella nuova cartella. Questo mi permette di ottenere molti punti di ripristino con requisiti di memoria moderati. Rimuovo le vecchie generazioni con un semplice script di rotazione senza rischiare la coerenza dei dati. Una pianificazione fissa (ad esempio 7 giorni, 4 settimane, 6 mesi) mantiene la pianificazione dello storage chiara e trasparente.
Controllo delle risorse: Larghezza di banda, CPU e I/O
Limito il throughput dei dati con -bwlimit in modo che Carico produttivo rimane stabile e gli utenti non subiscono alcuna perdita. Uso nice e ionice per dare priorità ai processi di backup. Sulle reti lente attivo la compressione (-z), sui supporti locali veloci la lascio disattivata. Per i file di grandi dimensioni, seleziono -parziale per poter continuare a cancellare i trasferimenti. Per i mirror locali, spesso uso -whole-file perché l'algoritmo delta non ha alcun vantaggio.
Stati dei dati coerenti: snapshot e database
Per mantenere coerenti i backup nonostante i file aperti, uso Istantanee o ganci dell'applicazione. I file system come LVM, ZFS o Btrfs consentono snapshot veloci, che uso come fonte per rsync. Questo mi permette di congelare logicamente lo stato dei dati senza bloccare i servizi per molto tempo.
# Esempio: snapshot LVM come sorgente coerente
lvcreate -L 10G -s -n data_snap /dev/vg0/data
montare /dev/vg0/data_snap /mnt/data_snap
rsync -a --delete /mnt/data_snap/www/ backup@host:/srv/backups/www/
umount /mnt/data_snap
lvremove -f /dev/vg0/data_snap
Per Banche dati Separo la logica dai file. Eseguo il backup di MySQL/MariaDB tramite dump o soluzioni Percona/Xtra, PostgreSQL con pg_dump o basebackup. La sequenza è importante: prima si crea un dump coerente, poi si trasferisce il percorso del dump tramite rsync. In questo modo si evitano file scritti a metà nel backup.
Fonti di errore tipiche e come evitarle
L'inciampo più comune è la barra alla fine di un percorso, quindi controllo Dettagli del percorso doppio: /src/ contro /src. Provo le esclusioni con -dry-run e -itemise-changes per vedere l'effetto. Cito correttamente gli schemi con gli spazi e mantengo il file di esclusione nel repository. Prima di -delete controllo i montaggi, perché una destinazione non montata può portare a una cancellazione indesiderata. Infine, registro i codici di ritorno e attivo gli allarmi in modo da poter vedere immediatamente gli errori.
Strategia di backup: GFS e obiettivi di ripristino
Ho impostato prima l'RPO/RTO, perché chiaro Obiettivi guidare ogni decisione sulla frequenza, sulla posizione di archiviazione e sulla conservazione. Uno schema comune è GFS: differenziale giornaliero, settimanale completo o unito tramite hard link, mensile a lungo termine. I requisiti di conformità influenzano il periodo di conservazione, quindi separo i dati operativi di breve durata dagli archivi a lungo termine. Per i sistemi critici, pianifico backup fuori sede oltre alle copie locali. Questa combinazione protegge dai guasti del sito e consente di effettuare ripristini rapidi e remoti.
Cron o systemd-timer: pianificazione affidabile
Cron è semplice e robusto. Per gli host che occasionalmente dormono o si riavviano, uso anche systemd-timer con le dipendenze e la gestione delle esecuzioni mancate. Ciò garantisce che nessuna corsa fallisca dopo un riavvio e che la sequenza sia corretta (ad esempio, dopo il ripristino della rete).
# /etc/systemd/system/rsync-backup.service
[Unità]
Descrizione=Rsync Backup
Dopo=network-online.target
Wants=network-online.target
[Servizio]
Tipo=oneshot
ExecStart=/usr/local/bin/rsync-backup.sh
Bello=10
IOSchedulingClass=best-effort
IOSchedulingPriority=7
# /etc/systemd/system/rsync-backup.timer
[Unità]
Descrizione=Timer giornaliero di backup di Rsync
[Timer]
OnCalendar=02:00
Persistente=vero
[Install]
WantedBy=timers.target
Tabella: Opzioni rsync importanti nella vita quotidiana
Ne uso pochi, ma efficaci Opzioniche documento per ogni lavoro e versione nel repo. La modalità archivio costituisce la base e riduce gli errori di configurazione. Mantengo puliti i mirror con -delete, ma lo uso solo con il corretto controllo del target. Per il versioning, combino -link-dest con un piano di rotazione. La tabella seguente mostra gli switch più importanti e il loro utilizzo.
| Opzione | Scopo | Suggerimento |
|---|---|---|
| -a | Modalità archivio | Assume diritti, tempi, proprietà per Coerenza |
| -z | Compressione | Utile per la WAN, spesso omesso a livello locale |
| -Cancellare | Rimuove i file legacy rimossi | Usare solo con gli specchi, prima di eseguire la prova a secco |
| -bwlimit=KBPS | Larghezza di banda dell'acceleratore | Protegge Sistemi produttivi dai picchi di carico |
| -link-dest=DIR | Versioning tramite hard link | Generazioni economiche con cartelle separate |
| -e "ssh ..." | Trasporto sicuro | Chiavi, chiavi host, utenti restrittivi |
| -n / -corsa a vuoto | Esecuzione del test senza modifiche | Mostra le azioni pianificate in anticipo |
Test di recupero: esercizi di ripristino
Verifico regolarmente il ripristino, perché un backup senza ripristino è solo Aspetto è. Per i campioni, ripristino singoli file e interi webroot in ambienti di staging. Eseguo il backup dei database separatamente utilizzando i dump e li importo su base di prova per verificarne la coerenza. Le checksum mi aiutano a confermare l'integrità e a riconoscere gli errori di bit silenti. Dopo ogni test, adatto la documentazione, gli script e i playbook in modo che la prossima emergenza venga eseguita più rapidamente.
Backup Bare Metal e di sistema: caratteristiche speciali
Per i backup di sistema o bare-metal, estendo le opzioni di rsync a ACL, xattr e hardlink da portare con sé. Su Linux, -aAXH e -numeric-ids hanno dimostrato la loro validità. Escludo pseudo-file system come /proc, /sys, /run, /dev/pts ed eseguo il backup dei file di avvio e di configurazione separatamente.
# Backup del sistema (esempio)
rsync -aAXH --numeric-ids \
--exclude={"/proc/*","/sys/*","/run/*","/dev/pts/*","/tmp/*"} \
/ root@backup:/srv/backups/hostA/current/
Ripristino # (semplificato, da supporto live)
rsync -aAXH --numeric-ids /srv/backups/hostA/current/ /mnt/target/
chroot /mnt/target update-initramfs -u
grub-installare /dev/sda && update-grub
Pianifico più tempo per questi ripristini, documento la sequenza e tengo a portata di mano i passaggi del bootloader. Questo riduce notevolmente lo stress in caso di emergenza.
Integrazione di Plesk: combinare abilmente i lavori del pannello
Combino i task di Plesk con rsync in modo che Backup del pannello e le copie offsite lavorano insieme. I ganci post-backup trasferiscono immediatamente i backup freschi sullo storage esterno. Le pianificazioni coincidono con le finestre di manutenzione, in modo che le distribuzioni e i backup non interferiscano l'uno con l'altro. La rotazione dei registri nel pannello e sul sistema di destinazione impedisce la crescita delle directory di registro. Un buon punto di partenza è fornito da Le migliori pratiche di Plesk con particolare attenzione ai processi ripetibili.
Integrazione con cPanel: Homedirs e database
Poi estraggo i backup di cPanel su un host esterno tramite rsync, in modo tale che Protezione fuori sede rimane senza carico aggiuntivo. La struttura delle directory facilita il ripristino selettivo dei singoli account. Per le configurazioni di grandi rivenditori, pianifico le esecuzioni differenziali durante la notte e i ripristini completi nel fine settimana. In combinazione con le quote e le rotazioni, mantengo trasparenti i requisiti di archiviazione. Un'aggiunta pratica sono le note su Backup di cPanel per una solida operatività quotidiana.
Scalabilità e struttura: gestire molti lavori in modo pulito
Quando gli ambienti crescono, strutturo le fonti e le esclusioni a livello centrale. Con -files-da Trasferisco gli elenchi che ho versione nel repo. In questo modo modifico i record senza toccare gli script e mantengo le posizioni coerenti.
File #: un esempio
/etc/backup/www.list
/data/www/
/etc/nginx/
/var/www/html/
rsync -a --delete --files-from=/etc/backup/www.list / backup@host:/srv/backups/www/
Evito le sovrapposizioni separando chiaramente le responsabilità dei percorsi (ad esempio, Webroot separatamente dai log). Per gli insiemi di grandi dimensioni, pianifico consapevolmente il parallelismo: preferisco pochi lavori ben tempificati a decine di processi concorrenti.
Robustezza nel funzionamento: blocco, tentativi, timeout
Per evitare sovrapposizioni, utilizzo il metodo gregge o i file di blocco. Intercetto i problemi di rete con Retries e -partial. Con -timeout termino le connessioni sospese in modo pulito e lancio un allarme.
# /usr/local/bin/rsync-backup.sh (estratto)
#!/usr/bin/env bash
set -euo pipefail
exec 9> /var/lock/rsync-backup.lock
flock -n 9 || { echo "Backup già in esecuzione"; exit 1; }
LOG=/var/log/rsync-backup.log
SRC=/data/www/
DST=backup@backuphost:/srv/backups/www/
per i in {1..3}; fare
se rsync -a --delete --partial --timeout=600 -e "ssh -i /root/.ssh/backup_key" "$SRC" "$DST"; allora
echo "OK"; exit 0
fi
echo "Riprova $i" | tee -a "$LOG"
dormire 60
fatto
echo "Errore dopo i tentativi" >> "$LOG"; exit 1
Opzioni per casi speciali: ACL, xattr, sparse e atomicità
Adatto rsync a seconda del tipo di dati. Per i percorsi web e di sistema, eseguo il backup di ACL e xattr con -A -X. I file di grandi dimensioni e scarsamente utilizzati (immagini di macchine virtuali, database) traggono vantaggio da -sparso. Con -ritardare gli aggiornamenti e -ritardo di cancellazione Riduco al minimo gli stati intermedi e ottengo aggiornamenti quasi atomici sulla destinazione. Per i dati sensibili, evito -inplace in modo che i trasferimenti difettosi non sovrascrivano l'ultima copia valida.
# Esempio per metadati estesi
rsync -aAXH --sparse --delete-delay --delay-updates SRC/ DST/
Se ho bisogno di directory assolutamente atomiche (ad esempio, per lo staging), sincronizzo su una destinazione temporanea e corsa poi usare mv per passare alla directory live.
Limiti di cancellazione sicuri e controlli di plausibilità
Per evitare disastri causati da una configurazione errata, ho impostato -max-cancellazione di Guardrail. Controllo anche i montaggi, la memoria libera e gli inode prima dell'esecuzione. Ho registrato l'ultimo backup riuscito e avverto dei valori anomali (tassi di cancellazione o modifica estremi).
# Protezione contro le cancellazioni di massa
rsync -a --cancellare --max-cancellare=5000 SRC/ DST/
# Controllo di plausibilità (semplice)
df -h /srv/backup
df -i /srv/backups
Riassumendo brevemente: Ecco come procedo
Definisco prima RPO/RTO, perché chiaro Priorità guidare ogni scelta tecnica. Scrivo quindi uno script snello, lo collaudo con -dry-run e registro ogni esecuzione. Con chiavi SSH, limiti di larghezza di banda e versioning, eseguo il backup in modo efficiente e tracciabile. Le destinazioni fuori sede integrano le copie locali e i regolari esercizi di ripristino ne confermano l'idoneità. Così il mio backup rsync rimane affidabile, veloce e sempre pronto all'uso.
