Persistent Volumes και Snapshots στο Dockup

Τα persistent volumes και τα snapshots λύνουν δύο διαφορετικά προβλήματα. Ένα volume διατηρεί τα αρχεία κατά την αντικατάσταση container και το deployment. Ένα snapshot καταγράφει το volume σε μια συγκεκριμένη χρονική στιγμή, ώστε οι operators να μπορούν να επιθεωρήσουν, να διατηρήσουν ή να επαναφέρουν αυτή την κατάσταση αργότερα.

Το filesystem του container μπορεί να αντικατασταθεί. Οτιδήποτε πρέπει να επιβιώσει από ένα deploy—uploads, παραγόμενο media, indexes, package artifacts ή αρχεία που διαχειρίζεται η εφαρμογή—χρειάζεται μια ρητά ορισμένη persistent τοποθεσία.

Ποια δεδομένα της εφαρμογής ανήκουν σε persistent storage;

Χρησιμοποιήστε volume όταν η εφαρμογή διαχειρίζεται αρχεία που δεν μπορούν να αναδημιουργηθούν εύκολα ή με ασφάλεια από άλλη πηγή.

Δεδομένα	Volume;	Καλύτερη εναλλακτική, όταν είναι διαθέσιμη
User uploads	Ναι	Object storage, αν χρησιμοποιείται από την αρχιτεκτονική
Generated thumbnails	Ίσως	Αναδημιουργία από τα originals
Search index	Ίσως	Rebuild από τη source database
Build artifacts	Συνήθως όχι	Rebuild κατά το deployment
Application logs	Συνήθως όχι	Runtime log system
PostgreSQL data directory	Όχι ως app volume	Managed PostgreSQL
Temporary cache	Όχι	Redis ή ephemeral storage
Local SQLite production DB	Επικίνδυνο	Managed database για concurrency και backups

Ένα volume πρέπει να έχει έναν σαφή owner και ένα mount path. Η εγγραφή από δύο άσχετες διεργασίες στον ίδιο κατάλογο δυσκολεύει το recovery και την ανάλυση permissions.

Πριν προσθέσετε storage, υπολογίστε το αρχικό μέγεθος, τον ρυθμό αύξησης, τις απαιτήσεις retention και το recovery objective. Ο χώρος στον δίσκο υπολογίζεται κάθε λεπτό σε σχέση με το υπόλοιπο του plan, επομένως η αχρησιμοποίητη χωρητικότητα και η ανεξέλεγκτη αύξηση αρχείων έχουν κόστος.

Πώς δημιουργείτε και ελέγχετε ένα Dockup volume;

Εμφανίστε τα υπάρχοντα volumes για το ακριβές service:

dockup volume list production/web --json

Προσθέστε ένα volume με όνομα, απόλυτο path στο container και μέγεθος σε gigabytes:

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

Η εφαρμογή πρέπει να γράφει στο /app/uploads. Η εγγραφή στο /uploads ή σε έναν άλλο τοπικό κατάλογο δεν ανακατευθύνει αυτόματα τα δεδομένα στο mount.

Μετά το deployment, επιβεβαιώστε ότι η εφαρμογή γράφει στο δηλωμένο απόλυτο mount path και όχι στο filesystem του container, το οποίο μπορεί να αντικατασταθεί.

Ελέγξτε την πραγματική χρήση του δίσκου με το volume ID που επιστράφηκε:

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

Συγκρίνετε την πραγματική χρήση με το allocated size και τα metrics της εφαρμογής. Ρυθμίστε alerts πριν γεμίσει το filesystem· ένα γεμάτο volume μπορεί να προκαλέσει partial writes, αποτυχημένα uploads ή crashes της εφαρμογής.

Ελέγξτε τις απαιτήσεις ownership των αρχείων. Ο runtime user του container πρέπει να μπορεί να διαβάζει και να γράφει στο mount path, χωρίς να του παραχωρούνται περισσότερα permissions από όσα χρειάζεται.

Πώς προστατεύουν τα volume snapshots τα δεδομένα;

Ένα on-demand snapshot καταγράφει τα περιεχόμενα του volume:

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

Εμφανίστε τα διαθέσιμα snapshots:

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

Τα snapshots διαβάζουν το volume με read-only τρόπο και δεν απαιτούν από την εφαρμογή να γράφει σε ειδικό snapshot directory. Είναι χρήσιμα πριν από ένα risky file migration, ένα bulk media rewrite ή μια αλλαγή στην εφαρμογή που μετασχηματίζει αποθηκευμένα δεδομένα.

Ένα volume snapshot δεν είναι αυτόματα application-consistent. Αν η εφαρμογή γράφει ενεργά αρκετά σχετικά αρχεία, το snapshot μπορεί να τα καταγράψει σε ελαφρώς διαφορετικές χρονικές στιγμές. Για μια managed database, χρησιμοποιήστε το managed database backup system αντί να δημιουργήσετε snapshot του raw data directory.

Καθορίστε πότε πρέπει να μπαίνει η εφαρμογή σε quiesced κατάσταση. Ένα σύντομο maintenance ή write pause μπορεί να είναι κατάλληλο πριν από ένα snapshot υψηλής αξίας. Καταγράψτε το snapshot ID, την αιτία και το αναμενόμενο restore point.

Πώς πρέπει να σχεδιαστεί το snapshot retention;

Επιλέξτε τον χρόνο δημιουργίας και το retention των snapshots με βάση την απαίτηση recovery και όχι τη συνήθεια. Δημιουργήστε ένα on-demand snapshot πριν από κάθε risky file migration, cleanup ή αλλαγή format και καταγράψτε το snapshot ID που επιστράφηκε.

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

Ανάγκη recovery	Πρακτική snapshots	Περιορισμός
Αναίρεση file migration	Snapshot αμέσως πριν από την αλλαγή	Δεν περιλαμβάνει μεταγενέστερα writes
Διατήρηση ιστορικών σημείων	Διατηρήστε labeled recovery points σύμφωνα με την policy	Το retention χρειάζεται ενεργή επανεξέταση
Προστασία συχνών writes	Προσθέστε application-level backup κατάλληλο για τα δεδομένα	Ένα point-in-time snapshot δεν είναι continuous protection
Regulatory archive	Χρησιμοποιήστε dedicated archive workflow	Τα operational snapshots μπορεί να μην καλύπτουν την policy

Ελέγχετε αν τα αναμενόμενα snapshots υπάρχουν πράγματι. Μια γραπτή retention policy δεν αποτελεί απόδειξη ότι δημιουργήθηκε usable restore point.

Πώς κάνετε με ασφάλεια restore ενός volume snapshot;

Το restore αντικαθιστά τα τρέχοντα περιεχόμενα του volume και κάνει restart το container:

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

Πρόκειται για disruptive operation που αλλάζει την κατάσταση. Πριν από το restore:

1. Επιβεβαιώστε το ακριβές service, το volume ID και το snapshot ID.
2. Εξηγήστε ποια τρέχοντα αρχεία θα αντικατασταθούν.
3. Σταματήστε ή περιορίστε τα νέα writes, όπου είναι δυνατό.
4. Δημιουργήστε ένα fresh snapshot της τρέχουσας κατάστασης, αν μπορεί να χρειαστεί.
5. Καταγράψτε τη συμβατότητα της εφαρμογής και του schema.
6. Λάβετε explicit production approval.
7. Σχεδιάστε το post-restore verification.

Μετά το restore, ελέγξτε την κατάσταση του container και τη συμπεριφορά της εφαρμογής:

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

Ελέγξτε αντιπροσωπευτικά αρχεία, permissions, indexes και application references. Μια επιτυχής εντολή restore αποδεικνύει ότι εφαρμόστηκε το snapshot· δεν αποδεικνύει ότι κάθε application record δείχνει σε έγκυρο αρχείο.

Το μοντέλο AI agent production guardrails πρέπει να αντιμετωπίζει το restore ως operation που απαιτεί approval, παρότι πρόκειται για διαδικασία recovery.

Πώς πρέπει να συμπεριφέρονται τα volumes κατά το deployment και το rollback;

Ένα deployment αντικαθιστά τα application containers, ενώ το mounted volume παραμένει. Αυτό επιτρέπει σε ένα νέο image να βλέπει τα υπάρχοντα αρχεία, δημιουργεί όμως υποχρέωση συμβατότητας.

Μια νέα έκδοση της εφαρμογής δεν πρέπει να μετασχηματίζει μη αναστρέψιμα τα αποθηκευμένα αρχεία πριν επιβεβαιωθεί η ορθότητα του release. Αν αλλάζει τα file formats ή τη διάταξη καταλόγων, χρησιμοποιήστε migration που μπορεί να συνεχιστεί μετά από διακοπή και είναι backward compatible, όπου είναι δυνατό.

Το application rollback εκτελεί ξανά ένα παλαιότερο deployment:

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

Το volume δεν κάνει αυτόματα rollback μαζί με το image. Μια παλαιότερη εφαρμογή μπορεί να μην μπορεί να διαβάσει αρχεία που μετασχηματίστηκαν από τη νέα έκδοση. Συντονίστε το image rollback με snapshot restore μόνο όταν απαιτούνται και τα δύο και έχουν εγκριθεί.

Αυτός ο διαχωρισμός είναι σημαντικός:

Ενέργεια recovery	Αλλάζει το image;	Αλλάζει τα δεδομένα του volume;
Deploy νέας έκδοσης	Ναι	Όχι, εκτός αν η εφαρμογή κάνει migration
Roll back deployment	Ναι	Όχι
Restore snapshot	Όχι	Ναι
Restore και rollback	Ναι	Ναι

Η διαδικασία zero-downtime deployment προστατεύει το traffic cutover, όχι τη συμβατότητα των data formats.

Τι είναι ένα durable storage operating runbook;

Αναθέστε έναν owner σε κάθε production volume. Το runbook πρέπει να περιλαμβάνει:

• Service target και volume ID.
• Mount path και αναμενόμενο runtime user.
• Allocated size και alert threshold.
• Περιγραφή δεδομένων και δυνατότητα rebuild.
• Πρόγραμμα snapshots και retention.
• Τελευταίο verified snapshot.
• Πολιτική approval για restore.
• Βήματα validation της εφαρμογής.
• Σημειώσεις συμβατότητας image και δεδομένων.
• Πολιτική αύξησης και διαγραφής.

Ελέγχετε τακτικά τη χρήση:

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

Η CPU, η RAM και ο δίσκος υπολογίζονται ανά λεπτό. Το Free plan προσφέρει αρχικό credit $10, ενώ το προτεινόμενο Pro plan κοστίζει $20 τον μήνα και περιλαμβάνει usage credit $20.

Άσκηση snapshot restore

Μην περιμένετε να συμβεί incident για να ανακαλύψετε ότι κανείς δεν γνωρίζει ποιο snapshot πρέπει να επιλέξει. Εκτελέστε μια ελεγχόμενη άσκηση σε non-production service ή σε εγκεκριμένο αντίγραφο:

1. Δημιουργήστε αναγνωρίσιμα test files.
2. Δημιουργήστε ένα snapshot.
3. Αλλάξτε τα αρχεία.
4. Κάντε restore του snapshot.
5. Επαληθεύστε τα περιεχόμενα και τα permissions.
6. Παρατηρήστε το restart του container.
7. Καταγράψτε τη διάρκεια και τα σημεία αποτυχίας.

Μια άσκηση restore μετατρέπει τα persistent volumes και snapshots από checkbox σε δοκιμασμένη δυνατότητα recovery.

Για τον αρχικό σχεδιασμό service, δείτε το Git repository to production. Για λεπτομέρειες εντολών, χρησιμοποιήστε το Dockup CLI reference.

Ορίστε recovery objectives για file data

Το recovery point objective απαντά στο πόσα πρόσφατα δεδομένα μπορεί να χάσει η επιχείρηση. Το recovery time objective απαντά στο πόσο μπορεί να διαρκέσει η επαναφορά. Ένα ημερήσιο snapshot με retention επτά αντιγράφων μπορεί να επαρκεί για ένα εσωτερικό media cache, αλλά όχι για ένα προϊόν user uploads που υπόσχεται near-real-time durability.

Καταγράψτε και τις δύο τιμές και μετρήστε τον πραγματικό χρόνο restore. Η ταχύτητα δημιουργίας snapshot, το μέγεθος των δεδομένων, το restart του container, το file validation και το application reindexing συμβάλλουν όλα στον χρόνο recovery.

Ελέγξτε τη διαγραφή και την αύξηση των αρχείων

Το persistent storage μπορεί να γεμίσει επειδή η εφαρμογή δεν διαγράφει ποτέ προσωρινά ή αντικατασταθέντα αρχεία. Προσθέστε retention policy στο application layer και διαχωρίστε τη logical deletion από την άμεση physical deletion. Ένα σύντομο recovery window μπορεί να δικαιολογεί την καθυστέρηση της οριστικής διαγραφής.

Πριν εκτελέσετε bulk cleanup:

1. Μετρήστε την τρέχουσα χρήση του volume.
2. Δημιουργήστε λίστα υποψήφιων αρχείων προς διαγραφή.
3. Δημιουργήστε ένα snapshot.
4. Εκτελέστε το cleanup σε bounded batches.
5. Επαληθεύστε τα application references.
6. Επιβεβαιώστε την αναμενόμενη απελευθέρωση χώρου.

Έτσι, τα persistent volumes και snapshots αποκτούν προληπτικό ρόλο και όχι μόνο ρόλο αντιμετώπισης incident.

Επαληθεύστε το snapshot inventory

Ελέγχετε σε τακτά διαστήματα τα snapshot IDs, τους χρόνους δημιουργίας, το retention και το τελευταίο επιτυχές restore test. Ένα ρυθμισμένο job χωρίς πρόσφατο usable snapshot δεν αποτελεί recovery system.

Αναθέστε την authority για restore

Ορίστε ποιος μπορεί να εγκρίνει ένα production restore και ποιος εκτελεί το post-restore validation. Ο διαχωρισμός approval και execution μειώνει την πιθανότητα η επείγουσα κατάσταση να παρακάμψει την επαλήθευση target και snapshot.

Ξεκινήστε με ένα επαληθεύσιμο deployment

Δημιουργήστε ένα non-production volume, πάρτε ένα snapshot, αλλάξτε ένα test file και ολοκληρώστε μια άσκηση restore πριν αποθηκεύσετε irreplaceable production data.

Start free at app.dockup.ai. Το Free plan κοστίζει $0 τον μήνα, περιλαμβάνει αρχικό credit $10 και υποστηρίζει ένα workspace, τρεις databases και τρία deployments.

FAQ

Επιβιώνει ένα Dockup volume από το deployment;

Ναι. Το volume παραμένει persistent ενώ τα service containers αντικαθίστανται, υπό την προϋπόθεση ότι η εφαρμογή συνεχίζει να χρησιμοποιεί το ρυθμισμένο mount path.

Είναι ένα volume snapshot το σωστό backup για PostgreSQL;

Όχι. Ένα hot snapshot ενός database data directory μπορεί να μην είναι transaction-consistent. Για managed databases, προτιμήστε το managed database backup system.

Τι συμβαίνει όταν γίνεται restore ενός volume snapshot;

Τα τρέχοντα περιεχόμενα του volume αντικαθίστανται από το επιλεγμένο snapshot και το container κάνει restart, επομένως η operation πρέπει να εγκρίνεται και να επαληθεύεται.

Μπορεί το Dockup να προγραμματίσει volume snapshots;

Ναι. Η εντολή volume schedule υποστηρίζει daily snapshots με retention count και το schedule μπορεί να απενεργοποιηθεί explicit.

Το rollback μιας εφαρμογής κάνει rollback και στο volume της;

Όχι. Το ιστορικό application deployment και το ιστορικό volume snapshots είναι ξεχωριστά. Συντονίστε τα μόνο όταν το απαιτεί το recovery plan.