Ανάκτηση σε συγκεκριμένο χρονικό σημείο έναντι Snapshots: Τι χάνετε

Κάποιος εκτελεί ένα DELETE χωρίς ρήτρα WHERE στις 4:15 μ.μ. Το πιο πρόσφατο backup σας είναι από τις 03:00. Όλα όσα συνέβησαν ανάμεσα σε αυτές τις δύο χρονικές στιγμές χάθηκαν και καμία επαναφορά δεν μπορεί να τα φέρει πίσω.

Αυτό το κενό έχει όνομα — στόχος σημείου ανάκτησης, ή RPO — και η απόφαση για ανάκτηση σε συγκεκριμένο χρονικό σημείο έναντι snapshots αφορά αποκλειστικά το πόσο μεγάλο είστε διατεθειμένοι να το αφήσετε να είναι.

Τα δύο μοντέλα

Τα snapshots καταγράφουν την κατάσταση των δεδομένων σας σε μια συγκεκριμένη χρονική στιγμή. Εκτελούνται βάσει προγράμματος, συνήθως κάθε βράδυ. Η επαναφορά ενός snapshot σάς επιστρέφει ακριβώς στην κατάσταση που υπήρχε όταν δημιουργήθηκε και όλα όσα έγιναν μετά χάνονται.

Η ανάκτηση σε συγκεκριμένο χρονικό σημείο συνδυάζει ένα βασικό backup με μια συνεχή ροή του write-ahead log της βάσης δεδομένων. Επειδή κάθε αλλαγή καταγράφεται με τη σειρά, μπορείτε να κάνετε replay σε οποιαδήποτε χρονική στιγμή καλύπτεται από το διατηρούμενο log — ακόμη και στις 4:14 μ.μ., ένα λεπτό πριν από τη διαγραφή.

Η διαφορά δεν είναι σταδιακή. Είναι η διαφορά ανάμεσα στο «χάσαμε μια μέρα» και στο «χάσαμε ένα λεπτό».

Ο αριθμός που το καθορίζει

Κάντε στον εαυτό σας μία ειλικρινή ερώτηση: αν χάνατε όλα όσα γράφτηκαν τις τελευταίες δώδεκα ώρες, τι θα συνέβαινε;

Για ένα προσωπικό project, έναν ιστότοπο τεκμηρίωσης ή ένα εσωτερικό εργαλείο με δεδομένα που μπορούν να αναπαραχθούν: όχι πολλά. Τα nightly snapshots είναι πραγματικά η σωστή επιλογή και η πληρωμή για continuous archiving θα ήταν σπατάλη.

Για οτιδήποτε δέχεται εγγραφές από πελάτες, η απάντηση συνήθως είναι κάποια εκδοχή του «θα έπρεπε να στείλουμε email και να το εξηγήσουμε». Παραγγελίες που δεν υπάρχουν πλέον. Αρχεία που εξαφανίστηκαν. Μηνύματα που στάλθηκαν και τώρα δεν υπάρχουν. Μόνο το κόστος υποστήριξης συνήθως ξεπερνά τη διαφορά στο κόστος υποδομής για έναν ολόκληρο χρόνο.

Το λάθος δεν είναι να επιλέξετε snapshots. Το λάθος είναι να επιλέξετε snapshots από προεπιλογή, χωρίς να αναρωτηθείτε ποτέ πόσο θα κόστιζε ένα κενό δώδεκα ωρών.

Σε τι είναι πραγματικά καλά τα snapshots

Δεν πρόκειται για κατώτερο προϊόν. Καλύπτουν περιπτώσεις αστοχίας που δεν καλύπτει το PITR:

• Απώλεια ολόκληρου του δίσκου. Ένα snapshot σε ξεχωριστό storage επαναφέρει τα πάντα, συμπεριλαμβανομένων των αρχείων που δεν ανήκουν στη βάση δεδομένων.
• Γρήγορη, γενικευμένη επαναφορά. Η αναίρεση μιας αποτυχημένης migration σε staging environment είναι ταχύτερη από ένα snapshot παρά από την αναπαραγωγή ενός log.
• Κόστος. Η αποθήκευση ενός αντιγράφου την ημέρα είναι φθηνότερη από την αποθήκευση κάθε εγγραφής.
• Απλότητα. Τα λιγότερα moving parts αποτελούν πραγματικό λειτουργικό πλεονέκτημα, ειδικά για μια μικρή ομάδα.

Η παγίδα είναι να τα θεωρείτε επαρκή για μια βάση δεδομένων που δέχεται συνεχείς εγγραφές.

Τι σας κοστίζει το PITR

Δεν είναι δωρεάν και αξίζει να αναφέρουμε τα κόστη:

• Storage. Διατηρείτε το βασικό backup και κάθε εγγραφή για όλη την περίοδο retention.
• Πολυπλοκότητα. Το archiving πρέπει να λειτουργεί συνεχώς. Ένα archiver που αποτυγχάνει σιωπηλά επί μία εβδομάδα σημαίνει ότι το ανακτήσιμο παράθυρό σας τελειώνει μία εβδομάδα πριν — γι’ αυτό η παρακολούθηση του archive είναι εξίσου σημαντική με τη ρύθμισή του.
• Χρόνος επαναφοράς. Η αναπαραγωγή ενός log διαρκεί περισσότερο από την επαναφορά ενός snapshot. Το RPO σας βελτιώνεται, αλλά το RTO συνήθως χειροτερεύει.

Αυτή η τελευταία αντιστάθμιση αιφνιδιάζει πολλούς. Το PITR σημαίνει ότι χάνετε λιγότερα δεδομένα, όχι ότι επιστρέφετε ταχύτερα σε λειτουργία.

Η πολυεπίπεδη απάντηση που χρειάζονται στην πράξη οι περισσότερες ομάδες

Στην πράξη, δεν πρόκειται για επιλογή ανάμεσα σε δύο πράγματα. Οι production βάσεις δεδομένων συνήθως χρειάζονται τρία επίπεδα, επειδή αποτυγχάνουν με τρεις διαφορετικούς τρόπους:

Snapshots, καθημερινά, με retention μίας ή δύο εβδομάδων. Φθηνή ασφάλεια απέναντι στην απώλεια του μηχανήματος. Αυτό καλύπτει επίσης τα αρχεία εκτός βάσης δεδομένων που βρίσκονται στο ίδιο volume.

Logical dumps, καθημερινά, αποθηκευμένα εκτός host. Ένα pg_dump είναι φορητό και συνεπές από κατασκευής. Μπορεί να γίνει restore σε διαφορετική major version, διαφορετικό provider ή laptop — ακριβώς αυτό που χρειάζεστε όταν το πρόβλημα αφορά την πλατφόρμα και όχι τα δεδομένα.

Continuous archiving, όταν η βάση περιέχει δεδομένα πελατών. Το επίπεδο που μετατρέπει το «χάσαμε τη σημερινή μέρα» σε «χάσαμε ένα λεπτό».

Κάθε επίπεδο καλύπτει όσα δεν καλύπτουν τα άλλα. Ένα snapshot δεν βοηθά στη μεταφορά μεταξύ providers. Ένα logical dump δεν βοηθά στην ανάκτηση ενός αρχείου που δεν βρισκόταν στη βάση δεδομένων. Κανένα από τα δύο δεν σας βοηθά να αναιρέσετε μια διαγραφή που έγινε πριν από τέσσερις ώρες.

Πού εντάσσεται το Dockup

Το Dockup σάς παρέχει τα δύο επίπεδα που καλύπτουν τις συνηθέστερες αστοχίες και αξίζει να είμαστε ακριβείς ως προς το ποια είναι αυτά.

Volume snapshots, κατ’ απαίτηση ή βάσει προγράμματος με αριθμό retention:

dockup volume snapshot <volumeId> my-project/my-api
dockup volume schedule <volumeId> my-project/my-api --daily --retention 7
dockup volume restore <volumeId> <snapshotId> my-project/my-api

Logical database backups, τα οποία μεταδίδονται απευθείας σε object storage και κρυπτογραφούνται κατά τη μεταφορά:

dockup db backup my-project/main-db --json
dockup db backups my-project/main-db --json

Δύο ιδιότητες του δεύτερου είναι σημαντικές για την ανάκτηση. Το backup δεν αποθηκεύεται ποτέ στον host της βάσης δεδομένων — μεταδίδεται στο storage καθώς το pg_dump το δημιουργεί, επομένως δεν μοιράζεται την ίδια μοίρα με τον δίσκο από τον οποίο προήλθε. Επίσης, ένα dump που ολοκληρώνεται με μη μηδενικό κωδικό εξόδου ή παράγει μηδέν bytes διαγράφεται και καταγράφεται ως αποτυχημένο, αντί να παραμένει στη λίστα και να μοιάζει με κανονικό backup.

Το Continuous archiving δεν είναι κάτι που εκτελεί σήμερα το Dockup για λογαριασμό σας. Αν το RPO σας χρειάζεται πραγματικά να μετριέται σε λεπτά, αξίζει να το γνωρίζετε πριν επιλέξετε και είναι απολύτως λογικό να το εκτελείτε μόνοι σας σε μια managed database, χρησιμοποιώντας την πλατφόρμα για όλα τα υπόλοιπα.

Η άσκηση που αξίζει να κάνετε αυτή την εβδομάδα

Καταγράψτε δύο αριθμούς για την production βάση δεδομένων σας:

1. RPO — πόσα δεδομένα μπορείτε να χάσετε. Μετριέται σε χρόνο.
2. RTO — για πόσο μπορείτε να παραμείνετε εκτός λειτουργίας. Επίσης μετριέται σε χρόνο.

Στη συνέχεια, ελέγξτε τι παρέχει πραγματικά η τρέχουσα ρύθμισή σας, κάνοντας restore σε κάτι. Αν οι αριθμοί που καταγράψατε και οι αριθμοί που παρέχει η ρύθμισή σας διαφέρουν, έχετε εντοπίσει μια απόφαση που πρέπει να πάρετε ενώ τίποτα δεν καίγεται — και αυτή είναι η μόνη καλή στιγμή για να την πάρετε.

Συχνές ερωτήσεις

Ποια είναι η διαφορά μεταξύ RPO και RTO; Το RPO είναι πόσα δεδομένα χάνετε — το κενό ανάμεσα στην τελευταία ανακτήσιμη χρονική στιγμή και την αστοχία. Το RTO είναι ο χρόνος που απαιτείται για την ανάκτηση. Τα snapshots σάς δίνουν μεγάλο RPO και μικρό RTO, ενώ το PITR αντιστρέφει αυτή την ισορροπία.

Μπορώ να ανακτήσω γραμμές που διαγράφηκαν πριν από μία ώρα από ένα nightly snapshot; Όχι. Ένα snapshot επαναφέρει την κατάσταση τη στιγμή που δημιουργήθηκε. Οτιδήποτε γράφτηκε μετά δεν περιλαμβάνεται στο αρχείο. Η ανάκτηση μιας αυθαίρετης χρονικής στιγμής απαιτεί continuous archiving.

Είναι ένα volume snapshot το ίδιο με ένα database backup; Όχι. Ένα snapshot καταγράφει τον δίσκο, συμπεριλαμβανομένης της κατάστασης στην οποία μπορεί να βρισκόταν η βάση δεδομένων στη μέση μιας εγγραφής. Ένα logical dump είναι εσωτερικά συνεπές και φορητό σε άλλες εκδόσεις και providers. Οι περισσότερες production ρυθμίσεις χρειάζονται και τα δύο.

Για πόσο διάστημα πρέπει να διατηρώ τα backups; Για αρκετό διάστημα ώστε να προλάβετε να εντοπίσετε ένα πρόβλημα. Η καταστροφή δεδομένων ή μια προβληματική migration συχνά ανακαλύπτεται αρκετές ημέρες αργότερα, επομένως η διατήρηση για μία μόνο ημέρα συχνά σημαίνει ότι τα μόνα backups που έχετε περιέχουν ήδη τη ζημιά.