Volume persistente și snapshot-uri pe Dockup

Volumele persistente și snapshot-urile rezolvă două probleme diferite. Un volum păstrează fișierele atunci când containerul este înlocuit sau are loc un deployment. Un snapshot capturează volumul la un anumit moment, astfel încât operatorii să poată inspecta, păstra sau restaura ulterior starea respectivă.

Filesystem-ul containerului poate fi înlocuit. Tot ce trebuie să supraviețuiască unui deployment — uploaduri, materiale media generate, indexuri, artefacte de pachete sau fișiere gestionate de aplicație — are nevoie de o locație persistentă configurată explicit.

Ce date ale aplicației ar trebui stocate persistent?

Folosește un volum atunci când aplicația deține fișiere care nu pot fi recreate ușor sau în siguranță dintr-o altă sursă.

Date	Volum?	Alternativă mai bună, dacă este disponibilă
Uploaduri ale utilizatorilor	Da	Object storage, dacă arhitectura îl folosește
Thumbnail-uri generate	Poate	Regenerează-le din fișierele originale
Index de căutare	Poate	Rebuild din baza de date sursă
Artefacte de build	De obicei nu	Rebuild în timpul deploymentului
Loguri ale aplicației	De obicei nu	Sistem de loguri al runtime-ului
Directorul de date PostgreSQL	Nu ca volum al aplicației	PostgreSQL administrat
Cache temporar	Nu	Redis sau stocare efemeră
Bază de date SQLite locală în producție	Riscant	Bază de date administrată pentru concurență și backupuri

Un volum ar trebui să aibă un singur owner clar și o singură cale de montare. Două procese fără legătură care scriu în același director complică recuperarea și analiza permisiunilor.

Înainte să adaugi stocare, estimează dimensiunea inițială, rata de creștere, cerințele de retenție și obiectivul de recuperare. Spațiul pe disc este măsurat în raport cu soldul planului, minut cu minut, astfel că atât capacitatea neutilizată, cât și creșterea necontrolată a fișierelor au un cost.

Cum creezi și inspectezi un volum Dockup?

Listează volumele existente pentru serviciul exact:

dockup volume list production/web --json

Adaugă un volum cu un nume, o cale absolută în container și o dimensiune în gigabytes:

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

Aplicația trebuie să scrie în /app/uploads. Scrierea în /uploads sau într-un alt director local nu redirecționează automat datele către montare.

După deployment, verifică dacă aplicația scrie în calea absolută de montare declarată, nu în filesystem-ul înlocuibil al containerului.

Inspectează utilizarea reală a discului folosind ID-ul de volum returnat:

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

Compară utilizarea reală cu dimensiunea alocată și cu metricile aplicației. Configurează alerte înainte ca filesystem-ul să se umple; un volum plin poate provoca scrieri parțiale, uploaduri eșuate sau crash-uri ale aplicației.

Verifică așteptările privind owner-ul fișierelor. Utilizatorul de runtime al containerului trebuie să poată citi și scrie în calea de montare fără să primească permisiuni mai largi decât este necesar.

Cum protejează datele snapshot-urile de volum?

Un snapshot creat la cerere capturează conținutul volumului:

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

Listează snapshot-urile disponibile:

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

Snapshot-urile citesc volumul în mod read-only și nu necesită ca aplicația să scrie într-un director special pentru snapshot-uri. Sunt utile înaintea unei migrări riscante de fișiere, a unei rescrieri în masă a materialelor media sau a unei modificări a aplicației care transformă datele stocate.

Un snapshot de volum nu este automat consistent la nivelul aplicației. Dacă aplicația scrie activ mai multe fișiere corelate, snapshot-ul le poate captura în momente ușor diferite. Pentru o bază de date administrată, folosește sistemul de backup al bazei de date, nu crea snapshot-uri ale directorului său brut de date.

Definește momentul în care aplicația ar trebui adusă într-o stare quiescentă. O scurtă perioadă de mentenanță sau de suspendare a scrierilor poate fi potrivită înaintea unui snapshot important. Notează ID-ul snapshot-ului, motivul și punctul de restaurare așteptat.

Cum ar trebui planificată retenția snapshot-urilor?

Alege momentul creării și retenția snapshot-urilor pornind de la cerințele de recuperare, nu din obișnuință. Creează un snapshot la cerere înaintea fiecărei migrări riscante de fișiere, operațiuni de curățare sau modificări de format și notează ID-ul snapshot-ului returnat.

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

Cerință de recuperare	Practica pentru snapshot-uri	Limitare
Anularea unei migrări de fișiere	Creează snapshot-ul imediat înaintea modificării	Nu include scrierile ulterioare
Păstrarea unor puncte istorice	Păstrează puncte de recuperare etichetate conform politicii	Retenția trebuie revizuită activ
Protejarea scrierilor frecvente	Adaugă un backup la nivelul aplicației, potrivit pentru date	Un snapshot punctual nu oferă protecție continuă
Arhivă pentru cerințe de reglementare	Folosește un workflow dedicat de arhivare	Snapshot-urile operaționale pot să nu respecte politica

Verifică dacă snapshot-urile așteptate există efectiv. O politică de retenție documentată nu dovedește că a fost creat un punct de restaurare utilizabil.

Cum restaurezi în siguranță un snapshot de volum?

Restaurarea înlocuiește conținutul actual al volumului și repornește containerul:

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

Aceasta este o operațiune disruptivă, care modifică starea sistemului. Înainte de restaurare:

1. Confirmă serviciul exact, ID-ul volumului și ID-ul snapshot-ului.
2. Explică ce fișiere curente vor fi înlocuite.
3. Oprește sau limitează scrierile noi, acolo unde este posibil.
4. Creează un snapshot nou al stării curente, dacă aceasta ar putea fi necesară ulterior.
5. Notează compatibilitatea aplicației și a schemei.
6. Obține aprobarea explicită pentru producție.
7. Planifică verificările de după restaurare.

După restaurare, verifică starea containerului și comportamentul aplicației:

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

Testează fișiere reprezentative, permisiunile, indexurile și referințele aplicației. O comandă de restaurare finalizată cu succes dovedește că snapshot-ul a fost aplicat; nu dovedește că fiecare înregistrare a aplicației indică un fișier valid.

Modelul de guardrails pentru agenții AI în producție ar trebui să trateze restaurarea ca pe o operațiune care necesită aprobare, chiar dacă este o operațiune de recuperare.

Cum ar trebui să se comporte volumele în timpul deploymentului și rollbackului?

Un deployment înlocuiește containerele aplicației, în timp ce volumul montat rămâne disponibil. Astfel, o imagine nouă poate vedea fișierele existente, dar apare o obligație de compatibilitate.

O versiune nouă a aplicației nu ar trebui să transforme ireversibil fișierele stocate înainte ca release-ul să fie validat. Dacă modifică formatele fișierelor sau structura directoarelor, folosește, pe cât posibil, o migrare reluabilă și compatibilă cu versiunile anterioare.

Rollbackul aplicației relansează un deployment mai vechi:

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

Volumul nu revine automat la starea anterioară odată cu imaginea. Este posibil ca o aplicație veche să nu poată citi fișiere transformate de versiunea nouă. Coordonează rollbackul imaginii cu restaurarea snapshot-ului numai atunci când ambele sunt necesare și aprobate.

Această separare este importantă:

Acțiune de recuperare	Modifică imaginea?	Modifică datele volumului?
Deployment al unei versiuni noi	Da	Nu, cu excepția cazului în care aplicația le migrează
Rollbackul deploymentului	Da	Nu
Restaurarea unui snapshot	Nu	Da
Restaurare plus rollback	Da	Da

Procesul de deployment fără downtime protejează comutarea traficului, nu compatibilitatea formatului datelor.

Ce este un runbook operațional pentru stocare persistentă?

Desemnează un owner pentru fiecare volum de producție. Runbook-ul ar trebui să conțină:

• Ținta serviciului și ID-ul volumului.
• Calea de montare și utilizatorul de runtime așteptat.
• Dimensiunea alocată și pragul de alertare.
• Descrierea datelor și posibilitatea de rebuild.
• Programul snapshot-urilor și retenția.
• Ultimul snapshot verificat.
• Politica de aprobare a restaurării.
• Pașii de validare a aplicației.
• Note despre compatibilitatea imaginii și a datelor.
• Politica privind creșterea și ștergerea datelor.

Inspectează periodic utilizarea:

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

CPU-ul, memoria RAM și spațiul pe disc sunt măsurate minut cu minut. Planul Free oferă un credit inițial de $10, iar planul Pro recomandat costă $20 pe lună și include un credit de utilizare de $20.

Exercițiu de restaurare a unui snapshot

Nu aștepta apariția unui incident pentru a descoperi că nimeni nu știe ce snapshot să aleagă. Desfășoară un exercițiu controlat pe un serviciu non-production sau pe o copie aprobată:

1. Creează fișiere de test ușor de recunoscut.
2. Creează un snapshot.
3. Modifică fișierele.
4. Restaurează snapshot-ul.
5. Verifică conținutul și permisiunile.
6. Observă repornirea containerului.
7. Notează durata și punctele de eșec.

Un exercițiu de restaurare transformă volumele persistente și snapshot-urile dintr-o bifă într-o capacitate de recuperare testată.

Pentru proiectarea inițială a serviciului, consultă De la repository Git la producție. Pentru detalii despre comenzi, folosește referința Dockup CLI.

Definește obiectivele de recuperare pentru datele din fișiere

Recovery point objective indică ce cantitate de date recente își poate permite compania să piardă. Recovery time objective indică durata maximă acceptabilă pentru restaurare. Un snapshot zilnic cu retenția a șapte copii poate fi suficient pentru un cache intern de materiale media, dar nu și pentru un produs cu uploaduri ale utilizatorilor care promite durabilitate aproape în timp real.

Documentează ambele valori și testează durata reală a restaurării. Viteza de creare a snapshot-ului, dimensiunea datelor, repornirea containerului, validarea fișierelor și reindexarea aplicației contribuie toate la timpul de recuperare.

Controlează ștergerea și creșterea numărului de fișiere

Stocarea persistentă se poate umple deoarece aplicația nu șterge niciodată fișierele temporare sau înlocuite. Adaugă o politică de retenție la nivelul aplicației și diferențiază ștergerea logică de ștergerea fizică imediată. O fereastră scurtă de recuperare poate justifica amânarea eliminării permanente.

Înainte de a rula o operațiune de curățare în masă:

1. Măsoară utilizarea curentă a volumului.
2. Generează o listă cu fișierele candidate pentru ștergere.
3. Creează un snapshot.
4. Rulează operațiunea de curățare în batch-uri limitate.
5. Verifică referințele aplicației.
6. Confirmă recuperarea estimată a spațiului.

Astfel, volumele persistente și snapshot-urile au un rol preventiv, nu doar unul legat de incidente.

Verifică inventarul de snapshot-uri

Revizuiește periodic ID-urile snapshot-urilor, momentele creării, retenția și ultimul test de restaurare finalizat cu succes. Un job configurat fără niciun snapshot recent și utilizabil nu este un sistem de recuperare.

Stabilește autoritatea pentru restaurare

Desemnează persoana care poate aproba o restaurare în producție și persoana care efectuează validarea după restaurare. Separarea aprobării de execuție reduce riscul ca urgența să ocolească verificarea țintei și a snapshot-ului.

Începe cu un deployment verificabil

Creează un volum non-production, creează un snapshot, modifică un fișier de test și finalizează un exercițiu de restaurare înainte de a stoca date de producție care nu pot fi înlocuite.

Începe gratuit pe app.dockup.ai. Planul Free costă $0 pe lună, include un credit inițial de $10 și oferă suport pentru un workspace, trei baze de date și trei deploymenturi.

Întrebări frecvente

Supraviețuiește un volum Dockup unui deployment?

Da. Volumul rămâne persistent atunci când containerele serviciului sunt înlocuite, cu condiția ca aplicația să continue să folosească calea de montare configurată.

Este un snapshot de volum backupul potrivit pentru PostgreSQL?

Nu. Un snapshot realizat în timp ce baza de date este activă poate să nu fie consistent la nivel de tranzacție. Pentru bazele de date administrate, preferă sistemul de backup al bazei de date administrate.

Ce se întâmplă când este restaurat un snapshot de volum?

Conținutul curent al volumului este înlocuit cu snapshot-ul selectat, iar containerul este repornit; prin urmare, operațiunea ar trebui aprobată și verificată.

Poate Dockup să programeze snapshot-uri de volum?

Da. Comanda pentru programarea volumului acceptă snapshot-uri zilnice cu un număr de copii păstrate, iar programarea poate fi dezactivată explicit.

Rollbackul unei aplicații readuce și volumul la starea anterioară?

Nu. Istoricul deploymenturilor aplicației și istoricul snapshot-urilor volumului sunt separate. Coordonează-le numai atunci când planul de recuperare o impune.