Woluminy trwałe i snapshoty w Dockup

Woluminy trwałe i snapshoty rozwiązują dwa różne problemy. Wolumin zachowuje pliki podczas wymiany kontenera i wdrażania aplikacji. Snapshot przechwytuje stan woluminu w określonym momencie, dzięki czemu operatorzy mogą później go sprawdzić, zachować lub przywrócić.

System plików kontenera można wymienić. Wszystko, co musi przetrwać wdrożenie — przesłane pliki, wygenerowane multimedia, indeksy, artefakty pakietów lub pliki zarządzane przez aplikację — wymaga jawnie określonej trwałej lokalizacji.

Które dane aplikacji powinny znajdować się na trwałym storage?

Użyj woluminu, gdy aplikacja zarządza plikami, których nie można tanio lub bezpiecznie odtworzyć z innego źródła.

Dane	Wolumin?	Lepsza alternatywa, jeśli jest dostępna
Przesłane pliki użytkowników	Tak	Object storage, jeśli architektura go wykorzystuje
Wygenerowane miniatury	Czasami	Wygenerowanie ponownie na podstawie oryginałów
Indeks wyszukiwania	Czasami	Odbudowanie na podstawie źródłowej bazy danych
Artefakty buildów	Zwykle nie	Odbudowanie podczas wdrażania
Logi aplikacji	Zwykle nie	System logów runtime
Katalog danych PostgreSQL	Nie jako wolumin aplikacji	Zarządzany PostgreSQL
Tymczasowy cache	Nie	Redis lub ephemeral storage
Lokalna produkcyjna baza SQLite	Ryzykowne	Zarządzana baza danych zapewniająca obsługę współbieżności i backupy

Wolumin powinien mieć jednego jasno określonego właściciela i jedną ścieżkę montowania. Dwa niezależne procesy zapisujące do tego samego katalogu utrudniają odzyskiwanie danych i analizę uprawnień.

Przed dodaniem storage oszacuj początkowy rozmiar, tempo wzrostu, wymagania dotyczące retencji oraz cel odtworzeniowy. Zużycie dysku jest rozliczane względem salda planu co minutę, dlatego niewykorzystana pojemność i niekontrolowany przyrost plików mają swój koszt.

Jak utworzyć i sprawdzić wolumin Dockup?

Wyświetl istniejące woluminy dla dokładnie wskazanej usługi:

dockup volume list production/web --json

Dodaj wolumin, podając nazwę, absolutną ścieżkę w kontenerze oraz rozmiar w gigabajtach:

dockup volume add production/web \
  --name uploads \
  --path /app/uploads \
  --size 20 \
  --json

Aplikacja musi zapisywać dane w /app/uploads. Zapis do /uploads lub innego lokalnego katalogu nie przekieruje automatycznie danych do montowania.

Po wdrożeniu sprawdź, czy aplikacja zapisuje dane w zadeklarowanej absolutnej ścieżce montowania, a nie w wymiennym systemie plików kontenera.

Sprawdź rzeczywiste użycie dysku, korzystając ze zwróconego identyfikatora woluminu:

dockup volume usage <volumeId> production/web --json

Porównaj rzeczywiste użycie z przydzielonym rozmiarem i metrykami aplikacji. Ustaw alert zanim system plików się zapełni — pełny wolumin może powodować częściowe zapisy, nieudane przesyłanie plików lub awarie aplikacji.

Zweryfikuj oczekiwania dotyczące właściciela plików. Użytkownik runtime kontenera musi mieć możliwość odczytu i zapisu w ścieżce montowania bez przyznawania szerszych uprawnień, niż jest to konieczne.

Jak snapshoty woluminów chronią dane?

Snapshot tworzony na żądanie przechwytuje zawartość woluminu:

dockup volume snapshot <volumeId> production/web --json

Wyświetl dostępne snapshoty:

dockup volume snapshots <volumeId> production/web --json

Snapshoty odczytują wolumin w trybie tylko do odczytu i nie wymagają, aby aplikacja zapisywała dane w specjalnym katalogu snapshotu. Są przydatne przed ryzykowną migracją plików, masową zmianą multimediów lub zmianą aplikacji przekształcającą zapisane dane.

Snapshot woluminu nie jest automatycznie spójny na poziomie aplikacji. Jeśli aplikacja aktywnie zapisuje kilka powiązanych plików, snapshot może przechwycić je w nieco różnych momentach. W przypadku zarządzanej bazy danych użyj systemu backupów zarządzanej bazy danych zamiast tworzyć snapshot jej surowego katalogu danych.

Określ, kiedy aplikacja powinna zostać wstrzymana. Przed utworzeniem snapshotu o dużej wartości krótka przerwa serwisowa lub wstrzymanie zapisów może być właściwym rozwiązaniem. Zapisz identyfikator snapshotu, powód jego utworzenia oraz oczekiwany punkt odtworzenia.

Jak planować retencję snapshotów?

Wybierz czas tworzenia snapshotów i okres retencji na podstawie wymagań dotyczących odzyskiwania danych, a nie przyzwyczajeń. Utwórz snapshot na żądanie przed każdą ryzykowną migracją plików, operacją czyszczenia lub zmianą formatu i zapisz zwrócony identyfikator snapshotu.

dockup volume snapshot <volumeId> production/web --json
dockup volume snapshots <volumeId> production/web --json

Potrzeba odtworzenia	Praktyka dotycząca snapshotów	Ograniczenie
Cofnięcie migracji plików	Utwórz snapshot bezpośrednio przed zmianą	Nie obejmuje późniejszych zapisów
Zachowanie punktów historycznych	Przechowuj opisane punkty odtworzenia zgodnie z polityką	Retencja wymaga aktywnego przeglądu
Ochrona przed częstymi zapisami	Dodaj backup na poziomie aplikacji odpowiedni dla danych	Snapshot z jednego punktu w czasie nie zapewnia ciągłej ochrony
Archiwum regulacyjne	Użyj dedykowanego workflow archiwizacji	Snapshoty operacyjne mogą nie spełniać wymagań polityki

Sprawdzaj, czy oczekiwane snapshoty rzeczywiście istnieją. Sama spisana polityka retencji nie jest dowodem na utworzenie użytecznego punktu odtworzenia.

Jak bezpiecznie przywrócić snapshot woluminu?

Przywracanie zastępuje bieżącą zawartość woluminu i restartuje kontener:

dockup volume restore \
  <volumeId> \
  <snapshotId> \
  production/web \
  --json

Jest to operacja zakłócająca działanie i zmieniająca stan. Przed przywróceniem:

1. Potwierdź dokładną usługę, identyfikator woluminu oraz identyfikator snapshotu.
2. Wyjaśnij, które bieżące pliki zostaną zastąpione.
3. Jeśli to możliwe, zatrzymaj nowe zapisy lub je ogranicz.
4. Utwórz świeży snapshot bieżącego stanu, jeśli może być potrzebny.
5. Zapisz informacje o zgodności aplikacji i schematu.
6. Uzyskaj jednoznaczną zgodę na operację produkcyjną.
7. Zaplanuj weryfikację po przywróceniu.

Po przywróceniu sprawdź stan kontenera i działanie aplikacji:

dockup status production/web --json
dockup logs production/web --json

Przetestuj reprezentatywne pliki, uprawnienia, indeksy oraz odwołania aplikacji. Pomyślne wykonanie polecenia przywracania dowodzi, że snapshot został zastosowany, ale nie dowodzi, że każdy rekord aplikacji wskazuje prawidłowy plik.

Model guardrails dla agentów AI w środowisku produkcyjnym powinien traktować przywracanie jako operację wymagającą zatwierdzenia, nawet jeśli jest to operacja odzyskiwania danych.

Jak woluminy powinny zachowywać się podczas wdrażania i wycofywania zmian?

Wdrożenie zastępuje kontenery aplikacji, podczas gdy zamontowany wolumin pozostaje bez zmian. Dzięki temu nowy obraz widzi istniejące pliki, ale powstaje obowiązek zachowania zgodności.

Nowa wersja aplikacji nie powinna nieodwracalnie przekształcać zapisanych plików, zanim jej wydanie nie zostanie sprawdzone. Jeśli zmienia formaty plików lub układ katalogów, w miarę możliwości użyj migracji, którą można wznowić i która zachowuje kompatybilność wsteczną.

Wycofanie wdrożenia uruchamia ponownie starsze wdrożenie:

dockup deployments production/web -n 20 --json
dockup rollback <deploymentId> production/web --json

Wolumin nie jest automatycznie wycofywany razem z obrazem. Starsza aplikacja może nie być w stanie odczytać plików przekształconych przez nową wersję. Łącz wycofanie obrazu z przywróceniem snapshotu tylko wtedy, gdy oba działania są wymagane i zatwierdzone.

To rozdzielenie jest istotne:

Działanie odzyskiwania	Zmienia obraz?	Zmienia dane woluminu?
Wdrożenie nowej wersji	Tak	Nie, chyba że aplikacja je migruje
Wycofanie wdrożenia	Tak	Nie
Przywrócenie snapshotu	Nie	Tak
Przywrócenie wraz z wycofaniem wdrożenia	Tak	Tak

Proces wdrażania bez przestojów chroni przełączanie ruchu, a nie zgodność formatów danych.

Czym jest runbook operacyjny dla trwałego storage?

Przypisz właściciela do każdego produkcyjnego woluminu. Runbook powinien zawierać:

• Docelową usługę i identyfikator woluminu.
• Ścieżkę montowania i oczekiwanego użytkownika runtime.
• Przydzielony rozmiar i próg alertu.
• Opis danych oraz możliwość ich odbudowania.
• Harmonogram snapshotów i retencję.
• Ostatni zweryfikowany snapshot.
• Politykę zatwierdzania przywracania.
• Kroki walidacji aplikacji.
• Informacje o zgodności obrazu i danych.
• Politykę wzrostu i usuwania danych.

Regularnie sprawdzaj użycie:

dockup volume usage <volumeId> production/web --json

CPU, RAM i dysk są rozliczane co minutę. Plan Free oferuje początkowy kredyt w wysokości 10 USD, a rekomendowany plan Pro kosztuje 20 USD miesięcznie i obejmuje kredyt na użycie w wysokości 20 USD.

Test przywracania snapshotu

Nie czekaj na incydent, aby odkryć, że nikt nie wie, który snapshot wybrać. Przeprowadź kontrolowany test na usłudze nieprodukcyjnej lub zatwierdzonej kopii:

1. Utwórz rozpoznawalne pliki testowe.
2. Utwórz snapshot.
3. Zmień pliki.
4. Przywróć snapshot.
5. Zweryfikuj zawartość i uprawnienia.
6. Zaobserwuj restart kontenera.
7. Zapisz czas trwania i punkty awarii.

Test przywracania zmienia woluminy trwałe i snapshoty z odhaczanego punktu na sprawdzoną możliwość odzyskiwania danych.

Informacje o początkowym projektowaniu usługi znajdziesz w artykule Od repozytorium Git do produkcji. Szczegóły poleceń znajdziesz w dokumentacji Dockup CLI.

Zdefiniuj cele odzyskiwania danych plikowych

Recovery point objective określa, ile najnowszych danych firma może utracić. Recovery time objective określa, jak długo może trwać przywracanie. Codzienny snapshot z retencją siedmiu kopii może wystarczyć w przypadku wewnętrznego cache multimediów, ale nie w przypadku produktu do przesyłania plików użytkowników, który obiecuje trwałość danych niemal w czasie rzeczywistym.

Udokumentuj obie wartości i zmierz rzeczywisty czas przywracania. Szybkość tworzenia snapshotu, rozmiar danych, restart kontenera, walidacja plików oraz ponowne indeksowanie aplikacji wpływają na czas odzyskiwania.

Kontroluj usuwanie i przyrost plików

Trwały storage może się zapełnić, ponieważ aplikacja nigdy nie usuwa plików tymczasowych lub zastąpionych. Dodaj politykę retencji na poziomie aplikacji i rozróżniaj usuwanie logiczne od natychmiastowego usuwania fizycznego. Krótkie okno odzyskiwania może uzasadniać opóźnienie trwałego usunięcia.

Przed uruchomieniem masowego czyszczenia:

1. Zmierz bieżące użycie woluminu.
2. Przygotuj listę plików przeznaczonych do usunięcia.
3. Utwórz snapshot.
4. Uruchom czyszczenie w ograniczonych partiach.
5. Zweryfikuj odwołania aplikacji.
6. Potwierdź oczekiwane odzyskanie miejsca.

Dzięki temu woluminy trwałe i snapshoty pełnią funkcję prewencyjną, a nie tylko reagują na incydenty.

Weryfikuj zasób snapshotów

Regularnie sprawdzaj identyfikatory snapshotów, czasy utworzenia, retencję oraz datę ostatniego pomyślnego testu przywracania. Skonfigurowane zadanie bez niedawnego, użytecznego snapshotu nie jest systemem odzyskiwania danych.

Przypisz uprawnienia do przywracania

Określ, kto może zatwierdzić przywracanie na produkcji i kto przeprowadza walidację po przywróceniu. Rozdzielenie zatwierdzania od wykonania zmniejsza ryzyko, że presja czasu ominie weryfikację usługi docelowej i snapshotu.

Zacznij od wdrożenia, które można zweryfikować

Utwórz jeden wolumin nieprodukcyjny, zrób snapshot, zmień plik testowy i przeprowadź test przywracania, zanim zapiszesz nieodwracalne dane produkcyjne.

Zacznij za darmo na app.dockup.ai. Plan Free kosztuje 0 USD miesięcznie, obejmuje początkowy kredyt w wysokości 10 USD oraz obsługuje jeden workspace, trzy bazy danych i trzy wdrożenia.

FAQ

Czy wolumin Dockup przetrwa wdrożenie?

Tak. Wolumin pozostaje trwały, gdy kontenery usługi są wymieniane, pod warunkiem że aplikacja nadal korzysta ze skonfigurowanej ścieżki montowania.

Czy snapshot woluminu jest właściwym backupem dla PostgreSQL?

Nie. Snapshot wykonywany podczas działania bazy danych może nie być spójny transakcyjnie. W przypadku zarządzanych baz danych preferuj system backupów zarządzanej bazy danych.

Co dzieje się po przywróceniu snapshotu woluminu?

Bieżąca zawartość woluminu zostaje zastąpiona wybranym snapshotem, a kontener jest restartowany, dlatego operacja powinna zostać zatwierdzona i zweryfikowana.

Czy Dockup może planować snapshoty woluminów?

Tak. Polecenie harmonogramu woluminu obsługuje codzienne snapshoty z określoną liczbą przechowywanych kopii, a harmonogram można jawnie wyłączyć.

Czy wycofanie aplikacji przywraca również jej wolumin?

Nie. Historia wdrożeń aplikacji i historia snapshotów woluminu są od siebie niezależne. Koordynuj oba działania tylko wtedy, gdy wymaga tego plan odzyskiwania.