RPO vs RTO. Turned a cube and changed the word 'RTO - recovery time objective' to 'RPO - recovery point objective'. Business and RPO vs RTO concept. Beautiful grey background, copy space.

RPO, RTO και προστασία δεδομένων σε οργανισμούς

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

rpo vs rto. turned a cube and changed the word 'rto recovery time objective' to 'rpo recovery point objective'. business and rpo vs rto concept. beautiful grey background, copy space.

Μεθοδολογία backup 3-2-1

Ο χρυσός κανόνας που πρέπει να ακολουθεί η κάθε backup στρατηγική μιας εταιρείας είναι η μεθοδολογία 3-2-1 οπού περιληπτικά σημαίνει: 3 διαφορετικά αντίγραφα των δεδομένων, 2 διαφορετικοί τρόποι αποθήκευσης, 1 από αυτά να είναι απομακρυσμένο.

Ας τα δούμε αναλυτικά.

Ξεκινάμε με 3 αντίγραφα των δεδομένων που μπορεί να είναι οτιδήποτε. Συνήθως το πρώτο αντίγραφο το συναντάμε πάνω στο storage array στην περίπτωση φυσικά που η υποδομή κατέχει τέτοιου επιπέδου συσκευή. Αυτό το δημιουργούμε με την μορφή snapshot και μας προσφέρει τον συντομότερο τρόπο ανάκτησης σε περίπτωση καταστροφής. Στην περίπτωση που δεν έχουμε shared storage μπορούμε να χρησιμοποιήσουμε τον hypervisor (VMware vSphere ή Microsoft HyperV) για να κάνουμε παρόμοια δουλεία. Φυσικά κάποιος σε αυτό το σημείο μπορεί να αναρωτηθεί τι κάνουμε σε περίπτωση που χάσουμε το storage καθαυτού.

Με αυτήν την ευκαιρία μπαίνουμε στο δεύτερο αντίγραφο που ιδανικά πρέπει να ζει έξω από το κύριο compute και storage της υποδομής μας. Αυτό μπορεί να είναι οτιδήποτε όπως ένας απλός με δίσκους και NFS shares ή κάτι εξελιγμένο όπως ένα S3 repository ή κάποιο dedicated backup appliance όπως το ΗPE StoreOnce. Η κάθε επιλογή έχει τα αρνητικά και τα θετικά της και τις περισσότερες φορές κινούμαστε με γνώμονα το budget του πελάτη.

Τέλος συνδυάζουμε τα 2 διαφορετικά μέσα αποθήκευσης με το 1 απομακρυσμένο. Σαν διαφορετικά μέσα μπορούμε να έχουμε το cloud ή κάποια κασέτα τύπου Linear Type Open (LTO). Ναι, η κασέτα στον κόσμο του enterprise IT ζει και βασιλεύει. Η τελευταία γενιά μάλιστα LTO-9 βγήκε το 2021 με συμπιεσμένη χωρητικότητα 45ΤΒ με πλάνα να υπάρξει και LTO-14 με χωρητικότητα 1.4PB. Με το μικρό φυσικό μέγεθος της μπορεί εύκολα να σταλεί σε ένα απομακρυσμένο σημείο ή/και σε κάποια θυρίδα. Αν κάποιος δεν θέλει να επενδύσει σε ανάλογο εξοπλισμό για LTO tapes μπορεί να στηριχθεί σε κάποιο public cloud service όπως το AWS Glacier. Καλύτερο φυσικά είναι να έχουμε και τα 2 εφόσον το budget μας το επιτρέπει.

RTO και RPO

Σε αυτό το σημείο θα μιλήσουμε για το RTO και το RPO. Αρχικά όλα τα μέσα για backups κάνουν την δουλεία τους και παίρνουν backup. Το ξεκινάει όταν μιλάμε για χρόνους και σημεία ανάκτησης και πιθανά σενάρια καταστροφής.

Ας δούμε το RPO ή Recovery Point Objective. Με αυτή την έννοια μετράμε το αμέσως προηγούμενο σημείο από το οποίο έχουμε χρήσιμο backup. Για παράδειγμα αν έχουμε απώλεια δεδομένων στις 12:00 και το προηγούμενο αντίγραφο ασφαλείας είναι στις 11:00 τότε λέμε ότι έχουμε RPO μίας ώρας. Αυτός ο αριθμός ορίζεται από τον IT administrator και πρέπει να καλύπτει όλες τις ανάγκες της εταιρείας. Κάποιο οργανισμοί είναι χαρούμενοι με RPO 2-3 ωρών. Άλλοι απαιτούν λίγα μόλις λεπτά. Φυσικά, μπορεί κάποιος να πει ότι όσο μειώνουμε το RPΟ αυξάνουμε το κόστος της backup υποδομής μας.

Αμέσως μετά έχουμε και το RTO ή Recovery Time Objective. Με αυτό μετράμε τον χρόνο που χρειάζεται για να ανακτήσουμε από το backup. Για παράδειγμα αν πάμε να κάνουμε ανάκτηση από το public cloud έναν μεγάλο όγκο δεδομένων περιοριζόμαστε από την γραμμή internet που έχει η εταιρεία. Aν καταλήξουμε να κάνουμε ανάκτηση από κασέτα που είναι σε ένα απομακρυσμένο σημείο τότε το RTO αυξάνεται εκθετικά.

Αυτά τα συστήματα μέτρησης συνδυάζονται με την 3-2-1 μεθοδολογία και από το backup το οποίο ανακτούμε μπορεί να αυξήσει ή να μειώσει το σημείο και τον χρόνο ανάκτησης.

Για παράδειγμα ας χρησιμοποιήσουμε ένα παράδειγμα της γνωστής ΦΟΥΦΟΥΤΟΣ ΑΕ.

Η εταιρεία αυτή έχει μια κλασική 3 tier αρχιτεκτονική (network, compute, storage) και τρέχει VMware. Το βασικό της application είναι ένα SAP στο οποίο βασίζουν όλες τους τις λειτουργείες. Υπάρχουν φυσικά και διάφορα applications όπως file server, πρόγραμμα μισθοδοσίας, πρόγραμμα HR. Ο συνολικός όγκος δεδομένων είναι περίπου στα 10TB.

Το βασικό storage είναι σύγχρονο, υποστηρίζει deduplication & data reduction (βλ. Alletra 6000)

Για backup appliance χρησιμοποιούν ένα StoreOnce με δυνατότητα να στέλνει και αντίγραφο στο Cloud (AWS)

Σαν immutable long term retention σύστημα έχουν και LTO-9 κασέτες με ρομποτική βιβλιο τύπου MSL 3040

Τα backups τα συντονίζει το Veeam Backup and Replication.

Με την υποδομή τους έχουμε τα παρακάτω RTO & RPO:

  • Ανάκτηση από το Alletra 6000 Storage
    • RPO: 30 λεπτά
    • RTO: Μερικά δευτερόλεπτα
  • Ανάκτηση από StoreOnce backup appliance
    • RPO: 2 ώρες
    • RTO: μερικά λεπτά
  • Ανάκτηση από τις onsite κασέτες
    • RPO: 1 ημέρα
    • RTO: μερικές ώρες
  • Ανάκτηση από το Cloud backup
    • RPO: 1 ημέρα
    • RTO: μερικές ώρες
  • Ανάκτηση από offsite κασέτα
    • RPO: ~1 μήνας
    • RTO: πολλές ώρες μέχρι και 1-2 ημέρες

Όπως βλέπουμε όσο ποιο κοντά είναι τα δεδομένα στην κεντρική υποδομή τόσο μικρότερο RPO και RPO μπορούμε να έχουμε. Φυσικά στο συγκεκριμένο παράδειγμα έχουμε μια σχετικά μικρή υποδομή και ο όγκος των δεδομένων δεν είναι τεράστιος. Όσο αυξάνονται τα δεδομένα τόσο αυξάνεται το κόστος και ο χρόνος αποκατάστασης.

Σε αυτό το σημείο η κάθε εταιρεία πρέπει να έχει και την ανάλογη ιδέα για το τι πρέπει να συμβεί για να φτάσει στο κάθε επίπεδο αποκατάστασης. Για παράδειγμα, γιατί δεν μπορούμε να ανακτήσουμε από το storage μας? Γιατί δεν είναι πλέον στο πλάνο? Χάθηκε η συσκευή λόγο κυβερνοεπίθεσης ή χάθηκε όλο το κτήριο? Αν χάθηκε όλο το κτήριο τι κάνουμε?

Υπάρχει εφεδρική υποδομή για να συνεχίσουμε να δουλεύουμε?

Όπως βλέπετε η προστασία των δεδομένων μιας εταιρείας είναι μια διαρκής μάχη με πολλαπλά σενάρια, καλό σχεδιασμό και διατήρηση μιας ισορροπίας με το διαθέσιμο budget. Σίγουρα αν διαθέτεις αρκετά να πετάξεις σε αυτό το πρόβλημα τότε θα το λύσεις αλλά αυτό είναι ένα εξαιρετικά ουτοπικό και μη ρεαλιστικό σενάριο. Πρέπει όλα τα επίπεδα ένας οργανισμού να γνωρίζουν το πόσο θα κοστίσει ένα πιθανό downtime και τι μπορεί να συμβεί για να φτάσουμε σε αυτό το σημείο. Κάποτε μιλούσαμε για φυσικές καταστροφές όπου είναι ακόμα πιθανό να συμβούν αλλά έχουν εκθρονιστεί από τις κυβερνοεπιθέσεις. Ένας κακόβουλος εισβολέας είναι πολύ ποιο επικίνδυνος και έξυπνος από έναν σεισμό. Ένα καλό ransomware δεν θα κάνει εμφανή την παρουσία του αν πρώτα δεν διαγράψει όλα τα backups.

iGuRu.gr The Best Technology Site in Greecefgns

κάθε δημοσίευση, άμεσα στο inbox σας

Προστεθείτε στους 2.087 εγγεγραμμένους.
RPO,RTO

Written by guest

Guest Post: Είδα ανοιχτά και μπήκα!

Αφήστε μια απάντηση

Η ηλ. διεύθυνση σας δεν δημοσιεύεται. Τα υποχρεωτικά πεδία σημειώνονται με *

Το μήνυμα σας δεν θα δημοσιευτεί εάν:
1. Περιέχει υβριστικά, συκοφαντικά, ρατσιστικά, προσβλητικά ή ανάρμοστα σχόλια.
2. Προκαλεί βλάβη σε ανηλίκους.
3. Παρενοχλεί την ιδιωτική ζωή και τα ατομικά και κοινωνικά δικαιώματα άλλων χρηστών.
4. Διαφημίζει προϊόντα ή υπηρεσίες ή διαδικτυακούς τόπους .
5. Περιέχει προσωπικές πληροφορίες (διεύθυνση, τηλέφωνο κλπ).