Ακόμα κι αν είναι πλημμύρα, ο 1C θα πρέπει να λειτουργεί! Συμφωνούμε με την επιχείρηση για το DR

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

Η ιστορία που περιγράφεται δεν είναι μια φαντασία, αλλά μια συλλογική περιγραφή μερικών γεγονότων του 2020. Σε μεγάλες εταιρείες, ένα σχέδιο αποκατάστασης από καταστροφή ή σχέδιο αποκατάστασης καταστροφών (DRP) είναι πάντα διαθέσιμο για αυτήν την περίπτωση. Στις εταιρείες, αυτή είναι ευθύνη των ειδικών της επιχειρηματικής συνέχειας. Αλλά στις μεσαίες και μικρές εταιρείες, η επίλυση τέτοιων προβλημάτων εμπίπτει στις υπηρεσίες πληροφορικής. Πρέπει να κατανοήσετε μόνοι σας την επιχειρηματική λογική, να κατανοήσετε τι μπορεί να αποτύχει και πού, να βρείτε προστασία και να την εφαρμόσετε. 

Είναι υπέροχο εάν ένας ειδικός πληροφορικής μπορεί να διαπραγματευτεί με την επιχείρηση και να συζητήσει την ανάγκη προστασίας. Αλλά έχω δει περισσότερες από μία φορές πώς μια εταιρεία αγνοούσε μια λύση αποκατάστασης από καταστροφές (DR) επειδή τη θεώρησε περιττή. Όταν συνέβη ένα ατύχημα, μια μακρά ανάκαμψη απείλησε απώλειες και η επιχείρηση δεν ήταν έτοιμη. Μπορείτε να επαναλάβετε όσο θέλετε: "Σας το είπα", αλλά η υπηρεσία IT θα πρέπει να επαναφέρει τις υπηρεσίες.

Ακόμα κι αν είναι πλημμύρα, ο 1C θα πρέπει να λειτουργεί! Συμφωνούμε με την επιχείρηση για το DR

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

  • Τι προστατεύουμε;
  • Από τι προστατεύουμε;
  • Πόσο προστατεύουμε; 

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

Τι προστατεύουμε: εντοπισμός κρίσιμων επιχειρηματικών λειτουργιών 

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

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

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

Θα δομήσω τη συζήτηση ως εξής: 

  1. Εξηγούμε στις επιχειρήσεις ότι τα ατυχήματα συμβαίνουν σε όλους και η αποκατάσταση απαιτεί χρόνο. Το καλύτερο είναι να δείξετε καταστάσεις, πώς συμβαίνει αυτό και ποιες συνέπειες είναι δυνατές.
  2. Δείχνουμε ότι δεν εξαρτώνται τα πάντα από την υπηρεσία πληροφορικής, αλλά είστε έτοιμοι να βοηθήσετε με ένα σχέδιο δράσης στον τομέα της ευθύνης σας.
  3. Ζητάμε από τον επιχειρηματικό πελάτη να απαντήσει: εάν συμβεί η αποκάλυψη, ποια διαδικασία πρέπει να αποκατασταθεί πρώτα; Ποιοι συμμετέχουν σε αυτό και πώς; 

    Απαιτείται μια απλή απάντηση από την επιχείρηση, για παράδειγμα: το τηλεφωνικό κέντρο πρέπει να συνεχίσει την εγγραφή των αιτήσεων 24/7.

  4. Ζητάμε από έναν ή δύο χρήστες του συστήματος να περιγράψουν λεπτομερώς αυτή τη διαδικασία. 
    Είναι καλύτερα να συμμετάσχετε έναν αναλυτή για να βοηθήσει εάν η εταιρεία σας έχει έναν.

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

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

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

Από τι προστατεύουμε: κίνδυνοι

Στη συνέχεια, ανακαλύπτουμε από τον επιχειρηματικό πελάτη από ποιους κινδύνους προστατεύουμε πρώτα τους εαυτούς μας. Όλοι οι κίνδυνοι μπορούν να χωριστούν σε δύο ομάδες: 

  • απώλεια χρόνου λόγω διακοπής της υπηρεσίας.
  • απώλεια δεδομένων λόγω φυσικών επιπτώσεων, ανθρώπινων παραγόντων κ.λπ.

Οι επιχειρήσεις φοβούνται ότι θα χάσουν δεδομένα και χρόνο - όλα αυτά οδηγούν σε απώλεια χρημάτων. Έτσι και πάλι θέτουμε ερωτήσεις για κάθε ομάδα κινδύνου: 

  • Για αυτή τη διαδικασία, μπορούμε να υπολογίσουμε πόσο κοστίζει σε χρήμα η απώλεια δεδομένων και η απώλεια χρόνου; 
  • Ποια δεδομένα δεν μπορούμε να χάσουμε; 
  • Πού δεν μπορούμε να επιτρέψουμε διακοπή λειτουργίας; 
  • Ποια γεγονότα είναι πιο πιθανά και πιο απειλητικά για εμάς;

Μετά από συζήτηση, θα καταλάβουμε πώς να ιεραρχήσουμε τα σημεία αποτυχίας. 

Πόσο προστατεύουμε: RPO και RTO 

Όταν τα κρίσιμα σημεία αστοχίας είναι ξεκάθαρα, υπολογίζουμε τους δείκτες RTO και RPO. 

Θα σας υπενθυμίσω αυτό RTO (στόχος χρόνου αποκατάστασης) — αυτός είναι ο επιτρεπόμενος χρόνος από τη στιγμή του ατυχήματος μέχρι την πλήρη αποκατάσταση της υπηρεσίας. Στην επιχειρηματική γλώσσα, αυτό είναι αποδεκτό χρόνο διακοπής λειτουργίας. Εάν γνωρίζουμε πόσα χρήματα έφερε η διαδικασία, μπορούμε να υπολογίσουμε τις απώλειες από κάθε λεπτό διακοπής λειτουργίας και να υπολογίσουμε την αποδεκτή απώλεια. 

RPO (στόχος σημείου ανάκτησης) — έγκυρο σημείο ανάκτησης δεδομένων. Καθορίζει το χρόνο κατά τον οποίο μπορούμε να χάσουμε δεδομένα. Από επιχειρηματική άποψη, η απώλεια δεδομένων μπορεί να οδηγήσει σε πρόστιμα, για παράδειγμα. Τέτοιες απώλειες μπορούν επίσης να μετατραπούν σε χρήματα. 

Ακόμα κι αν είναι πλημμύρα, ο 1C θα πρέπει να λειτουργεί! Συμφωνούμε με την επιχείρηση για το DR

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

Ας δούμε ένα συγκεκριμένο παράδειγμα. Ο χρήστης συνδέεται στο 1C, το σύστημα ανοίγει με σφάλμα βάσης δεδομένων. Επικοινωνεί με τον διαχειριστή του συστήματος. Η βάση δεδομένων βρίσκεται στο cloud, ο διαχειριστής του συστήματος αναφέρει το πρόβλημα στον πάροχο υπηρεσιών. Ας υποθέσουμε ότι όλες οι επικοινωνίες διαρκούν 15 λεπτά. Στο cloud, μια βάση δεδομένων αυτού του μεγέθους θα αποκατασταθεί από ένα αντίγραφο ασφαλείας σε μια ώρα, επομένως, το RTO στην πλευρά του παρόχου υπηρεσιών είναι μία ώρα. Αλλά αυτή δεν είναι η τελική προθεσμία· για τον χρήστη, έχουν προστεθεί 15 λεπτά για να εντοπίσει το πρόβλημα. 
 
Στη συνέχεια, ο διαχειριστής του συστήματος πρέπει να ελέγξει ότι η βάση δεδομένων είναι σωστή, να τη συνδέσει στο 1C και να ξεκινήσει τις υπηρεσίες. Αυτό απαιτεί άλλη μια ώρα, πράγμα που σημαίνει ότι το RTO από την πλευρά του διαχειριστή είναι ήδη 2 ώρες και 15 λεπτά. Ο χρήστης χρειάζεται άλλα 15 λεπτά: συνδεθείτε, ελέγξτε ότι έχουν εμφανιστεί οι απαραίτητες συναλλαγές. 2 ώρες και 30 λεπτά είναι ο συνολικός χρόνος ανάκτησης της υπηρεσίας σε αυτό το παράδειγμα.

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

Πώς προστατεύουμε: επιλογή εργαλείων για διαφορετικούς κινδύνους

Αφού συζητήσει όλα τα σημεία, ο πελάτης έχει ήδη καταλάβει το κόστος ενός ατυχήματος για την επιχείρηση. Τώρα μπορείτε να επιλέξετε εργαλεία και να συζητήσετε τον προϋπολογισμό. Χρησιμοποιώντας παραδείγματα υποθέσεων πελατών, θα σας δείξω ποια εργαλεία προσφέρουμε για διαφορετικές εργασίες. 

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

  1. Φιλοξενήστε την εφαρμογή στο cloud 

    Αρχικά, μπορείτε απλώς να μετακινηθείτε στο cloud - ο πάροχος έχει ήδη σκεφτεί τα ζητήματα της υψηλής διαθεσιμότητας. Οι κεντρικοί υπολογιστές εικονικοποίησης συναρμολογούνται σε ένα σύμπλεγμα, η ισχύς και το δίκτυο δεσμεύονται, τα δεδομένα αποθηκεύονται σε συστήματα αποθήκευσης με ανοχή σε σφάλματα και ο πάροχος υπηρεσιών είναι οικονομικά υπεύθυνος για το χρόνο διακοπής λειτουργίας.

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

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

  2. Ομαδοποιήστε την εφαρμογή  

    Εάν θέλετε να βελτιώσετε το RTO, μπορείτε να ενισχύσετε την προηγούμενη επιλογή και να τοποθετήσετε αμέσως μια εφαρμογή συμπλέγματος στο cloud.

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

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

    Από την πρακτική: Η εταιρεία λιανικής διέθετε πολλά πληροφοριακά συστήματα και ιστοσελίδες. Όλες οι βάσεις δεδομένων βρίσκονταν τοπικά στο γραφείο της εταιρείας. Κανένα DR δεν σκεφτόταν μέχρι που το γραφείο έμεινε χωρίς ρεύμα πολλές φορές στη σειρά. Οι πελάτες ήταν δυσαρεστημένοι με τα σφάλματα ιστότοπου. 
     
    Το πρόβλημα με τη διαθεσιμότητα της υπηρεσίας επιλύθηκε μετά τη μετάβαση στο cloud. Επιπλέον, καταφέραμε να βελτιστοποιήσουμε το φορτίο στις βάσεις δεδομένων εξισορροπώντας την κίνηση μεταξύ των κόμβων.

  3. Μεταβείτε σε ένα σύννεφο ανθεκτικό στις καταστροφές

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

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

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

    • Ένα νέφος ανεκτικό σε καταστροφές προστατεύει την εφαρμογή από αστοχίες σε επίπεδο υποδομής. 
    • Η δημιουργία αντιγράφων ασφαλείας δύο επιπέδων παρέχει προστασία σε περίπτωση ανθρώπινου λάθους. Υπάρχουν δύο τύποι αντιγράφων ασφαλείας: "κρύο" και "ζεστό". Ένα "κρύο" αντίγραφο ασφαλείας βρίσκεται σε κατάσταση απενεργοποιημένης και χρειάζεται χρόνο για να αναπτυχθεί. Ένα «καυτό» αντίγραφο ασφαλείας είναι ήδη έτοιμο για χρήση και αποκαθίσταται πιο γρήγορα. Αποθηκεύεται σε ένα ειδικά αποκλειστικό σύστημα αποθήκευσης. Το τρίτο αντίγραφο εγγράφεται σε κασέτα και αποθηκεύεται σε άλλο δωμάτιο. 

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

  4. Οργανώστε την αναπαραγωγή σε άλλη τοποθεσία 

    Μια άλλη επιλογή για το πώς να αποφύγετε παγκόσμια προβλήματα στον κύριο ιστότοπο: παρέχετε γεωγραφική κράτηση. Με άλλα λόγια, δημιουργήστε εφεδρικές εικονικές μηχανές σε έναν ιστότοπο σε άλλη πόλη. Ειδικές λύσεις για DR είναι κατάλληλες για αυτό: στην εταιρεία μας χρησιμοποιούμε VMware vCloud Availability (vCAV). Με τη βοήθειά του, μπορείτε να διαμορφώσετε την προστασία μεταξύ πολλών τοποθεσιών παροχής cloud ή να κάνετε επαναφορά στο cloud από έναν ιστότοπο εσωτερικής εγκατάστασης. Έχω ήδη μιλήσει με περισσότερες λεπτομέρειες για το σχέδιο εργασίας με vCAV εδώ

    RPO και RTO: από 5 λεπτά. 

    Κόστος: πιο ακριβό από την πρώτη επιλογή, αλλά φθηνότερο από την αναπαραγωγή υλικού σε ένα σύννεφο ανθεκτικό σε καταστροφές. Η τιμή αποτελείται από το κόστος μιας άδειας vCAV, τα τέλη διαχείρισης, το κόστος των πόρων cloud και τους αποθεματικούς πόρους σύμφωνα με το μοντέλο PAYG (10% του κόστους των πόρων εργασίας για απενεργοποιημένα VM).

    Από την πρακτική: Ο πελάτης διατήρησε 6 εικονικές μηχανές με διαφορετικές βάσεις δεδομένων στο cloud μας στη Μόσχα. Αρχικά, η προστασία παρεχόταν μέσω δημιουργίας αντιγράφων ασφαλείας: μερικά από τα αντίγραφα ασφαλείας αποθηκεύτηκαν στο cloud στη Μόσχα και μερικά αποθηκεύτηκαν στον ιστότοπό μας στην Αγία Πετρούπολη. Με τον καιρό, οι βάσεις δεδομένων μεγάλωσαν σε μέγεθος και η επαναφορά από ένα αντίγραφο ασφαλείας άρχισε να απαιτεί περισσότερο χρόνο. 
     
    Η αναπαραγωγή με βάση τη διαθεσιμότητα vCloud VMware προστέθηκε στα αντίγραφα ασφαλείας. Αντίγραφα εικονικών μηχανών αποθηκεύονται σε έναν ιστότοπο ασφαλείας στην Αγία Πετρούπολη και ενημερώνονται κάθε 5 λεπτά. Εάν παρουσιαστεί μια αποτυχία στην κύρια τοποθεσία, οι εργαζόμενοι μεταβαίνουν ανεξάρτητα σε ένα αντίγραφο της εικονικής μηχανής στην Αγία Πετρούπολη και συνεχίζουν να εργάζονται μαζί της. 

Όλες οι εξεταζόμενες λύσεις παρέχουν υψηλή διαθεσιμότητα, αλλά δεν προστατεύουν από απώλεια δεδομένων λόγω ιού ransomware ή τυχαίου σφάλματος υπαλλήλου. Σε αυτήν την περίπτωση, θα χρειαστούμε αντίγραφα ασφαλείας που θα παρέχουν το απαιτούμενο RPO.

5. Μην ξεχνάτε τη δημιουργία αντιγράφων ασφαλείας

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

Αυστηρά μιλώντας, το backup δεν είναι DR. Και για αυτο: 

  • Είναι πολύς καιρός. Εάν τα δεδομένα μετρηθούν σε terabyte, η ανάκτηση θα διαρκέσει περισσότερο από μία ώρα. Πρέπει να κάνετε επαναφορά, να αντιστοιχίσετε ένα δίκτυο, να ελέγξετε ότι ενεργοποιείται, να δείτε ότι τα δεδομένα είναι σε τάξη. Έτσι, μπορείτε να παρέχετε ένα καλό RTO μόνο εάν υπάρχουν λίγα δεδομένα. 
  • Τα δεδομένα ενδέχεται να μην αποκατασταθούν την πρώτη φορά και πρέπει να αφήσετε χρόνο για την επανάληψη της ενέργειας. Για παράδειγμα, υπάρχουν φορές που δεν γνωρίζουμε πότε ακριβώς χάθηκαν τα δεδομένα. Ας πούμε ότι η απώλεια έγινε αντιληπτή στις 15.00, και αντίγραφα γίνονται κάθε ώρα. Από τις 15.00 κοιτάμε όλα τα σημεία αποθεραπείας: 14:00, 13:00 κ.ο.κ. Εάν το σύστημα είναι σημαντικό, προσπαθούμε να ελαχιστοποιήσουμε την ηλικία του σημείου ανάκτησης. Αλλά εάν το νέο αντίγραφο ασφαλείας δεν περιείχε τα απαραίτητα δεδομένα, παίρνουμε το επόμενο σημείο - αυτός είναι επιπλέον χρόνος. 

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

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

  • Μία από τις επιλογές 1-4, η οποία θα προστατεύει τα συστήματα από βλάβες και πτώσεις.
  • Δημιουργία αντιγράφων ασφαλείας για προστασία δεδομένων από απώλεια. 

Αξίζει επίσης να φροντίσετε για ένα εφεδρικό κανάλι επικοινωνίας σε περίπτωση που ο κύριος πάροχος Διαδικτύου πέσει. Και - voila! — Το DR με ελάχιστους μισθούς είναι ήδη έτοιμο. 

Πηγή: www.habr.com

Προσθέστε ένα σχόλιο