Ένα σχέδιο αντιγράφων ασφαλείας για τον server σας

Ενότητα 8: Αντίγραφα ασφαλείας και παρακολούθηση · Χρόνος ανάγνωσης: 11 λεπτά

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

Βασικές έννοιες: κανόνας 3-2-1, snapshot, αντίγραφο ασφαλείας του παρόχου, δικό σας αντίγραφο ασφαλείας εκτός παρόχου, RPO, RTO, dump βάσης δεδομένων (mariadb-dump, pg_dump), ρυθμίσεις στο /etc, Docker volumes, κρυπτογράφηση, ransomware, append-only, δοκιμή επαναφοράς

Γιατί ένα σχέδιο και όχι απλώς "υπάρχει ήδη αντίγραφο ασφαλείας";

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

Ένα σχέδιο απαντά σε πέντε ερωτήσεις:

1. Τι πρέπει να μπορεί να επανέλθει;
2. Πόσα δεδομένα επιτρέπεται να χάσετε; (RPO)
3. Πόσο γρήγορα πρέπει να λειτουργεί ξανά; (RTO)
4. Πού βρίσκονται τα αντίγραφα και πόσα είναι;
5. Πώς ξέρετε ότι λειτουργεί;

Τι πρέπει να μπορεί να επανέλθει;

Ένας server αποτελείται από επίπεδα. Δεν χρειάζεται κάθε επίπεδο να μπει στο αντίγραφο ασφαλείας:

Δώστε ιδιαίτερη προσοχή στις βάσεις δεδομένων. Μια βάση δεδομένων που εκτελείται γράφει συνεχώς. Αν αντιγράψετε τα αρχεία μιας MariaDB ή PostgreSQL που εκτελείται, μπορεί να καταλήξετε με κατεστραμμένο αντίγραφο. Γι' αυτό δημιουργήστε πρώτα ένα dump: ένα συνεπές στιγμιότυπο σε μορφή αρχείου, το οποίο στη συνέχεια συμπεριλαμβάνετε στο αντίγραφο ασφαλείας.

root@web1:~# mariadb-dump --single-transaction --all-databases | gzip > /var/backups/db/alles-$(date +%F).sql.gz
root@web1:~# sudo -u postgres pg_dumpall | gzip > /var/backups/db/pg-$(date +%F).sql.gz

(Το mariadb-dump παλαιότερα ονομαζόταν mysqldump· αυτή η εντολή συνήθως λειτουργεί ακόμη.) Αν η βάση δεδομένων εκτελείται σε container, κάνετε το ίδιο με το docker compose exec (μάθημα 9.4).

RPO και RTO: πόσα επιτρέπεται να χάσετε;

Δύο έννοιες από την επαγγελματική πρακτική βοηθούν στη λήψη αποφάσεων:

• RPO (recovery point objective): πόσο χρονικό διάστημα δεδομένων επιτρέπεται να χάσετε το πολύ; Ένα ημερήσιο αντίγραφο ασφαλείας στις 03:00 σημαίνει: αν ο server καταρρεύσει στις 22:00, χάνετε σχεδόν μια μέρα. Για ένα ηλεκτρονικό κατάστημα με παραγγελίες αυτό είναι πολύ· για ένα blog που αλλάζει μία φορά την εβδομάδα είναι μια χαρά.
• RTO (recovery time objective): πόσο επιτρέπεται να διαρκέσει μέχρι να λειτουργούν ξανά όλα; Η επαναφορά ενός πλήρους αντιγράφου ασφαλείας του παρόχου μπορεί να γίνει σε λίγα λεπτά· η δημιουργία νέου server και η χειροκίνητη επαναφορά όλων μπορεί να πάρει ώρες.

Καταγράψτε τα για τον δικό σας server. Αυτά καθορίζουν πόσο συχνά δημιουργείτε αντίγραφο ασφαλείας και πώς το φυλάτε.

Snapshot, αντίγραφο ασφαλείας του παρόχου, δικό σας αντίγραφο ασφαλείας

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

1. Το snapshot. Ένα στιγμιότυπο ολόκληρου του εικονικού δίσκου, που δημιουργείται στον πίνακα ελέγχου του παρόχου σας. Δημιουργείται γρήγορα και επαναφέρεται γρήγορα. Ιδανικό λίγο πριν από μια αναβάθμιση (μάθημα 4.3). Όμως: στους περισσότερους παρόχους ένα snapshot βρίσκεται στον ίδιο αποθηκευτικό χώρο με τον server σας. Αν χαλάσει αυτός ο αποθηκευτικός χώρος ή χάσετε τον λογαριασμό σας, χάνεται και το snapshot. Επίσης ένα snapshot δεν το κρατάτε για πολύ: μεγαλώνει μαζί με όλες τις αλλαγές που ακολουθούν. Ένα snapshot δεν είναι αντίγραφο ασφαλείας.

2. Το αντίγραφο ασφαλείας του παρόχου. Πολλοί πάροχοι δημιουργούν (ενδεχομένως ως επιλογή) αυτόματα κάθε μέρα ένα αντίγραφο ολόκληρου του server σας, σε άλλον αποθηκευτικό χώρο. Στο WebOké, για παράδειγμα, πρόκειται για ένα ημερήσιο αντίγραφο ασφαλείας ολόκληρου του VPS που διατηρείται επτά ημέρες· σε άλλους παρόχους λειτουργεί παρόμοια, με δικές τους προθεσμίες. Αυτό είναι ένα καλό δεύτερο επίπεδο απέναντι σε χαλασμένο υλικό και στα δικά σας λάθη της προηγούμενης μέρας. Παραμένει όμως ένας μόνο φορέας: ο λογαριασμός σας, η πληρωμή σας, η δική τους βλάβη. Και η επαναφορά γίνεται συνήθως για ολόκληρο τον server ταυτόχρονα.

3. Το δικό σας αντίγραφο ασφαλείας, εκτός παρόχου. Ένα αντίγραφο των δεδομένων σας σε άλλον φορέα ή σε άλλη τοποθεσία, το οποίο δημιουργείτε και διαχειρίζεστε εσείς (μάθημα 8.2). Αυτό είναι το επίπεδο που απομένει όταν όλα τα άλλα αποτύχουν.

Ο κανόνας 3-2-1

Ένας διαδεδομένος πρακτικός κανόνας:

• 3 αντίγραφα των δεδομένων σας (το πρωτότυπο συν δύο αντίγραφα ασφαλείας)·
• σε 2 διαφορετικά είδη αποθήκευσης ή συστήματα·
• από τα οποία 1 σε άλλη τοποθεσία.

Για ένα VPS αυτό μπορεί να είναι: τα δεδομένα στον server, το ημερήσιο αντίγραφο ασφαλείας του παρόχου και ένα κρυπτογραφημένο δικό σας αντίγραφο ασφαλείας με το restic σε αποθηκευτικό χώρο άλλου φορέα. Μια σύγχρονη προσθήκη είναι ότι τουλάχιστον ένα αντίγραφο δεν μπορεί να διαγραφεί από όποιον αποκτήσει τον έλεγχο του server (offline ή append-only, μάθημα 8.2). Το ransomware σε έναν server ψάχνει ενεργά για αντίγραφα ασφαλείας, ώστε να τα κρυπτογραφήσει ή να τα διαγράψει κι αυτά. Ένα αντίγραφο ασφαλείας που μπορεί να διαγράψει ο ίδιος ο server δεν προσφέρει καμία προστασία απέναντι σε αυτό.

Κρυπτογράφηση και ο κωδικός πρόσβασης του αντιγράφου ασφαλείας σας

Ένα αντίγραφο ασφαλείας σε άλλον φορέα πρέπει να είναι κρυπτογραφημένο: περιέχει δεδομένα πελατών, κωδικούς πρόσβασης και κλειδιά. Το restic (μάθημα 8.2) κρυπτογραφεί από προεπιλογή. Έτσι όμως δημιουργείται ένας νέος κίνδυνος: ο κωδικός πρόσβασης του αντιγράφου ασφαλείας σας. Αν τον χάσετε, το αντίγραφο ασφαλείας είναι άχρηστο. Το ίδιο ισχύει αν βρίσκεται μόνο στον server που χάσατε.

Γι' αυτό φυλάξτε τον κωδικό πρόσβασης και εκτός server: στον διαχειριστή κωδικών πρόσβασης σας και ενδεχομένως σε χαρτί μέσα σε χρηματοκιβώτιο. Το ίδιο ισχύει για τα στοιχεία πρόσβασης του αποθηκευτικού χώρου όπου βρίσκεται το αντίγραφο ασφαλείας σας.

Δοκιμή επαναφοράς

Το σημαντικότερο μέρος του σχεδίου. Δοκιμή επαναφοράς σημαίνει: επαναφέρετε πραγματικά ένα αντίγραφο ασφαλείας, σε ένα σημείο όπου δεν χαλάει τίποτα, και ελέγχετε αν το αποτέλεσμα λειτουργεί.

• Μικρή και συχνή: επαναφέρετε ένα αρχείο ή έναν φάκελο στο /tmp/terug και κάνετε σύγκριση (diff). Για παράδειγμα κάθε μήνα.
• Μεγάλη και περιστασιακή: δημιουργείτε έναν πλήρη νέο δοκιμαστικό server από το αντίγραφο ασφαλείας, εισάγετε τη βάση δεδομένων και ξεκινάτε τον ιστότοπο. Για παράδειγμα μία φορά τον χρόνο ή σε κάθε μεγάλη αλλαγή. Αυτό είναι ταυτόχρονα και η εξάσκηση για την περίπτωση που κάτι πάει πραγματικά στραβά (μάθημα 10.3).

Καταγράψτε πόσο διήρκεσε: αυτό είναι το πραγματικό σας RTO.

Χρόνοι διατήρησης

Μην κρατάτε μόνο το τελευταίο αντίγραφο ασφαλείας. Αν ανακαλύψετε μόλις μετά από δύο εβδομάδες ότι ένα αρχείο είναι κατεστραμμένο ή έχει διαγραφεί, χρειάζεστε ένα αντίγραφο ασφαλείας τριών εβδομάδων πριν. Ένα διαδεδομένο σχήμα: επτά ημερήσιες, τέσσερις εβδομαδιαίες και έξι μηνιαίες εκδόσεις. Το restic το ρυθμίζει αυτό με το forget (μάθημα 8.2). Σκεφτείτε επίσης τον GDPR (ΓΚΠΔ): τα προσωπικά δεδομένα δεν τα κρατάτε περισσότερο από όσο χρειάζεται, ούτε στα αντίγραφα ασφαλείας. Καταγράψτε τους χρόνους διατήρησης που εφαρμόζετε.

Στην πράξη

Χρησιμοποιήστε το snapshot του παρόχου σας λίγο πριν από επικίνδυνες αλλαγές και διαγράψτε το στη συνέχεια· αφήστε ενεργό το ημερήσιο αντίγραφο ασφαλείας του παρόχου, αν υπάρχει· και επιπλέον δημιουργήστε το δικό σας κρυπτογραφημένο αντίγραφο ασφαλείας δεδομένων και ρυθμίσεων σε άλλον φορέα. Στο WebOké αυτά ονομάζονται στην οθόνη του VPS Snapshots και Backups· σε άλλους παρόχους τα ονόματα και οι προθεσμίες διαφέρουν, αλλά η αρχή είναι η ίδια. Ένα πακέτο hosting ή μια διαχειριζόμενη υπηρεσία έχει συχνά διαφορετικές συμφωνίες: ελέγξτε τι ισχύει στη δική σας περίπτωση.

Σύνοψη

• Ένα αντίγραφο ασφαλείας έχει αξία μόνο αν η επαναφορά λειτουργεί· ξεκινήστε με ένα σχέδιο και τελειώστε με μια δοκιμή.
• Κρατήστε αντίγραφα κυρίως των δεδομένων και των ρυθμίσεων: βάσεις δεδομένων ως dump, /etc, ιστότοπους, Docker volumes, αρχεία compose.
• Ορίστε το RPO (πόσα επιτρέπεται να χάσετε) και το RTO (πόσο γρήγορα πρέπει να λειτουργεί).
• Το snapshot (ίδιος αποθηκευτικός χώρος, σύντομη διάρκεια), το αντίγραφο ασφαλείας του παρόχου (άλλος αποθηκευτικός χώρος, ίδιος φορέας) και ένα δικό σας αντίγραφο ασφαλείας εκτός παρόχου είναι τρία διαφορετικά επίπεδα· ακολουθήστε τον κανόνα 3-2-1 με τουλάχιστον ένα αντίγραφο που ο ίδιος ο server δεν μπορεί να διαγράψει.
• Κρυπτογραφήστε, φυλάξτε τον κωδικό πρόσβασης του αντιγράφου ασφαλείας εκτός server και δοκιμάζετε την επαναφορά σε μικρή κλίμακα συχνά και σε μεγάλη κλίμακα περιστασιακά.

Κουίζ

Άσκηση

Άσκηση O8.1: Το σχέδιο αντιγράφων ασφαλείας σας. Φτιάξτε για τον δικό σας server ένα σχέδιο αντιγράφων ασφαλείας σε μία σελίδα: τι πρέπει να μπορεί να επανέλθει (ανά επίπεδο), το RPO και το RTO σας, ποια αντίγραφα έχετε (snapshot, πάροχος, δικό σας) και πού, τους χρόνους διατήρησης, πού βρίσκεται ο κωδικός πρόσβασης του αντιγράφου ασφαλείας και πότε κάνετε δοκιμή επαναφοράς. Συμπληρώστε τη φόρμα· μετά την υποβολή βλέπετε ένα παράδειγμα σχεδίου για να το συγκρίνετε με το δικό σας.

Για περαιτέρω μελέτη

• Snapshots και backups του VPS σας
• Στρατηγική δημιουργίας αντιγράφων ασφαλείας: ο κανόνας 3-2-1 για τη δική σας επιχείρηση
• Στη σειρά μαθημάτων για την ασφάλεια στο διαδίκτυο (Veilig online): τα μαθήματα για τον κανόνα 3-2-1 και για αντίγραφα ασφαλείας που επιβιώνουν από ransomware.
• MariaDB, mariadb-dump: https://mariadb.com/docs/server/clients-and-utilities/backup-restore-and-import-clients/mariadb-dump
• PostgreSQL, Backup and Restore (SQL Dump): https://www.postgresql.org/docs/current/backup-dump.html