Πώς δοκιμάζετε ένα restore, όχι μόνο ένα backup

Κάθε κονσόλα backup στον κόσμο μπορεί να σας δείξει μια στήλη από πράσινα τικ. Καμία τους δεν μπορεί να σας πει αν η επιχείρησή σας θα τρέχει ξανά μέχρι το μεσημέρι μετά από μια κακή νύχτα. Μόνο ένα restore μπορεί να σας το πει αυτό, και το μόνο restore που μπορείτε να εμπιστευτείτε είναι αυτό που έχετε ήδη κάνει. Έτσι δοκιμάζετε restores ώστε το αποτέλεσμα να σημαίνει κάτι.

Τι αποδεικνύει πραγματικά ένα πράσινο job

Ένα επιτυχημένο backup job αποδεικνύει ότι ένα job έτρεξε, διάβασε κάποια δεδομένα και τα έγραψε κάπου χωρίς σφάλμα που το λογισμικό αναγνώρισε. Δεν αποδεικνύει ότι τα δεδομένα είναι πλήρη, ότι το μηχάνημα που σας ενδιαφέρει ήταν μέσα στο job, ότι το αντίγραφο μπορεί να διαβαστεί πίσω, ή ότι η εφαρμογή θα ξεκινήσει από αυτό.

Υπάρχουν τρία πράγματα να δοκιμάσετε: κάλυψη (γίνεται πραγματικά backup όλων όσων πρέπει), ανακτησιμότητα (μπορεί το αντίγραφο να διαβαστεί και να ξεκινήσει) και χρόνος (πόσο παίρνει πραγματικά μια ανάκαμψη). Οι περισσότεροι οργανισμοί δεν δοκιμάζουν κανένα από αυτά σε πρόγραμμα.

Βήμα πρώτο: ελέγξτε την κάλυψη απέναντι στην πραγματικότητα

Τα backup jobs ορίζονται σε μια χρονική στιγμή. Η υποδομή συνεχίζει να αλλάζει. Μια νέα εικονική μηχανή που δημιουργήθηκε δίπλα στις παλιές, μια βάση δεδομένων που μεταφέρθηκε σε νέο host, ένας server που μετονομάστηκε: καθένα μπορεί να πέσει έξω από κάθε job χωρίς να σηκωθεί ούτε ένα σφάλμα.

Οπότε συγκρίνετε τη λίστα όσων υπάρχουν με τη λίστα όσων προστατεύονται. Εξάγετε την απογραφή από το μέρος που ξέρει τι τρέχει, τον hypervisor, την πλατφόρμα cloud ή το DCIM, και τη λίστα προστατευμένων αντικειμένων από το σύστημα backup, και μετά συγκρίνετέ τες:

sort -u running-inventory.txt > running.sorted
sort -u protected-objects.txt > protected.sorted
comm -23 running.sorted protected.sorted   # running, but not protected
comm -13 running.sorted protected.sorted   # protected, but no longer running

Η πρώτη λίστα είναι η επικίνδυνη. Η δεύτερη είναι σκουπίδια που την κρύβουν. Κάθε εγγραφή της πρώτης λίστας χρειάζεται μια απόφαση: προσθήκη σε job, ή γραπτή σημείωση ότι συνειδητά δεν έχει backup και γιατί.

Βήμα δεύτερο: restore σε περισσότερα από ένα επίπεδα

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

Επίπεδο αρχείου. Κάντε restore ένα δείγμα αρχείων σε εναλλακτική θέση και συγκρίνετέ τα με checksums με την πηγή ή με ένα γνωστό καλό αντίγραφο. Αυτό πιάνει μη αναγνώσιμα μέσα και σπασμένες αλυσίδες incremental backups.

Επίπεδο μηχανήματος. Εκκινήστε έναν ολόκληρο server ή εικονική μηχανή από backup. Αυτό πιάνει boot volumes που λείπουν, drivers και τον δίσκο που εξαιρέθηκε αθόρυβα από το job. Οι περισσότερες enterprise πλατφόρμες backup, μεταξύ αυτών το Veeam, μπορούν να ξεκινήσουν ένα μηχάνημα κατευθείαν από το backup repository σε απομονωμένο lab ακριβώς για αυτόν τον σκοπό.

Επίπεδο εφαρμογής. Αποδείξτε ότι η εφαρμογή δουλεύει από το επαναφερμένο αντίγραφο. Για μια βάση δεδομένων, αυτό σημαίνει ότι ξεκινά, περνά τον δικό της έλεγχο συνέπειας, και περιέχει τις νεότερες εγγραφές που περιμένετε για τη στιγμή του backup:

# MySQL or MariaDB
mysqlcheck --all-databases --check
mysql -e "SELECT MAX(created_at) FROM orders;"

# PostgreSQL
pg_amcheck --all
psql -c "SELECT max(created_at) FROM orders;"

Για εργαλεία backup σε επίπεδο αρχείου υπάρχουν έλεγχοι ακεραιότητας που διαβάζουν πίσω τα αποθηκευμένα δεδομένα, για παράδειγμα borg check --verify-data σε ένα Borg repository.

Βήμα τρίτο: restore σε lab, όχι σε παραγωγή

Ένα επαναφερμένο μηχάνημα είναι αντίγραφο της παραγωγής, με τις διευθύνσεις, τα διαπιστευτήρια, τις προγραμματισμένες εργασίες και το εξερχόμενο mail της παραγωγής. Σηκώστε το στο πραγματικό δίκτυο και μπορεί να απαντήσει σε αιτήματα που προορίζονταν για τον ζωντανό server, να στείλει σε πελάτες μια παρτίδα διπλών emails, ή να τρέξει το χθεσινοβραδινό job χρέωσης για δεύτερη φορά.

Οι δοκιμές restore ανήκουν επομένως σε απομονωμένο δίκτυο χωρίς διαδρομή προς την παραγωγή και χωρίς διαδρομή προς το internet. Πριν ξεκινήσετε οποιαδήποτε εφαρμογή σε αυτό το lab, απενεργοποιήστε τον scheduler και το εξερχόμενο mail στο επαναφερμένο αντίγραφο. Κάντε το γραπτό βήμα της δοκιμής, ώστε να μη χρειάζεται να το θυμάται κανείς.

Βήμα τέταρτο: χρονομετρήστε το

Ο χρόνος ανάκαμψης στο χαρτί είναι εκτίμηση. Αυτός που μετράει είναι ο μετρημένος: από τη στιγμή που κάποιος αποφασίζει να κάνει restore, μέσα από την εύρεση του σωστού restore point, τη μετακίνηση των δεδομένων, την εκκίνηση των υπηρεσιών και τον έλεγχο της εφαρμογής, μέχρι την πρώτη επιτυχημένη πραγματική συναλλαγή. Τα μεγάλα restores συχνά περιορίζονται από απόδοση που κανείς δεν μέτρησε, ή από ένα βήμα που μόνο ένα άτομο ξέρει πώς να κάνει. Η χρονομέτρηση ολόκληρης της ακολουθίας βρίσκει και τα δύο.

Βήμα πέμπτο: γράψτε το

Κρατήστε μια σύντομη καταχώριση για καθένα:

• Ημερομηνία, και ποιος το έτρεξε.
• Τι επαναφέρθηκε, από ποιο restore point.
• Ποιο επίπεδο δοκιμάστηκε: αρχείο, μηχάνημα ή εφαρμογή.
• Χρόνος που πήρε, από άκρη σε άκρη.
• Οτιδήποτε απέτυχε, σας εξέπληξε ή χρειάστηκε γνώση που δεν είναι γραμμένη.
• Τι άλλαξε ως αποτέλεσμα.

Και ο σχεδιασμός από κάτω μετράει

Οι δοκιμές αποδεικνύουν ότι τα backups υπάρχουν και δουλεύουν σήμερα. Ο σχεδιασμός αποφασίζει αν θα υπάρχουν ακόμα μετά από μια κακή μέρα. Ο κανόνας που μετράει περισσότερο είναι ότι τα backups τραβιούνται. Το σύστημα backup φτάνει μέσα στην παραγωγή και παίρνει ό,τι χρειάζεται. Η παραγωγή δεν έχει διαδρομή δικτύου προς το σύστημα backup και δεν έχει διαπιστευτήρια γι' αυτό. Τότε ένας εισβολέας που κατέχει έναν server παραγωγής δεν μπορεί να φτάσει στα backups του ίδιου server για να τα διαγράψει. Η append-only πρόσβαση για εργαλεία επιπέδου αρχείου προσθέτει δεύτερη κλειδαριά, και το ιστορικό στο repository σημαίνει ότι ένα αντίγραφο από πριν από το πρόβλημα εξακολουθεί να υπάρχει.

Πώς το κάνουμε εμείς

Τα backups μας είναι pull-only εκ σχεδιασμού και επιβάλλονται στις συσκευές firewall, με μόνο το δίκτυο διαχείρισης να μπορεί να φτάσει σε συστήματα backup και ανάκαμψης. Χρησιμοποιούμε Veeam για εικονικές μηχανές, φυσικούς servers και SQL servers, και ένα deduplicating backup hub που τραβά δεδομένα αρχείων και βάσεων Linux με περιορισμένα, append-only κλειδιά. Η κάλυψη ελέγχεται απέναντι στη ζωντανή απογραφή, τα προγράμματα ορίζονται από μετρημένους χρόνους εκτέλεσης, και πλήρη restores τρέχουν ακόμη και κάθε εβδομάδα.

Αν δεν έχετε χρονομετρήσει ποτέ ένα πλήρες restore του πιο σημαντικού σας συστήματος, από αυτό ξεκινήστε, και ευχαρίστως να σας βοηθήσουμε να το σχεδιάσετε.

CTA

Μιλήστε με έναν μηχανικό

Related

Σχετικά: Disaster recovery και replicas μεταξύ sites · Storage replication ανάμεσα σε Αθήνα και Άμστερνταμ · Υπηρεσίες αρχείων NAS, NFS και SMB