Harmonogram potrzebny do życia w stanie trwałym Dockera
Autor chciał co tydzień tworzyć kopie AppData w puli RAID 1, a następnie drugą kopię z tej puli na stale podłączony dysk USB. Systemowy crontab i społecznościowa aplikacja do harmonogramów nie zachowywały zadań niezawodnie po ponownym uruchomieniu, więc autor przeniósł harmonogram do zarządzanego przez Portainera stosu Ofelia przechowywanego w trwałych danych ZimaOS.
Powstała konfiguracja rozdzielała trzy warstwy: skrypty powłoki na magazynie RAID, kontener Ofelia zapewniający harmonogram oraz krótkotrwałe kontenery rsync wykonujące poszczególne kopie.
Przechowuj skrypty i dzienniki na trwałym magazynie
W przykładzie skrypty znajdowały się w ścieżce takiej jak /media/RAID1/scripts. Ten katalog był montowany z prawem zapisu i odczytu w harmonogramie jako /scripts. Dzienniki zapisywano obok skryptów, aby po zakończeniu zadania można było je sprawdzić za pomocą aplikacji Pliki lub udziału sieciowego.
Każda ścieżka w przykładzie zależy od konkretnej instalacji. Skopiowanie nazwy macierzy RAID autora bez sprawdzenia rzeczywistej ścieżki montowania może spowodować wysłanie kopii zapasowej w niewłaściwe miejsce albo ciche niepowodzenie zadania.
Ofelia zapewniała harmonogram odporny na ponowne uruchomienie
Stos Portainera korzystał z obrazu Ofelia, miał ustawienie restart: always, montował katalog ze skryptami i przechowywał etykiety harmonogramu wraz z kontenerem. W przykładzie AppData było planowane na 23:30 w każdą niedzielę, a ogólne dane NAS na 23:45.
ofelia.job-local.appdata.schedule: "0 30 23 * * 0"
ofelia.job-local.appdata.command: "/bin/sh /scripts/backup_appdata.sh"
ofelia.job-local.nas_home.schedule: "0 45 23 * * 0"
ofelia.job-local.nas_home.command: "/bin/sh /scripts/backup_nas_home.sh"Autor poinformował, że harmonogram i jego zadania wracały w ciągu mniej więcej minuty od ponownego uruchomienia, bez konieczności nawiązywania kolejnej sesji SSH.
Skrypt AppData zatrzymywał Plex przed kopiowaniem
Aby zmniejszyć ryzyko kopiowania aktywnie zmieniającej się bazy danych Plex, skrypt zatrzymywał Plex, uruchamiał rsync ze źródłowego montowania AppData tylko do odczytu, a następnie ponownie uruchamiał Plex. Kontener harmonogramu instalował interfejs Docker CLI w razie potrzeby i sterował kontenerami sąsiednimi za pośrednictwem gniazda Dockera.
Montowanie /var/run/docker.sock daje harmonogramowi szeroką kontrolę nad hostem Dockera. Uruchamianie go jako root i z uprawnieniami uprzywilejowanymi dodatkowo zwiększa ten zakres uprawnień. Wątek przedstawia to jako działającą konfigurację autora, a nie model zabezpieczeń oparty na zasadzie najmniejszych uprawnień.
rsync --delete tworzy dokładną kopię lustrzaną, a nie historię wersji
W przykładzie użyto rsync -avH --delete. Opcja --delete usuwa z miejsca docelowego pliki, które nie istnieją już w źródle. Tworzy to dokładną kopię lustrzaną, ale może również powielać przypadkowe usunięcie lub uszkodzenie danych.
Najpierw przetestuj działanie bez usuwania, potwierdź montowania źródła i miejsca docelowego oraz sprawdź dziennik przed włączeniem harmonogramu działającego bez nadzoru. Kopia lustrzana na stale podłączonym dysku USB nie jest również równoważna kopii offline ani niezmiennej kopii zapasowej.
Trwałość po ponownym uruchomieniu nie rozwiązała problemu ponownego podłączania USB
Autor osobno poprosił o to, aby podłączony dysk USB po ponownym uruchomieniu nie pojawiał się jako nowy dysk. Ofelia zachowuje konfigurację zadania, ale zmieniona lub niedostępna ścieżka montowania nadal może uniemożliwić wykonanie kopii zapasowej do miejsca docelowego. Stabilna identyfikacja magazynu i sprawdzanie montowań przed uruchomieniem rsync pozostają odrębnymi wymaganiami.
FAQ
Dlaczego ten harmonogram przetrwał ponowne uruchomienie?
Definicje zadań znajdowały się w stosie Portainera skonfigurowanym do automatycznego ponownego uruchamiania, a skrypty były przechowywane na trwałym magazynie, a nie w efemerycznym systemowym crontabie.
Czy tworzy to historyczne wersje kopii zapasowych?
Nie. Udokumentowane polecenie rsync tworzy kopię lustrzaną i używa --delete. Zachowywanie wersji wymaga innej konfiguracji.
Dlaczego należy zatrzymać Plex przed kopiowaniem AppData?
Autor robił to, aby zmniejszyć ryzyko skopiowania bazy danych w trakcie jej modyfikowania.
