Tak.
Może takie głupie pytanie zadam ale czemu jak patrzę na poradniki jak robić backup volume to wszędzie jest to robione przez montowanie wolumenu a nie po prostu backup /var/lib/docker/volume/ ??
Jeśli dobrze rozumiem to co opisujesz, to po zamontowaniu masz dostęp do plików i możesz przyrostowo zbackupować tylko te pliki, które się zmieniły od czasu ostatniego backupu. Jeśli widzisz cały wolumen jako jeden plik, to za każdym razem musisz wysyłać całość.
Oszczędność transferu oraz miejsca (jeśli chcesz trzymać więcej historii niż ostatni snapshot tylko). Do tego w niektórych systemach możliwość wyciągnięcia starszej wersji pojedynczego pliku
To nie do końca to, na volumenie są dane te same ale nazewnictwo może być różne volumenów, czasem ciężko namierzyć co to konkretnie potrzebujemy (zarówno backup jak i jego odtworzenie) jak volumen ma przykładową nazwę postaci hasha (nie interesuje jak chcesz backupowac całość a nie wybiórczo,), dobrą praktyką jest wykonywanie backupów tak jak widzi to kontener aplikacyjny z zamontowanym volumenem bez naleciałości warstwy abstrakcji konteneryzacji (celowo nie użyłem słowo docker bo nie jest to jedyna opcja)
Pierwsze lepsze zagrożenia jakie mogą się pojawić przy chamskim kopiowaniu /var/lib/docker/volumes/
-
Kopiowanie danych podczas gdy aplikacja je modyfikuje może prowadzić do niekompletnego lub uszkodzonego backupu.
Dedykowane narzędzia backupowe mogą zatrzymywać aplikację i wstrzymywać operacje we/wy na czas backupu, zapewniając spójność danych, przy bazach danych w kontenerze mogą się pojawić jaja z integralnością danych. -
Docker itp. przechowują metadane wolumenów wewnętrznie. Ręczne kopiowanie może spowodować utratę tych metadanych, utrudniając zarządzanie i przywracanie.
-
Wolumeny mają specyficzne uprawnienia dostępu. Ręczne kopiowanie może je naruszyć, powodując problemy z uruchamianiem aplikacji po przywróceniu.
To tak z grubsza i wcale nie muszą te bolączki wystąpić, z tyłu głowy trzeba to mieć. Jak się nie boisz może użyć właśnie jakiegoś restic + prosty skrypt.
IMO to nie powinno byc problemu - zatrzymac aplikacje na czas kopiowania moge i za pomoca skryptu.
Wszystko u mnie aktualnie leci jako rsync /var/lib/docker/volumes/ do katalogu tymczasowego (bo rsync pozwala na rekurencyjne kopiowanie plików i zachowuje dowiązania symboliczne, uprawnienia do plików, własność użytkowników i grup oraz znaczniki czasu), potem to wszystko jest ladnie pakowane do tar.gz, nastepnie szyfrowane przez gnupg i wysylane do punktu docelowego poza maszyna na ktorej backup jest robiony.
Ok, jako backup i jego wykonanie jest to ok, siermiężne ale ok. Ja od backupów wymagam czegoś więcej. Bo to fajne rozwiązanie jak coś padnie i przywracasz wszystko. Dla mnie backup ma również wykonywać snapshot volumenow by w razie jakiegoś fackupu móc się cofnąć do konkretnego dnia dla danej aplikacji. Mnie już rozpieścił longhorn w k8s.
Snapshoty XD
Panie, ja tego używam. Backup jest raz na tydzień robiony tylko dlatego, że głupio mi robić go rzadziej.
Ale bywa tak, że zmian tam nie ma przez tygodnie XD
Jak potrzebuje eksperymentować to git wchodzi do akcji po prostu - wtedy osobne gałęzie, commit przy każdej zmianie itp.
Ah, jeśli masz to rozwiązane na jakiejś warstwie już w postaci snapshotów to nie było tematu + chcesz mieć dodatkowo backup całości to już faktycznie uprość sprawę jak tylko możesz 
żeby yunohost miał sens to wymagane jest publiczne IP? Czy jeśli ustawiam sobie to dla swojej domeny to nie ma takiego wymogu?
Postawiłem sobie to testowo ale mam problem z forwardem portów (pomimo ustawień na routerze) stąd moje pytanie.
Najlepiej to działa jak ma się przypisany adres publiczny (nawet dynamiczny) i otwarte porty 80 i 443. Da się jednak to pożenić z Cloudflare tunnels, mój kolega tak zrobił.
1 polubienie
O, a powiedz więcej? Na wewnętrznej sieci miałem zawsze problemy i wolałem używać dietpi, ale jestem zainteresowany.
No właśnie ja mam otwarte porty ale nie da się na świat bo nie mam indywidualnego IP. Sprawdzę te tunele wieczorem czy to się sprawdzi w moim przypadku. Dziękuję za wskazanie drogi 
1 polubienie
Pytasz o Cloudflare Tunnel? W skrócie jest to usługa, która “wyciąga” reverse proxy do Cloudflare i pozwala Ci definiować domeny/subdomeny pod wybrane porty na hoście, na którym zainstalowane masz Cloudflared. Działa to bez otwierania portów. Np masz Home Assistant na adresie 192.168.1.10:8123 i domenę test.pl, to w Cloudflare możesz sobie zdefiniować, że np. home.test.pl ma wskazywać na 192.168.1.10:8123
Ja używam tuneli do wystawienia do internetu usług, które mam na Mikrusie, bo tam nie ma jako takiej adresacji IPv4.
Poniższy poradnik nie jest już 100% aktualny i tłumaczy bardzo niewiele, ale w sumie pokazuje główny cel:
1 polubienie
na tej dokładnie zasadzie mam wystawione HA to świata. Myślałem, że nie będzie potrzebne ale jednak się przydaje jak mnie nie ma w domy a żonie coś nie pasuje ze smarthome i mogę to ogarnąć zdalnie (a przynajmniej spróbować).
Zamiast cf tunel polecam tailscale. Szczególnie jak się ma kilka lokalizacji.
1 polubienie
Działa podobnie, ale nie jest tym samym. Tunnele wystawiają coś pod domeną dla każdego - Tailscale to w zasadzie VPN i usługa tworzenia własnej sieci wirtualnej.
owszem, pytanie czy chcesz wystawiac cos w swiat dla kazdego
CF Tunnel jest super.
Lokalnie ogarnąłem sobie pihole → bind9 → traefik
dzięki temu lokalnie ogarniam domeny, np. homeassistant.xxxx.xx leci mi bezpośrednio na maszynke gdzie mam HA
A gdy jestem poza siecią lokalną to ten sam adres idzie przez CF Tunnel do tej samej maszynki z HA
Tak jak napisałem, chcę:
Ja używam tuneli do wystawienia do internetu usług, które mam na Mikrusie,