Przejdź do treści 
Automatyzuję moje Kopia zapasowa rsyncaby uniknąć awarii i zapewnić przewidywalne odzyskiwanie danych. Z jasnym Zadania CronTransport SSH i uruchomienia przyrostowe, skutecznie zabezpieczam serwery WWW, bazy danych i konfiguracje.
Punkty centralne
- AutomatyzacjaKontrolowane czasowo zadania zmniejszają liczbę błędów i nakład pracy.
- WydajnośćTransfer Delta oszczędza przepustowość i pamięć.
- BezpieczeństwoSSH, zarządzanie kluczami i cele offsite.
- StrategiaUtrzymanie GFS i jasne cele RPO/RTO.
- PrzejrzystośćRejestrowanie, monitorowanie i testy przywracania.
Dlaczego automatyzuję tworzenie kopii zapasowych
Konsekwentnie zabezpieczam wydajne systemy, ponieważ pojedyncza awaria może doprowadzić do zatrzymania całych projektów, a ja Dostępność chce zagwarantować. Zaplanowane tworzenie kopii zapasowych o godzinie 02:00 zastępuje podatną na błędy pracę ręczną i zapewnia czysty stan danych. Definiuję jasne cele dla każdego serwera: Jak duża utrata danych jest akceptowalna (RPO) i jak szybko musi nastąpić odzyskiwanie (RTO). Cele te wpływają na harmonogram, docelową pamięć masową i opcje, dzięki czemu mogę niezawodnie zabezpieczyć operacje. W szczególności w przypadku serwerów internetowych ograniczam ryzyko usterek sprzętowych, oprogramowania ransomware lub przypadkowego usunięcia danych do obliczalnego minimum.
Krótkie wyjaśnienie rsync: funkcjonalność i mocne strony
rsync przenosi tylko zmiany, wykorzystuje wydajną metodę Transfer Delta i unika niepotrzebnych kopii. Znacząco skraca to czas wykonywania, zmniejsza obciążenie sieci i zmniejsza ilość operacji wejścia-wyjścia w systemie docelowym. Pracuję w trybie archiwum (-a), dzięki czemu uprawnienia, czasy, właściciele i dowiązania symboliczne pozostają spójne. Używam -delete do utrzymywania aktualnych kopii lustrzanych, ale zwracam uwagę na przeznaczenie i łączę je z oddzielnymi katalogami do wersjonowania. Używam SSH do transportu, bezpośrednich ścieżek dla zadań lokalnych i dodaję kompresję (-z) i limit przepustowości (-bwlimit), jeśli jest to wymagane.
Automatyzacja z Cron: krok po kroku
Zaczynam od prostego skryptu, ponieważ Wartości bazowe można rozszerzyć później. Najpierw instaluję rsync, jeśli go brakuje, i tworzę bezpieczny katalog roboczy dla logów i statusu. Następnie piszę skrypt ze źródłami, celem i rozsądnymi opcjami, w tym wykluczeniami. Cronjob działa codziennie lub co godzinę w zależności od RPO i zapisuje pliki dziennika do oceny i alertów. Suchy przebieg (-n) przed pierwszym uruchomieniem produkcyjnym zapobiega niechcianym usunięciom.
Instalacja # (Debian/Ubuntu)
sudo apt-get install rsync
# Minimal uruchamiany lokalnie
rsync -a /data/www/ /backup/www/
# Zdalna kopia lustrzana przez SSH z usuwaniem
rsync -a --delete -e "ssh -i /root/.ssh/backup_key" /data/www/ backup@backuphost:/srv/backups/www/
# Cron: codziennie o 02:00.
0 2 * * * * * /usr/local/bin/rsync-backup.sh >> /var/log/rsync-backup.log 2>&1
Bezpieczne konfigurowanie kopii zapasowych SSH
Używam kluczy SSH z ograniczonymi uprawnieniami, ponieważ Zarządzanie kluczami zmniejsza powierzchnię ataku. W systemie docelowym ograniczam polecenia za pomocą authorised_keys i używam oddzielnego użytkownika kopii zapasowej. Fail2ban, reguły firewalla i restrykcyjne opcje SSH (np. PasswordAuthentication no) zwiększają bezpieczeństwo. Przechowuję klucz hosta, więc man-in-the-middle nie ma szans. Jeśli szukasz zorganizowanego startu, możesz znaleźć wypróbowane i przetestowane pomysły na stronie Automatyzacja tworzenia kopii zapasowych.
Pull zamiast push: korzyści bezpieczeństwa w praktyce
Tam, gdzie to możliwe, zostawiam Kopia zapasowa rollup serwera zamiast wypychać serwer produkcyjny. Pozostawia to systemy produkcyjne bez kluczy wychodzących, a skompromitowany serwer WWW nie może usunąć kopii zapasowych poza siedzibą firmy. Na celu ograniczam klucz w authorized_keys z restrykcyjnymi opcjami i wymuszonym poleceniem.
# Przykład authorised_keys na docelowej kopii zapasowej
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
Wywołany skrypt zezwala tylko na wywołania serwera rsync i ustawia limity ścieżek. W ten sposób osiągam Zasada praw minimalnychbez komplikowania obsługi.
Wersjonowanie i przechowywanie za pomocą twardych linków
Dla kilku stanowisk buduję dzienne, tygodniowe i miesięczne foldery z -link-dest, ponieważ Hardlinks Oszczędza pamięć i upraszcza przywracanie. Każda generacja odnosi się do identycznych, niezmienionych plików z poprzedniej kopii zapasowej; nowe lub zmienione pliki trafiają fizycznie do nowego folderu. Pozwala mi to osiągnąć wiele punktów przywracania przy umiarkowanych wymaganiach dotyczących pamięci masowej. Stare generacje usuwam za pomocą prostego skryptu rotacji bez ryzyka utraty spójności danych. Ustalony harmonogram (np. 7 dni, 4 tygodnie, 6 miesięcy) sprawia, że planowanie przestrzeni dyskowej jest jasne i przejrzyste.
Kontrola zasobów: Przepustowość, CPU i I/O
Ograniczam przepustowość danych za pomocą -bwlimit tak, aby Obciążenie produkcyjne pozostaje stabilny, a użytkownicy nie doświadczają żadnych strat. Używam nice i ionice do nadawania priorytetów procesom tworzenia kopii zapasowych. Włączam kompresję (-z) w wolnych sieciach i pozostawiam ją wyłączoną na szybkich nośnikach lokalnych. W przypadku dużych plików wybieram -partial, aby móc kontynuować anulowane transfery. W przypadku lokalnych mirrorów często używam -whole-file, ponieważ algorytm delta nie ma tam żadnych zalet.
Spójne stany danych: migawki i bazy danych
Aby utrzymać spójne kopie zapasowe pomimo otwartych plików, używam Migawki lub haki aplikacji. Systemy plików takie jak LVM, ZFS czy Btrfs pozwalają na szybkie snapshoty, które wykorzystuję jako źródło dla rsync. Pozwala mi to logicznie zamrozić stan danych bez blokowania usług przez długi czas.
# Przykład: Migawka LVM jako spójne źródło danych
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
Dla Bazy danych Oddzielam logikę od plików. Tworzę kopie zapasowe MySQL/MariaDB za pomocą dump lub rozwiązań Percona/Xtra, PostgreSQL za pomocą pg_dump lub basebackups. Kolejność jest ważna: najpierw utwórz spójny zrzut, a następnie prześlij ścieżkę zrzutu przez rsync. Zapobiega to powstawaniu w połowie zapisanych plików w kopii zapasowej.
Typowe źródła błędów i sposoby ich unikania
Najczęstszą przeszkodą jest ukośnik na końcu ścieżki, więc sprawdzam Szczegóły ścieżki podwójnie: /src/ vs. /src. Testuję wykluczenia z -dry-run i -itemise-changes, aby zobaczyć efekt. Poprawnie cytuję wzorce ze spacjami i przechowuję plik wykluczenia w repozytorium. Przed -delete sprawdzam mocowania, ponieważ niezamontowany cel może prowadzić do niechcianego usunięcia. Wreszcie, rejestruję kody powrotu i aktywuję alarmy, dzięki czemu mogę natychmiast zobaczyć błędy.
Strategia tworzenia kopii zapasowych: GFS i cele odzyskiwania
Najpierw ustawiam RPO/RTO, ponieważ jasne Cele kieruje każdą decyzją dotyczącą częstotliwości, miejsca przechowywania i retencji. Powszechnym schematem jest GFS: codzienny różnicowy, tygodniowy pełny lub scalony za pomocą twardych łączy, miesięczny długoterminowy. Wymogi zgodności wpływają na okres przechowywania, więc oddzielam krótkotrwałe dane operacyjne od długoterminowych archiwów. W przypadku krytycznych systemów, oprócz kopii lokalnych, planuję kopie zapasowe poza siedzibą firmy. Takie połączenie chroni przed awariami lokalizacji i umożliwia zarówno szybkie, jak i zdalne przywracanie danych.
Cron lub systemd-timer: niezawodne planowanie
Cron jest prosty i solidny. W przypadku hostów, które od czasu do czasu usypiają lub restartują się, używam również systemd-timer z zależnościami i obsługą nieudanych uruchomień. Gwarantuje to, że żadne uruchomienie nie zakończy się niepowodzeniem po ponownym uruchomieniu i że sekwencja jest prawidłowa (np. po przywróceniu sieci).
# /etc/systemd/system/rsync-backup.service
[Jednostka]
Description=Rsync Backup
After=network-online.target
Chce=network-online.target
[Usługa]
Type=oneshot
ExecStart=/usr/local/bin/rsync-backup.sh
Nice=10
IOSchedulingClass=największy wysiłek
IOSchedulingPriority=7
# /etc/systemd/system/rsync-backup.timer
[Jednostka]
Description=Codzienny timer kopii zapasowej Rsync
[Timer]
OnCalendar=02:00
Persistent=true
[Install]
WantedBy=timers.target
Tabela: Ważne opcje rsync w codziennym życiu
Używam kilku, ale skutecznych Opcjektóre dokumentuję dla każdego zadania i wersji w repozytorium. Tryb archiwizacji stanowi podstawę i zmniejsza liczbę błędów konfiguracji. Utrzymuję mirrory w czystości za pomocą -delete, ale używam go tylko z poprawnym sprawdzeniem celu. Do wersjonowania łączę -link-dest z planem rotacji. Poniższa tabela przedstawia najważniejsze przełączniki i ich zastosowanie.
| Opcja | Cel | Wskazówka |
|---|---|---|
| -a | Tryb archiwizacji | Przyjmuje prawa, czasy, własność dla Spójność |
| -z | Kompresja | Przydatne dla sieci WAN, często pomijane lokalnie |
| -usuń | Usuwa usunięte starsze pliki | Używaj tylko z lusterkami, wcześniej wykonaj suchy bieg |
| -bwlimit=KBPS | Szerokość pasma przepustnicy | Chroni Wydajne systemy od szczytów obciążenia |
| -link-dest=DIR | Wersjonowanie za pomocą twardych linków | Ekonomiczne generacje z oddzielnymi folderami |
| -e "ssh ..." | Bezpieczny transport | Klucze, klucze hosta, restrykcyjni użytkownicy |
| -n / -dry-run | Test bez zmian | Pokazuje zaplanowane działania z wyprzedzeniem |
Odzyskiwanie testowe: Przywróć ćwiczenia
Regularnie testuję przywracanie, ponieważ kopia zapasowa bez przywracania to tylko Wygląd jest. W przypadku próbek przywracam pojedyncze pliki i całe webroots w środowiskach przejściowych. Tworzę kopie zapasowe baz danych oddzielnie za pomocą zrzutu i importuję je testowo, aby sprawdzić spójność. Sumy kontrolne pomagają mi potwierdzić integralność i rozpoznać ciche błędy bitowe. Po każdym teście dostosowuję dokumentację, skrypty i playbooki tak, aby następna awaria przebiegała szybciej.
Kopie zapasowe typu bare metal i systemu: funkcje specjalne
W przypadku kopii zapasowych systemu lub gołego metalu, rozszerzam opcje rsync na ACL, xattrs i hardlinki do zabrania ze sobą. W Linuksie, -aAXH i -numeric-ids udowodniły swoją wartość. Wykluczam pseudo systemy plików, takie jak /proc, /sys, /run, /dev/pts i tworzę kopie zapasowe plików rozruchowych i konfiguracyjnych osobno.
# Kopia zapasowa związana z systemem (przykład)
rsync -aAXH --numeric-ids \
--exclude={"/proc/*","/sys/*","/run/*","/dev/pts/*","/tmp/*"} \
/ root@backup:/srv/backups/hostA/current/
Przywracanie # (uproszczone, z nośnika live)
rsync -aAXH --numeric-ids /srv/backups/hostA/current/ /mnt/target/
chroot /mnt/target update-initramfs -u
grub-install /dev/sda && update-grub
Planuję więcej czasu na takie przywracanie, dokumentuję sekwencję i przechowuję kroki bootloadera pod ręką. To znacznie zmniejsza stres w sytuacjach awaryjnych.
Integracja z Plesk: sprytne łączenie zadań panelu
Łączę zadania Plesk z rsync, aby Kopie zapasowe panelu i kopie zewnętrzne współpracują ze sobą. Haki po utworzeniu kopii zapasowej natychmiast przenoszą świeże kopie zapasowe do zewnętrznej pamięci masowej. Harmonogramy pokrywają się z oknami konserwacji, dzięki czemu wdrożenia i kopie zapasowe nie kolidują ze sobą. Rotacja logów w panelu i systemie docelowym zapobiega rozrastaniu się katalogów logów. Dobrym punktem wyjścia jest Najlepsze praktyki Plesk z naciskiem na powtarzalne procesy.
Integracja z cPanel: katalogi domowe i bazy danych
Następnie pobieram kopie zapasowe cPanel do zewnętrznego hosta za pomocą rsync, dzięki czemu Ochrona poza siedzibą firmy pozostaje bez dodatkowego obciążenia. Struktura katalogów ułatwia selektywne przywracanie poszczególnych kont. W przypadku dużych konfiguracji odsprzedawców planuję uruchomienia różnicowe w nocy i pełne stanowiska w weekendy. W połączeniu z kwotami i rotacjami utrzymuję przejrzyste wymagania dotyczące pamięci masowej. Praktycznym dodatkiem są notatki na temat Kopie zapasowe cPanel za solidne codzienne operacje.
Skalowanie i struktura: czyste zarządzanie wieloma zadaniami
Gdy środowiska rosną, strukturyzuję źródła i wykluczenia centralnie. Z -pliki-od Przenoszę listy, które wersjonuję w repo. W ten sposób zmieniam rekordy bez dotykania skryptów i utrzymuję spójne lokalizacje.
Pliki # - na przykładzie
/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/
Unikam nakładania się zadań poprzez wyraźne oddzielenie odpowiedzialności za ścieżki (np. Webroot oddzielnie od logów). W przypadku dużych zestawów świadomie planuję równoległość - wolę kilka dobrze zgranych zadań niż dziesiątki konkurujących ze sobą procesów.
Solidność działania: blokowanie, ponawianie prób, timeouty
Aby uniknąć nakładania się, używam stado lub lockfile. Przechwytuję problemy sieciowe za pomocą Retries i -partial. Z -timeout kończę zawieszające się połączenia i podnoszę alarm.
# /usr/local/bin/rsync-backup.sh (fragment)
#!/usr/bin/env bash
set -euo pipefail
exec 9> /var/lock/rsync-backup.lock
flock -n 9 || { echo "Backup już działa"; 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 "Retry $i" | tee -a "$LOG"
sleep 60
done
echo "Error after retries" >> "$LOG"; exit 1
Opcje dla przypadków specjalnych: ACL, xattrs, sparse i atomowość
Dostosowuję rsync w zależności od typu danych. W przypadku ścieżek internetowych i systemowych tworzę kopie zapasowe Listy ACL i xattrs z -A -X. Duże, rzadko używane pliki (obrazy maszyn wirtualnych, bazy danych) korzystają z -rzadki. Z -delay-updates oraz -delete-delay Minimalizuję stany pośrednie i osiągam quasi-atomowe aktualizacje na celu. W przypadku wrażliwych danych unikam -inplace, aby wadliwe transfery nie nadpisywały ostatniej dobrej kopii.
# Przykład dla obszernych metadanych
rsync -aAXH --sparse --delete-delay --delay-updates SRC/ DST/
Jeśli potrzebuję absolutnie atomowych katalogów (np. do przemieszczania), synchronizuję się do tymczasowego celu i bieg następnie użyj mv, aby przełączyć się do katalogu live.
Bezpieczne limity usuwania i kontrole wiarygodności
Aby zapobiec katastrofom spowodowanym błędną konfiguracją, ustawiłem -max-delete niż Guardrail. Przed uruchomieniem sprawdzam również wierzchowce, wolną pamięć i i-węzły. Rejestruję ostatnią udaną kopię zapasową i ostrzegam przed wartościami odstającymi (ekstremalne wskaźniki usuwania lub modyfikacji).
# Ochrona przed masowym usuwaniem
rsync -a --delete --max-delete=5000 SRC/ DST/
# Sprawdzanie wiarygodności (proste)
df -h /srv/backups
df -i /srv/backups
Krótkie podsumowanie: Oto jak postępuję
Najpierw definiuję RPO/RTO, ponieważ jasne Priorytety kieruje każdym wyborem technicznym. Następnie piszę odchudzony skrypt, testuję za pomocą -dry-run i rejestruję każde wykonanie. Dzięki kluczom SSH, limitom przepustowości i wersjonowaniu tworzę kopie zapasowe w sposób wydajny i identyfikowalny. Miejsca docelowe poza siedzibą firmy uzupełniają kopie lokalne, a regularne ćwiczenia przywracania potwierdzają ich przydatność. Dzięki temu moje kopie zapasowe rsync pozostają niezawodne, szybkie i zawsze gotowe do użycia.
