Videre til indhold 
Jeg automatiserer min rsync-backupfor at undgå fejl og holde genoprettelser forudsigelige. Med klare Cron-jobsSSH-transport og inkrementelle kørsler, jeg sikrer effektivt webservere, databaser og konfigurationer.
Centrale punkter
- AutomatiseringTidsstyrede jobs reducerer fejl og besvær.
- EffektivitetDelta-overførsel sparer båndbredde og hukommelse.
- SikkerhedSSH, nøglehåndtering og offsite-mål.
- StrategiGFS-fastholdelse og klare RPO/RTO-mål.
- GennemsigtighedLogning, overvågning og gendannelsestest.
Hvorfor jeg automatiserer backups
Jeg sikrer konsekvent produktive systemer, fordi en enkelt fejl kan få hele projekter til at gå i stå, og jeg Tilgængelighed ønsker at garantere. En planlagt backup kl. 02:00 erstatter fejlbehæftet manuelt arbejde og sikrer rene datastatusser. Jeg definerer klare mål for hver server: Hvor meget datatab er acceptabelt (RPO), og hvor hurtigt skal gendannelsen finde sted (RTO). Disse mål påvirker tidsplanen, lagringsmålet og mulighederne, så jeg kan sikre driften på en pålidelig måde. Især for webservere reducerer jeg risikoen for hardwarefejl, ransomware eller utilsigtet sletning til et beregneligt minimum.
rsync kort forklaret: Funktionalitet og styrker
rsync overfører kun ændringer, bruger en effektiv Delta-overførsel og undgår unødvendige kopier. Det reducerer runtimes, netværksbelastning og IO på målsystemet betydeligt. Jeg arbejder i arkivtilstand (-a), så tilladelser, tidspunkter, ejere og symlinks forbliver konsistente. Jeg bruger -delete til at holde spejle opdaterede, men er opmærksom på den tilsigtede brug og kombinerer det med separate mapper til versionering. Jeg bruger SSH til transport, direkte stier til lokale jobs og tilføjer komprimering (-z) og båndbreddebegrænsning (-bwlimit), hvis det er nødvendigt.
Automatisering med Cron: trin for trin
Jeg starter med et simpelt script, fordi det er klart Basislinjer kan udvides senere. Først installerer jeg rsync, hvis det mangler, og opretter en sikker arbejdsmappe til logfiler og status. Derefter skriver jeg et script med kilder, mål og fornuftige indstillinger, herunder udelukkelser. Cronjobbet kører dagligt eller hver time afhængigt af RPO og skriver logfiler til evaluering og alarmering. En tørkørsel (-n) før den første produktive kørsel forhindrer uønskede sletninger.
Installation af # (Debian/Ubuntu)
sudo apt-get installer rsync
# Minimal kørsel lokalt
rsync -a /data/www/ /backup/www/
# Fjernspejling via SSH med sletninger
rsync -a --delete -e "ssh -i /root/.ssh/backup_key" /data/www/ backup@backuphost:/srv/backups/www/
# Cron: dagligt kl. 02:00.
0 2 * * * * /usr/local/bin/rsync-backup.sh >> /var/log/rsync-backup.log 2>&1
Sæt SSH-sikkerhedskopier op på en sikker måde
Jeg bruger SSH-nøgler med begrænsede rettigheder, fordi Nøglehåndtering reducerer angrebsfladen. På målsystemet begrænser jeg kommandoer ved hjælp af authorised_keys og bruger en separat backup-bruger. Fail2ban, firewall-regler og restriktive SSH-indstillinger (f.eks. PasswordAuthentication no) øger sikkerheden. Jeg gemmer værtsnøglen, så man-in-the-middle ikke har nogen chance. Hvis du er på udkig efter en struktureret start, kan du finde afprøvede og testede ideer på Automatiser backups.
Pull i stedet for push: sikkerhedsfordele i praksis
Hvor det er muligt, lader jeg Rollup af backup-server i stedet for at skubbe produktionsserveren. Det efterlader produktionssystemerne uden udgående nøgler, og en kompromitteret webserver kan ikke slette offsite-sikkerhedskopier. På målet begrænser jeg nøglen i authorised_keys med restriktive indstillinger og en tvungen kommando.
# Eksempel 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/autoriserede_nøgler
Det kaldte script tillader kun rsync-serverkald og sætter stibegrænsninger. Dette er, hvordan jeg opnår en Princippet om minimale rettighederuden at komplicere betjeningen.
Versionering og lagring med hårde links
For flere stande bygger jeg daglige, ugentlige og månedlige mapper med -link-dest, fordi Hårde forbindelser Sparer hukommelse og forenkler gendannelser. Hver generation henviser til identiske, uændrede filer fra den forrige sikkerhedskopi; nye eller ændrede filer ender fysisk i den nye mappe. Det giver mig mulighed for at opnå mange gendannelsespunkter med moderate lagerkrav. Jeg fjerner gamle generationer med et simpelt rotationsscript uden at risikere datakonsistens. En fast tidsplan (f.eks. 7 dage, 4 uger, 6 måneder) holder lagerplanlægningen klar og gennemsigtig.
Styring af ressourcer: Båndbredde, CPU og I/O
Jeg begrænser datagennemstrømningen med -bwlimit, så Produktiv belastning forbliver stabil, og brugerne oplever ingen tab. Jeg bruger nice og ionice til at prioritere backup-processerne. På langsomme netværk slår jeg komprimering til (-z), på hurtige lokale medier lader jeg den være slået fra. For store filer vælger jeg -partial for at kunne fortsætte med at annullere overførsler. Til lokale spejle bruger jeg ofte -whole-file, fordi delta-algoritmen ikke har nogen fordele der.
Konsistente datastatusser: snapshots og databaser
For at opretholde konsistente sikkerhedskopier på trods af åbne filer bruger jeg Øjebliksbilleder eller applikationskroge. Filsystemer som LVM, ZFS eller Btrfs giver mulighed for hurtige snapshots, som jeg bruger som kilde til rsync. Det giver mig mulighed for logisk at fastfryse datastatus uden at blokere tjenester i lang tid.
# Eksempel: LVM-snapshot som konsistent kilde
lvcreate -L 10G -s -n data_snap /dev/vg0/data
mount /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
For Databaser Jeg adskiller logik og filer. Jeg sikkerhedskopierer MySQL/MariaDB via dump eller Percona/Xtra-løsninger, PostgreSQL med pg_dump eller basebackups. Rækkefølgen er vigtig: Opret først et konsistent dump, og overfør derefter dumpstien via rsync. Dette forhindrer halvskrevne filer i sikkerhedskopien.
Typiske fejlkilder og hvordan man undgår dem
Den mest almindelige snublesten er skråstregen i slutningen af en sti, så jeg tjekker Detaljer om stien dobbelt: /src/ vs. /src. Jeg tester eksklusioner med -dry-run og -itemise-changes for at se effekten. Jeg citerer mønstre med mellemrum korrekt og opbevarer ekskluderingsfilen i repository'et. Før -delete tjekker jeg mounts, fordi et umonteret mål kan føre til uønsket sletning. Endelig logger jeg returkoder og aktiverer alarmer, så jeg kan se fejl med det samme.
Backup-strategi: GFS og gendannelsesmål
Jeg indstiller RPO/RTO først, fordi klar Mål styrer alle beslutninger om hyppighed, lagringssted og opbevaring. En almindelig ordning er GFS: daglig differentieret, ugentlig fuld eller flettet via hardlinks, månedlig langsigtet. Overensstemmelseskrav påvirker opbevaringsperioden, så jeg adskiller kortlivede driftsdata fra langtidsarkiver. For kritiske systemer planlægger jeg offsite-sikkerhedskopier i tillæg til lokale kopier. Denne kombination beskytter mod fejl på stedet og muliggør både hurtige og eksterne gendannelser.
Cron eller systemd-timer: Pålidelig planlægning
Cron er enkel og robust. Til værter, der af og til sover eller genstarter, bruger jeg også systemd-timer med afhængigheder og håndtering af manglende kørsler. Det sikrer, at ingen kørsler mislykkes efter en genstart, og at rækkefølgen er korrekt (f.eks. efter netværksgenoprettelse).
# /etc/systemd/system/rsync-backup.service
[Unit]
Beskrivelse=Rsync Backup
Efter=netværk-online.target
Ønsker=network-online.target
[Tjeneste]
Type=oneshot
ExecStart=/usr/local/bin/rsync-backup.sh
Nice=10
IOSchedulingClass=bedste indsats
IOSchedulingPriority=7
# /etc/systemd/system/rsync-backup.timer
[Unit]
Beskrivelse=Daglig Rsync-backup-timer
[Timer]
OnCalendar=02:00
Vedvarende=true
[Install]
WantedBy=timers.target
Tabel: Vigtige rsync-muligheder i hverdagen
Jeg bruger nogle få, men effektive Valgmulighedersom jeg dokumenterer for hvert job og hver version i repoen. Arkivtilstand danner grundlaget og reducerer konfigurationsfejl. Jeg holder spejlene rene med -delete, men bruger det kun med den korrekte målkontrol. Til versionering kombinerer jeg -link-dest med en rotationsplan. Følgende tabel viser de vigtigste switches og deres anvendelse.
| Mulighed | Formål | Hint |
|---|---|---|
| -a | Arkivtilstand | Påtager sig rettigheder, tider og ejerskab for Konsistens |
| -z | Kompression | Nyttig til WAN, ofte udeladt lokalt |
| -slette | Fjerner fjernede ældre filer | Brug kun med spejle, tørkørsel på forhånd |
| -bwlimit=KBPS | Gashåndtagets båndbredde | Beskytter Produktive systemer fra belastningsspidser |
| -link-dest=DIR | Versionering via hårde links | Økonomiske generationer med separate mapper |
| -e "ssh ..." | Sikker transport | Nøgler, værtsnøgler, restriktive brugere |
| -n / -dry-run | Testkørsel uden ændringer | Viser planlagte handlinger på forhånd |
Test af gendannelse: Gendan øvelser
Jeg tester jævnligt gendannelsen, fordi en backup uden gendannelse kun er Udseende er. Til prøver gendanner jeg individuelle filer og hele webroots i staging-miljøer. Jeg sikkerhedskopierer databaser separat ved hjælp af dumps og importerer dem på testbasis for at kontrollere konsistensen. Checksummer hjælper mig med at bekræfte integriteten og genkende stille bitfejl. Efter hver test tilpasser jeg dokumentation, scripts og playbooks, så den næste nødsituation kører hurtigere.
Bare metal- og systembackup: særlige funktioner
Til system- eller bare-metal-sikkerhedskopier udvider jeg rsync-indstillingerne til ACL'er, xattrs og hardlinks at tage med sig. På Linux har -aAXH og -numeric-ids vist deres værd. Jeg udelukker pseudo-filsystemer som /proc, /sys, /run, /dev/pts og sikkerhedskopierer boot- og konfigurationsfiler separat.
# Systemrelateret backup (eksempel)
rsync -aAXH --numeriske-id'er \
--exclude={"/proc/*","/sys/*","/run/*","/dev/pts/*","/tmp/*"} \
/ root@backup:/srv/backups/hostA/current/
# gendannelse (forenklet, fra live-medie)
rsync -aAXH --numeric-ids /srv/backups/hostA/current/ /mnt/target/
chroot /mnt/target update-initramfs -u
grub-install /dev/sda && update-grub
Jeg planlægger mere tid til sådanne gendannelser, dokumenterer sekvensen og har bootloader-trin ved hånden. Det reducerer stress betydeligt i en nødsituation.
Plesk-integration: smart kombination af paneljobs
Jeg kombinerer Plesk-opgaver med rsync, så Sikkerhedskopier af paneler og offsite-kopier arbejder sammen. Post-backup hooks overfører straks friske backups til ekstern lagring. Tidsplaner falder sammen med vedligeholdelsesvinduer, så udrulninger og sikkerhedskopieringer ikke forstyrrer hinanden. Logrotation i panelet og på målsystemet forhindrer voksende logkataloger. Et godt udgangspunkt er givet af Bedste praksis for Plesk med fokus på gentagelige processer.
cPanel-integration: Homedirs og databaser
Jeg trækker derefter cPanel-sikkerhedskopier til en ekstern host via rsync, så Offsite-beskyttelse forbliver uden yderligere belastning. Katalogstrukturen gør det lettere at foretage selektive gendannelser af individuelle konti. Til store forhandleropsætninger planlægger jeg differentierede kørsler om natten og fulde stande i weekenden. I kombination med kvoter og rotationer holder jeg lagerkravene gennemsigtige. En praktisk tilføjelse er noterne om cPanel-sikkerhedskopier for en solid daglig drift.
Skalering og struktur: håndter mange jobs på en ren måde
Når miljøerne vokser, strukturerer jeg kilder og udelukkelser centralt. Med -filer-fra Jeg overfører lister, som jeg versionerer i repoen. På den måde ændrer jeg poster uden at røre ved scripts og holder placeringerne konsistente.
#-filer - fra eksempel
/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/
Jeg undgår overlapninger ved klart at adskille stiansvar (f.eks. Webroot separat fra logfiler). Ved store mængder planlægger jeg bevidst parallelitet - hellere nogle få, veltimede jobs end dusinvis af konkurrerende processer.
Robusthed i drift: låsning, gentagelser, timeouts
For at undgå overlapninger bruger jeg flok eller lockfiles. Jeg opfanger netværksproblemer med Retries og -partial. Med -timeout afslutter jeg hængende forbindelser rent og udløser en alarm.
# /usr/local/bin/rsync-backup.sh (uddrag)
#!/usr/bin/env bash
set -euo pipefail
exec 9> /var/lock/rsync-backup.lock
flock -n 9 || { echo "Backup kører allerede"; 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 "Prøv igen $i" | tee -a "$LOG"
sleep 60
færdig
echo "Fejl efter nye forsøg" >> "$LOG"; exit 1
Indstillinger for særlige tilfælde: ACL'er, xattrs, sparse og atomicitet
Jeg tilpasser rsync afhængigt af datatypen. For web- og systemstier tager jeg backup af ACL'er og xattrs med -A -X. Store, sparsomt anvendte filer (VM-images, databaser) har gavn af -sparsom. Med -forsink-opdateringer og -delete-forsinkelse Jeg minimerer mellemliggende tilstande og opnår kvasi-atomiske opdateringer på målet. For følsomme data undgår jeg -inplace, så defekte overførsler ikke overskriver den sidste gode kopi.
# Eksempel på omfattende metadata
rsync -aAXH --sparse --delete-delay --delay-updates SRC/ DST/
Hvis jeg har brug for absolut atomare mapper (f.eks. til staging), synkroniserer jeg til et midlertidigt mål og løbe Brug derefter mv til at skifte til live-biblioteket.
Sikre grænser for sletning og sandsynlighedskontrol
For at forhindre katastrofer forårsaget af fejlkonfiguration sætter jeg -max-sletning end Guardrail. Jeg tjekker også mounts, ledig hukommelse og inodes før kørslen. Jeg logger den sidste vellykkede backup og advarer om outliers (ekstreme sletnings- eller ændringsrater).
# Beskyttelse mod massesletning
rsync -a --delete --max-delete=5000 SRC/ DST/
# Plausibilitetskontrol (simpel)
df -h /srv/backups
df -i /srv/backups
Kort opsummeret: Sådan gør jeg
Jeg definerer RPO/RTO først, fordi det er klart Prioriteringer vejlede om alle tekniske valg. Derefter skriver jeg et slankt script, tester med -dry-run og logger hver eneste udførelse. Med SSH-nøgler, båndbreddegrænser og versionering tager jeg effektiv og sporbar backup. Offsite-destinationer supplerer lokale kopier, og regelmæssige gendannelsesøvelser bekræfter deres egnethed. Så min rsync-backup forbliver pålidelig, hurtig og altid klar til brug.
