Jak skonfigurować funkcje Btrfs Send i Receive do przyrostowych kopii zapasowych poza siedzibą firmy

Btrfs send i receive mogą przekształcić migawki podwolumenów tylko do odczytu w wydajny łańcuch replikacji zdalnej. Pierwszy transfer wysyła pełną migawkę. Późniejsze transfery używają wcześniej zreplikowanej migawki jako elementu nadrzędnego, dzięki czemu przez sieć przesyłane są tylko zmiany potrzebne do odtworzenia nowej migawki.

W ZimaOS najpierw potwierdź, że zarówno źródło, jak i zdalne miejsce docelowe są rzeczywiście systemami plików Btrfs oraz że dostęp przez SSH jest możliwy. Aktualny przewodnik ZimaSpace dotyczący formatów dysków wymienia obsługę odczytu i zapisu BTRFS, a przewodnik SSH dla ZimaOS pokazuje, jak włączyć dostęp do terminala z poziomu trybu deweloperskiego.

Zanim zaczniesz, poznaj łańcuch kopii zapasowych

Btrfs send/receive służy do replikacji podwolumenów, a nie do ogólnego kopiowania katalogów. Źródło musi być podwolumenem Btrfs, a każda migawka używana przez btrfs send musi być tylko do odczytu. Montowanie tylko do odczytu nie zastępuje migawki podwolumenu tylko do odczytu.

Oficjalna dokumentacja btrfs send opisuje dwa tryby. Pełne wysłanie zawiera całą migawkę. Wysłanie przyrostowe używa -p lub -c wraz z migawkami dostępnymi w tym samym stanie po stronie nadawcy i odbiorcy.

W przypadku prostego łańcucha zdalnego użyj jednego jawnie określonego elementu nadrzędnego za pomocą -p:

snapshot-A  --pełne wysłanie-->  migawka zdalna snapshot-A
snapshot-B  --send -p A-->  migawka zdalna snapshot-B
snapshot-C  --send -p B-->  migawka zdalna snapshot-C

Nie usuwaj ani nie modyfikuj bieżącego nadrzędnego podwolumenu, dopóki kolejny transfer przyrostowy nie zostanie ukończony i zweryfikowany.

Sprawdź, czy źródło jest podwolumenem Btrfs

Zastąp przykładowe ścieżki rzeczywistymi punktami montowania w swoim systemie. Katalog migawek powinien znajdować się poza aktywnym podwolumenem źródłowym, aby migawki kopii zapasowych nie stały się zagnieżdżone w chronionych danych.

findmnt -no FSTYPE --target /mnt/pool/data
sudo btrfs subvolume show /mnt/pool/data
sudo btrfs version

Pierwsze polecenie powinno wyświetlić btrfs. Druga powinna poprawnie rozpoznać /mnt/pool/data jako podwolumenu. Jeśli jest tylko zwykłym katalogiem, zatrzymaj się tutaj: btrfs send nie może wysyłać dowolnego katalogu.

Uruchom tę samą kontrolę systemu plików w systemie zdalnym dla lokalizacji odbioru. btrfs receive musi utworzyć swój replikowany podwolumen w systemie plików Btrfs.

Przygotuj SSH przed przesyłaniem danych kopii zapasowej

Strumień wysyłania poza siedzibę zawiera binarne dane systemu plików. SSH jest praktycznym środkiem transportu, ponieważ zapewnia uwierzytelnianie i szyfrowanie podczas przesyłania. Jeśli używasz ZimaOS na którymkolwiek z punktów końcowych, najpierw włącz SSH i przetestuj zwykłe logowanie przed próbą przesłania strumienia Btrfs.

ssh backup@backup.example.net

W przypadku zadań wykonywanych bez nadzoru użyj uwierzytelniania SSH opartego na kluczach. Zdalne konto musi również móc uruchamiać btrfs receive nieinteraktywnie. Nie pozwól, aby zdalny sudo monit o hasło odczytywany z tego samego standardowego wejścia, które przenosi strumień Btrfs. Precyzyjnie ograniczona reguła uprawnień dla wymaganej operacji odbioru jest bezpieczniejsza niż szeroki dostęp root bez hasła.

Utwórz katalog docelowy podczas interaktywnej sesji administracyjnej:

ssh -t backup@backup.example.net \
  'sudo mkdir -p /mnt/backup/btrfs-recv'

Featured

ZimaCube 2 Osobisty domowy NAS w chmurze

ZimaCube2

$799.00 - $2,499.00

Buy Now

Utwórz pierwszą migawkę tylko do odczytu

Utwórz stałą migawkę źródłowego podwoluminu działającą tylko do odczytu. Ta -r Ta flaga ma znaczenie, ponieważ przyrostowe wysyłanie Btrfs zależy od migawek, które nie mogą zmienić się podczas operacji wysyłania.

sudo mkdir -p /mnt/pool/.snapshots

sudo btrfs subvolume snapshot -r \
  /mnt/pool/data \
  /mnt/pool/.snapshots/data-20260831-1000

Przed wysłaniem potwierdź właściwość:

sudo btrfs property get \
  /mnt/pool/.snapshots/data-20260831-1000 ro

Oczekiwany wynik to ro=true.

Wyślij pierwszą pełną migawkę poza siedzibę

Pierwszy transfer nie ma punktu odniesienia, więc jest pełnym wysyłaniem. W powłoce zgodnej z Bash włącz pipefail sprawia, że błąd po dowolnej stronie potoku jest widoczny dla powłoki wywołującej.

set -o pipefail

sudo btrfs send \
  /mnt/pool/.snapshots/data-20260831-1000 \
  | ssh backup@backup.example.net \
  'sudo -n btrfs receive /mnt/backup/btrfs-recv'

Jeśli sudo -n zakończy się niepowodzeniem na zdalnym hoście, napraw konfigurację uprawnień zdalnych przed ponowną próbą. Nie zastępuj tego monitem o hasło wewnątrz potoku przesyłania.

Oficjalna dokumentacja btrfs receive wskazuje, że pomyślnie odebrany podwolumin staje się tylko do odczytu. Ostrzega również, że nie należy modyfikować ścieżki odbioru podczas stosowania strumienia.

Zweryfikuj otrzymaną migawkę przed użyciem jej jako punktu odniesienia

Nie zakładaj, że zakończenie sesji SSH oznacza, że łańcuch kopii zapasowych działa prawidłowo. Sprawdź obie migawki:

sudo btrfs subvolume show \
  /mnt/pool/.snapshots/data-20260831-1000

ssh backup@backup.example.net \
  'sudo -n btrfs subvolume show \
  /mnt/backup/btrfs-recv/data-20260831-1000'

Na nadawcy zwróć uwagę na migawkę UUIDNa odbiorcy replikowany podwolumin powinien wskazywać ten identyfikator źródłowy jako swój Otrzymany identyfikator UUIDPotwierdź również, że otrzymany podwolumin jest tylko do odczytu.

Dopiero po tym sprawdzeniu należy data-20260831-1000 stać się punktem odniesienia dla następnej kopii przyrostowej.

Utwórz i wyślij kolejną migawkę przyrostową

Po zmianie danych na żywo utwórz nową migawkę tylko do odczytu:

sudo btrfs subvolume snapshot -r \
  /mnt/pool/data \
  /mnt/pool/.snapshots/data-20260901-0200

Następnie wyślij tylko różnicę względem poprzedniej migawki:

set -o pipefail

sudo btrfs send \
  -p /mnt/pool/.snapshots/data-20260831-1000 \
  /mnt/pool/.snapshots/data-20260901-0200 \
  | ssh backup@backup.example.net \
  'sudo -n btrfs receive /mnt/backup/btrfs-recv'

Działa to dlatego, że migawka nadrzędna z pierwszego wysyłania nadal istnieje w identycznej postaci na obu systemach. Po pomyślnym odebraniu i zweryfikowaniu nowej migawki data-20260901-0200 może stać się rodzicem dla kolejnego uruchomienia.

Zachowuj identyczne migawki nadrzędne

Najczęstszym sposobem przerwania łańcucha przyrostowego jest zmiana stanu tylko do odczytu lub zawartości migawki używanej jako rodzic. Btrfs śledzi odebrane migawki za pomocą odebranego identyfikatora UUID, aby nadawca i odbiorca mogli identyfikować odpowiadającą sobie historię.

Oficjalna dokumentacja Btrfs dotycząca flag podwoluminów i odebranych identyfikatorów UUID ostrzega, że zmiana odebranej migawki z tylko do odczytu na odczyt-zapis narusza założenia używane przez wysyłanie przyrostowe.

Z tego powodu nie ustawiaj migawki odbiorczej poza siedzibą jako zapisywalnej tylko po to, aby przeglądać, przywracać lub edytować pliki. Jeśli potrzebujesz zapisywalnej kopii odzyskiwania, utwórz oddzielną migawkę z chronionej migawki odbiorczej:

sudo btrfs subvolume snapshot \
  /mnt/backup/btrfs-recv/data-20260901-0200 \
  /mnt/restore/data-20260901-0200

Nowa migawka przywracania jest domyślnie zapisywalna, podczas gdy oryginalna migawka odbiorcza pozostaje niezmieniona na potrzeby przyszłych wysyłań przyrostowych.

Używaj bezpiecznej zasady przechowywania migawek

Nie musisz przechowywać wszystkich starych migawek na zawsze, ale musisz zachować na obu systemach rodzica wymaganego przez następne wysyłanie. Prosta zasada rotacji:

1. Utwórz nową migawkę źródłową tylko do odczytu.
2. Wyślij ją, używając poprzedniej pomyślnie utworzonej migawki jako -p.
3. Zweryfikuj nową migawkę odbiorczą poza siedzibą.
4. Ustaw nową migawkę jako następnego rodzica.
5. Dopiero wtedy usuń starsze punkty odzyskiwania zgodnie z zasadami przechowywania.

Przechowywanie kilku historycznych migawek może zapewnić przydatne punkty powrotu, ale pamiętaj, że migawka w tym samym systemie plików nie jest niezależną kopią zapasową. Replika poza siedzibą jest cenna, ponieważ umieszcza dodatkową kopię w oddzielnym systemie i lokalizacji. Przewodnik tworzenia kopii zapasowych 3-2-1 firmy ZimaSpace wyjaśnia, dlaczego kopia poza siedzibą chroni przed awariami, których lokalna redundancja nie jest w stanie obejść.

Osobno obsługuj zagnieżdżone podwoluminy Btrfs

Migawki Btrfs nie są rekurencyjne w przypadku zagnieżdżonych podwoluminów. Jeśli /mnt/pool/data zawiera inny podwolumin, migawka nadrzędna zawiera atrapę podwoluminu, a nie pełną migawkę zagnieżdżonych danych.

Wyświetl podwoluminy przed sfinalizowaniem planu tworzenia kopii zapasowych:

sudo btrfs subvolume list /mnt/pool

Jeśli ważne dane aplikacji znajdują się w zagnieżdżonych podwoluminach, utwórz i replikuj osobny łańcuch migawek tylko do odczytu dla każdego z nich.

Dowiedz się, kiedy używać opcji -p, a kiedy -c

W przypadku liniowej historii kopii zapasowych -p to najprostsza opcja i najłatwiejsza do sprawdzenia. Opcja -c opcja może dodać jedno lub więcej źródeł klonowania, które pozwalają Btrfs ponownie wykorzystać pasujące extenty z dodatkowych migawek, ale te źródła klonowania również muszą istnieć w dokładnie takim samym stanie po obu stronach.

Jeśli nie możesz potwierdzić, że źródło klonowania jest niezmienione i obecne w obu systemach, nie używaj go. Prosty łańcuch z jednym rodzicem jest zwykle bezpieczniejszy w zadaniu tworzenia kopii zapasowej poza siedzibą.

Opcjonalnie: użyj protokołu 2 dla skompresowanych extentów

W wystarczająco nowych wersjach systemu Linux i btrfs-progs protokół 2 wysyłania Btrfs może wydajniej przesyłać skompresowane extentу za pomocą --compressed-data. Oficjalna dokumentacja wysyłania podaje, że protokół 2 wymaga btrfs-progs w wersji 6.0 lub nowszej po stronie nadawcy i odbiorcy oraz systemu Linux 6.0 lub nowszego po stronie nadawcy.

sudo btrfs send \
  --proto 2 \
  --compressed-data \
  -p /mnt/pool/.snapshots/data-20260831-1000 \
  /mnt/pool/.snapshots/data-20260901-0200 \
  | ssh backup@backup.example.net \
  'sudo -n btrfs receive /mnt/backup/btrfs-recv'

Nie włączaj tej opcji tylko dlatego, że jest dostępna. Najpierw sprawdź wersje po obu stronach i używaj domyślnego protokołu, gdy zgodność jest ważniejsza niż optymalizacja.

Rozwiązywanie typowych problemów z przyrostowym wysyłaniem i odbieraniem

Polecenie send informuje, że migawka nie jest tylko do odczytu

Utwórz migawkę ponownie za pomocą btrfs subvolume snapshot -rSamo zamontowanie zapisywalnej migawki przez montowanie tylko do odczytu nie spełnia wymagań wysyłania.

Przyrostowe wysyłanie nie może znaleźć ani użyć swojego rodzica

Sprawdź, czy dokładny migawkowy rodzic nadal istnieje po stronie nadawcy oraz czy odpowiadająca mu odebrana migawka nadal istnieje po stronie odbiorcy. Jeśli którykolwiek z rodziców został usunięty, zmieniony lub stał się zapisywalny, przywróć pasującego rodzica, jeśli go masz. W przeciwnym razie utwórz nową migawkę tylko do odczytu i rozpocznij od nowa pełne zasiewanie.

btrfs receive informuje, że podwolumin docelowy już istnieje

btrfs receive nie nadpisze istniejącego podwoluminu o tej samej nazwie przychodzącej. Najpierw sprawdź istniejący podwolumin. Jeśli odbiór zakończył się niepowodzeniem lub jest niekompletny, a Ty potwierdziłeś, że można go bezpiecznie usunąć, usuń ten niekompletny podwolumin przed ponowieniem tego samego przesyłania.

Rodzic po stronie odbiorczej został zmodyfikowany po jego odebraniu

Nie używaj zmodyfikowanej migawki jako podstawy nowego strumienia przyrostowego. Jeśli nie istnieje niezmieniony, pasujący rodzic po stronie odbiorczej, rozpocznij nowy łańcuch pełnej kopii zapasowej.

Brakuje plików znajdujących się w zagnieżdżonym katalogu migawki

Sprawdź, czy ten katalog sam jest podwoluminem Btrfs. Zagnieżdżone podwoluminy nie są rekurencyjnie uwzględniane w migawce nadrzędnej i wymagają własnego łańcucha wysyłania/odbioru.

Połączenie WAN lub SSH zostaje przerwane podczas przesyłania

Traktuj odbiór jako nieudany, chyba że zakończył się pomyślnie, a wynikowy podwolumin został prawidłowo zweryfikowany. Udokumentowany interfejs poleceń wysyłania/odbioru Btrfs nie udostępnia opcji wznowienia strumienia. W przypadku zawodnych połączeń na duże odległości rozważ zapisanie strumienia wysyłania do pliku tymczasowego, przesłanie tego pliku za pomocą transportu obsługującego wznawianie, a następnie przekazanie ukończonego, zaufanego pliku do btrfs receive.

Chroń stronę odbiorczą przed niezaufanymi strumieniami

Polecenie odbioru Btrfs stosuje operacje systemu plików z przychodzącego strumienia. Oficjalna dokumentacja odbioru zaleca, aby nie przyjmować strumieni wysyłania z niezaufanych źródeł, oraz zaleca ochronę ścieżki odbioru przed równoczesnymi zapisami podczas stosowania strumienia.

Używaj weryfikacji hosta SSH, uwierzytelniania opartego na kluczach, dedykowanego konta kopii zapasowych oraz możliwie najwęższych uprawnień. Podczas wykonywania kopii zapasowej trzymaj katalog odbiorczy poza zwykłymi ścieżkami zapisu użytkowników.

Używaj tej listy kontrolnej przy każdym przebiegu przyrostowym

• Potwierdź, że oba punkty końcowe używają systemu plików Btrfs.
• Utwórz nową migawkę źródłową za pomocą -r.
• Zachowaj poprzedniego pomyślnie użytego rodzica bez zmian w obu systemach.
• Wysyłaj za pomocą btrfs send -p OLD NEW.
• Odbieraj dane przez uwierzytelnione i szyfrowane połączenie SSH.
• Zweryfikuj pomyślne zakończenie i porównaj identyfikator UUID źródła z identyfikatorem Received UUID odbiorcy.
• Zachowaj odebraną migawkę kopii zapasowej w trybie tylko do odczytu.
• Twórz osobną zapisywalną migawkę, gdy potrzebujesz przywrócić dane lub je przetestować.
• Usuwaj stare migawki dopiero po zweryfikowaniu nowego rodzica.
• Twórz kopie zapasowe zagnieżdżonych podwoluminów w osobnych łańcuchach.

Po ręcznym pomyślnym wykonaniu pełnego zasiewu i jednego przebiegu przyrostowego zautomatyzuj tę samą sekwencję, dodając logowanie i jawne sprawdzanie kodów wyjścia. Najważniejszy nie jest harmonogram, lecz zachowanie niezmienionego, zweryfikowanego migawkowego rodzica po obu stronach każdego kroku przyrostowego.