Jag automatiserar min rsync säkerhetskopieringför att undvika fel och göra återställningarna förutsägbara. Med tydliga Cron jobbSSH-transport och inkrementella körningar säkrar jag effektivt webbservrar, databaser och konfigurationer.
Centrala punkter
- AutomatiseringTidsstyrda jobb minskar antalet fel och arbetsinsatser.
- EffektivitetDeltaöverföring sparar bandbredd och minne.
- SäkerhetSSH, nyckelhantering och mål utanför anläggningen.
- StrategiGFS retention och tydliga RPO/RTO-mål.
- ÖppenhetLoggning, övervakning och återställningstest.
Varför jag automatiserar säkerhetskopiering
Jag säkrar konsekvent produktiva system eftersom ett enda fel kan få hela projekt att stanna upp och jag Tillgänglighet vill garantera. En schemalagd säkerhetskopiering kl. 02.00 ersätter felbenäget manuellt arbete och säkerställer rena datastatusar. Jag definierar tydliga mål för varje server: Hur stor dataförlust som är acceptabel (RPO) och hur snabbt återställningen måste ske (RTO). Dessa mål påverkar schemat, lagringsmålet och alternativen så att jag på ett tillförlitligt sätt kan skydda verksamheten. Särskilt för webbservrar reducerar jag riskerna för hårdvarudefekter, ransomware eller oavsiktlig radering till ett beräkningsbart minimum.
rsync kortfattat förklarat: Funktionalitet och styrkor
rsync överför bara ändringar och använder en effektiv Delta-överföring och undviker onödiga kopior. Detta minskar avsevärt körtiderna, nätverksbelastningen och IO på målsystemet. Jag arbetar i arkivläge (-a) så att behörigheter, tider, ägare och symlänkar förblir konsekventa. Jag håller speglar uppdaterade med -delete, men är uppmärksam på den avsedda användningen och kombinerar den med separata kataloger för versionshantering. Jag använder SSH för transport, direkta sökvägar för lokala jobb och lägger till komprimering (-z) och bandbreddsbegränsning (-bwlimit) vid behov.
Automatisering med Cron: steg för steg
Jag börjar med ett enkelt skript, eftersom tydliga Baslinjer kan utökas senare. Först installerar jag rsync, om det saknas, och skapar en säker arbetskatalog för loggar och status. Sedan skriver jag ett skript med källor, mål och förnuftiga alternativ inklusive undantag. Cronjobbet körs dagligen eller varje timme beroende på RPO och skriver loggfiler för utvärdering och varning. En torrkörning (-n) före den första produktiva körningen förhindrar oönskade raderingar.
Installation av # (Debian/Ubuntu)
sudo apt-get installera rsync
# Minimal körning lokalt
rsync -a /data/www/ /backup/www/
# Fjärrspegel via SSH med raderingar
rsync -a --delete -e "ssh -i /root/.ssh/backup_key" /data/www/ backup@backuphost:/srv/backups/www/
# Cron: dagligen kl. 02:00
0 2 * * * * * /usr/local/bin/rsync-backup.sh >> /var/log/rsync-backup.log 2>&1
Konfigurera SSH-backuper på ett säkert sätt
Jag använder SSH-nycklar med begränsade rättigheter eftersom Nyckelhantering minskar attackytan. På målsystemet begränsar jag kommandon med authorised_keys och använder en separat backup-användare. Fail2ban, brandväggsregler och restriktiva SSH-alternativ (t.ex. PasswordAuthentication no) ökar säkerheten. Jag lagrar värdnyckeln så att man-in-the-middle inte har någon chans. Om du vill ha en strukturerad start kan du hitta beprövade och testade idéer på Automatisera säkerhetskopiering.
Pull istället för push: säkerhetsfördelar i praktiken
Där det är möjligt lämnar jag Backup server rollup istället för att skicka till produktionsservern. Detta lämnar produktionssystem utan utgående nycklar, och en komprometterad webbserver kan inte radera säkerhetskopior utanför webbplatsen. På målet begränsar jag nyckeln i authorised_keys med restriktiva alternativ och ett tvingande kommando.
# Exempel på authorised_keys på backup-målet
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/auktoriserade_nycklar
Det anropade skriptet tillåter endast rsync-serveranrop och ställer in sökvägsgränser. Det är så här jag uppnår en Principen om minimirättigheterutan att komplicera driften.
Versionering och lagring med hårda länkar
Under flera år har jag dagligen, veckovis och månadsvis skapat mappar med -link-dest, eftersom Hårda länkar Sparar minne och förenklar återställningar. Varje generation avser identiska, oförändrade filer från den föregående säkerhetskopian; nya eller ändrade filer hamnar fysiskt i den nya mappen. Detta gör att jag kan uppnå många återställningspunkter med måttliga lagringskrav. Jag tar bort gamla generationer med ett enkelt rotationsskript utan att riskera datakonsistensen. Ett fast schema (t.ex. 7 dagar, 4 veckor, 6 månader) gör att lagringsplaneringen blir tydlig och transparent.
Kontrollera resurser: Bandbredd, CPU och I/O
Jag begränsar dataflödet med -bwlimit så att Produktiv belastning förblir stabil och användarna inte upplever några förluster. Jag använder nice och ionice för att prioritera säkerhetskopieringsprocesserna. På långsamma nätverk slår jag på komprimering (-z), på snabba lokala medier låter jag det vara avstängt. För stora filer väljer jag -partial för att kunna fortsätta med avbrutna överföringar. För lokala speglar använder jag ofta -whole-file eftersom delta-algoritmen inte har några fördelar där.
Konsistenta datastatusar: ögonblicksbilder och databaser
För att upprätthålla konsekventa säkerhetskopior trots öppna filer använder jag Ögonblicksbilder eller applikationskrokar. Filsystem som LVM, ZFS eller Btrfs tillåter snabba ögonblicksbilder, som jag använder som källa för rsync. Detta gör att jag logiskt kan frysa datastatusen utan att blockera tjänster under lång tid.
# Exempel: LVM-snapshot som en konsekvent källa
lvcreate -L 10G -s -n data_snap /dev/vg0/data
montera /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
För Databaser Jag separerar logik och filer. Jag säkerhetskopierar MySQL / MariaDB via dump eller Percona / Xtra-lösningar, PostgreSQL med pg_dump eller basebackups. Sekvensen är viktig: skapa först en konsekvent dumpning och överför sedan dumpningsvägen via rsync. Detta förhindrar halvskrivna filer i säkerhetskopian.
Typiska felkällor och hur man undviker dem
Den vanligaste stötestenen är snedstrecket i slutet av en sökväg, så jag kontrollerar Information om sökvägen dubbel: /src/ vs. /src. Jag testar exkluderingar med -dry-run och -itemise-changes för att se effekten. Jag citerar mönster med mellanslag korrekt och behåller exkluderingsfilen i förvaret. Före -delete kontrollerar jag monteringar, eftersom ett omonterat mål kan leda till oönskad radering. Slutligen loggar jag returkoder och aktiverar larm så att jag kan se fel omedelbart.
Backup-strategi: GFS och återställningsmål
Jag ställer in RPO/RTO först, eftersom det är klart Mål vägleda varje beslut om frekvens, lagringsplats och lagring. Ett vanligt schema är GFS: daglig differentiell, veckovis fullständig eller sammanslagen via hårda länkar, månatlig långsiktig. Krav på efterlevnad påverkar lagringsperioden, så jag separerar kortlivade operativa data från långsiktiga arkiv. För kritiska system planerar jag säkerhetskopiering på annan plats utöver lokala kopior. Den här kombinationen skyddar mot driftstörningar och möjliggör både snabb och fjärrstyrd återställning.
Cron eller systemd-timer: Tillförlitlig planering
Cron är enkelt och robust. För värdar som ibland sover eller startar om använder jag också systemd-timer med beroenden och hantering av missade körningar. Detta säkerställer att ingen körning misslyckas efter en omstart och att sekvensen är korrekt (t.ex. efter nätverksåterställning).
# /etc/systemd/system/rsync-backup.service
[Enhet]
Beskrivning=Rsync Backup
Efter=nätverk-online.mål
Vill ha=nätverk-online.mål
[Tjänst]
Typ=oneshot
ExecStart=/usr/local/bin/rsync-backup.sh
Trevlig=10
IOS-planeringsklass=bästa ansträngning
IOS-planeringsprioritet=7
# /etc/systemd/system/rsync-backup.timer
[Enhet]
Beskrivning=Daglig timer för säkerhetskopiering av Rsync
[Timer]
PåKalender=02:00
Ihållande=true
[Install]
WantedBy=timers.target
Tabell: Viktiga rsync-alternativ i vardagen
Jag använder några få, men effektiva Alternativsom jag dokumenterar för varje jobb och version i repot. Arkivläget utgör grunden och minskar konfigurationsfel. Jag håller speglarna rena med -delete, men använder det bara med rätt målkontroll. För versionshantering kombinerar jag -link-dest med en rotationsplan. Följande tabell visar de viktigaste switcharna och hur de används.
| Alternativ | Syfte | Ledtråd |
|---|---|---|
| -a | Arkivläge | Tar över rättigheter, tider och ägande för Samstämmighet |
| -z | Kompression | Användbar för WAN, ofta utelämnad lokalt |
| -radera | Tar bort borttagna äldre filer | Använd endast med speglar, provkör i förväg |
| -bwlimit=KBPS | Bandbredd för gasreglage | Skyddar Produktiva system från belastningstoppar |
| -länk-dest=DIR | Versionering via hårda länkar | Ekonomiska generationer med separata mappar |
| -e "ssh ..." | Säker transport | Nycklar, värdnycklar, restriktiva användare |
| -n / -dry-run | Testkörning utan ändringar | Visar planerade åtgärder i förväg |
Teståterställning: Återställ övningar
Jag testar regelbundet återställningen, eftersom en säkerhetskopia utan återställning bara är Utseende är. För prover återställer jag enskilda filer och hela webbroots i staging-miljöer. Jag säkerhetskopierar databaser separat med hjälp av dumpar och importerar dem på testbasis för att kontrollera konsekvensen. Kontrollsummor hjälper mig att bekräfta integriteten och känna igen tysta bitfel. Efter varje test anpassar jag dokumentationen, skripten och spelböckerna så att nästa nödsituation går snabbare.
Bare metal- och systembackuper: specialfunktioner
För säkerhetskopiering av system eller bara metall utökar jag rsync-alternativen till ACL:er, xattrs och hårda länkar att ta med sig. På Linux har -aAXH och -numeric-ids visat sig vara värdefulla. Jag utesluter pseudofilsystem som /proc, /sys, /run, /dev/pts och säkerhetskopierar start- och konfigurationsfiler separat.
# Systemrelaterad säkerhetskopiering (exempel)
rsync -aAXH --numeriska-id \
--exclude={"/proc/*","/sys/*","/run/*","/dev/pts/*","/tmp/*"} \
/ root@backup:/srv/backups/hostA/current/
# Återställning (förenklad, från levande medium)
rsync -aAXH --numeric-ids /srv/backups/hostA/current/ /mnt/mål/
chroot /mnt/target update-initramfs -u
grub-install /dev/sda && uppdatera-grub
Jag planerar mer tid för sådana återställningar, dokumenterar sekvensen och håller bootloader-steg till hands. Detta minskar stressen avsevärt i en nödsituation.
Plesk-integration: smart kombination av paneljobb
Jag kombinerar Plesk-uppgifter med rsync så att Säkerhetskopiering av panel och offsite-kopior fungerar tillsammans. Post-backup hooks överför omedelbart nya säkerhetskopior till extern lagring. Scheman sammanfaller med underhållsfönster så att utplaceringar och säkerhetskopior inte stör varandra. Loggrotation i panelen och på målsystemet förhindrar växande loggkataloger. En bra utgångspunkt tillhandahålls av Bästa praxis för Plesk med fokus på repeterbara processer.
cPanel-integration: Homedir och databaser
Jag drar sedan cPanel-säkerhetskopior till en extern värd via rsync så att Skydd utanför anläggningen förblir utan ytterligare belastning. Katalogstrukturen underlättar selektiva återställningar av enskilda konton. För stora återförsäljarkonfigurationer planerar jag differentiella körningar över natten och fullständiga återställningar på helgen. I kombination med kvoter och rotationer håller jag lagringskraven transparenta. Ett praktiskt tillägg är anteckningarna om Säkerhetskopior av cPanel för en stabil daglig verksamhet.
Skalning och struktur: hantera många jobb på ett smidigt sätt
När miljöerna växer strukturerar jag källor och exkluderingar centralt. Med -filer-ifrån Jag överför listor som jag versionerar i repot. På så sätt kan jag ändra poster utan att röra skript och hålla platserna konsekventa.
#-filer-från exempel
/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/
Jag undviker överlappningar genom att tydligt separera ansvaret för sökvägar (t.ex. Webroot separat från loggar). För stora uppsättningar planerar jag medvetet parallellitet - hellre några få, vältajmade jobb än dussintals konkurrerande processer.
Robusthet i drift: låsning, omförsök, timeouts
För att undvika överlappningar använder jag flock eller låsta filer. Jag fångar upp nätverksproblem med Retries och -partial. Med -timeout avslutar jag hängande anslutningar på ett snyggt sätt och larmar.
# /usr/local/bin/rsync-backup.sh (utdrag)
#!/usr/bin/env bash
set -euo pipefail
exec 9> /var/lock/rsync-backup.lock
flock -n 9 || { echo "Säkerhetskopieringen körs redan"; exit 1; }
LOG=/var/log/rsync-backup.log
SRC=/data/www/
DST=backup@backuphost:/srv/backups/www/
for i in {1..3}; do
if rsync -a --delete --partial --timeout=600 -e "ssh -i /root/.ssh/backup_key" "$SRC" "$DST"; then
echo "OK"; exit 0
fi
echo "Försök igen $i" | tee -a "$LOG"
sömn 60
gjort
echo "Fel efter omförsök" >> "$LOG"; exit 1
Alternativ för specialfall: ACL, xattrs, sparse och atomicitet
Jag anpassar rsync beroende på datatyp. För webb- och systemsökvägar säkerhetskopierar jag ACL:er och xattrs med -A -X. Stora, sällan använda filer (VM-bilder, databaser) drar nytta av -sparsam. Med -fördröjning-uppdateringar och -delete-fördröjning Jag minimerar mellanliggande tillstånd och uppnår kvasi-atomära uppdateringar på målet. För känsliga data undviker jag -inplace så att defekta överföringar inte skriver över den senast fungerande kopian.
# Exempel för omfattande metadata
rsync -aAXH --sparse --delete-delay --delay-updates SRC/ DST/
Om jag behöver absolut atomiska kataloger (t.ex. för staging) synkroniserar jag till ett tillfälligt mål och körning och använd sedan mv för att byta till live-katalogen.
Säkra raderingsgränser och rimlighetskontroller
För att förhindra katastrofer som orsakas av felaktig konfiguration ställer jag in -max-delete än Guardrail. Jag kontrollerar också mounts, ledigt minne och inodes före körningen. Jag loggar den senaste lyckade säkerhetskopieringen och varnar för outliers (extrema raderings- eller modifieringshastigheter).
# Skydd mot massradering
rsync -a --delete --max-delete=5000 SRC/ DST/
# Plausibilitetskontroll (enkel)
df -h /srv/backups
df -i /srv/backups
Kortfattat sammanfattat: Så här går jag tillväga
Jag definierar RPO/RTO först, eftersom det är tydligt Prioriteringar vägleda varje tekniskt val. Sedan skriver jag ett smidigt skript, testar med -dry-run och loggar varje körning. Med SSH-nycklar, bandbreddsbegränsningar och versionshantering säkerhetskopierar jag på ett effektivt och spårbart sätt. Offsite-destinationer kompletterar lokala kopior, och regelbundna återställningsövningar bekräftar dess lämplighet. Så min rsync-backup förblir pålitlig, snabb och alltid redo att användas.
