Το Capacity Tier (ή όπως το αποκαλούμε μέσα στο Vim - captir) εμφανίστηκε την εποχή του Veeam Backup and Replication 9.5 Update 4 με το όνομα Archive Tier. Η ιδέα πίσω από αυτό είναι να καταστεί δυνατή η μετακίνηση αντιγράφων ασφαλείας που έχουν πέσει έξω από το λεγόμενο παράθυρο λειτουργικής επαναφοράς στην αποθήκευση αντικειμένων. Αυτό βοήθησε στην εκκαθάριση του χώρου στο δίσκο για εκείνους τους χρήστες που είχαν λίγο από αυτόν. Και αυτή η επιλογή ονομάστηκε Move Mode.

Για να εκτελέσετε αυτήν την απλή (όπως φαίνεται) ενέργεια, αρκούσε να πληρούνται δύο προϋποθέσεις: όλα τα σημεία από το μετακινούμενο αντίγραφο ασφαλείας πρέπει να βρίσκονται εκτός των ορίων του προαναφερθέντος παραθύρου λειτουργικής επαναφοράς, το οποίο ορίζεται ρητά στη διεπαφή χρήστη. Και δεύτερο: η αλυσίδα πρέπει να είναι στη λεγόμενη «σφραγισμένη μορφή» (σφραγισμένη εφεδρική αλυσίδα ή Ανενεργή εφεδρική αλυσίδα). Δηλαδή, δεν συμβαίνουν αλλαγές σε αυτή την αλυσίδα με την πάροδο του χρόνου.

Αλλά στο VBR v10, η ιδέα συμπληρώθηκε με νέες λειτουργίες - Copy Mode, Sealed Mode και εμφανίστηκε ένα πράγμα με το δύσκολο στην προφορά όνομα Immutability.

Αυτά είναι τα συναρπαστικά πράγματα για τα οποία θα μιλήσουμε σήμερα. Πρώτα, για το πώς λειτούργησε στο VBR9.5u4 και μετά για τις αλλαγές στη δέκατη έκδοση.

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

• Χωρίς την παραμικρή λύπη. Συντάκτης του άρθρου.

Οπως ήταν

Λοιπόν, ας ξεκινήσουμε αναλύοντας το παράθυρο λειτουργικής επαναφοράς και το σφραγισμένο αντίγραφο ασφαλείας (ή όπως ονομάζονται στην τεκμηρίωση Inactive Backup Chain). Χωρίς την κατανόησή τους, περαιτέρω εξήγηση δεν θα είναι δυνατή.

Όπως βλέπουμε στην εικόνα, έχουμε ένα είδος εφεδρικής αλυσίδας με μπλοκ δεδομένων, που βρίσκεται στο Performance tier SOBR του αποθετηρίου στο οποίο είναι συνδεδεμένο το Capacity Tier. Το λειτουργικό μας εφεδρικό παράθυρο είναι τρεις ημέρες.

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

Τι ακριβώς εννοούσε όμως η σφραγισμένη αλυσίδα και τι θα μπορούσε να σταλεί στο πεδίο βολής χωρητικότητας στην ενημέρωση 4;

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

Στην περίπτωση του Reverse, όλα αυτά είναι αρχεία που δεν εμπίπτουν στο παράθυρο λειτουργίας.

Στην περίπτωση της αύξησης προς τα εμπρός με επαναλήψεις, όλες αυτές είναι επαναλήψεις και .vbk, εάν υπάρχει άλλο .vbk στην έκταση απόδοσης

Τώρα ας εξετάσουμε την επιλογή της εργασίας με αλυσίδες αντιγράφων ασφαλείας. Μόνο τα αντικείμενα που εμπίπτουν στη διατήρηση GFS μεταφέρθηκαν εδώ. Επειδή όλα όσα είναι αποθηκευμένα σε πιο πρόσφατες αλυσίδες αντιγράφων ασφαλείας μπορούν να αλλάξουν με τον ένα ή τον άλλο τρόπο.

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

Ας δούμε πώς μοιάζει με ένα παράδειγμα: Ας υποθέσουμε ότι έχουμε ένα .vbk που βγήκε από το παράθυρο συναλλαγής και ανήκει σε μια σφραγισμένη αλυσίδα. Αυτό σημαίνει ότι έχουμε κάθε δικαίωμα να το μεταφέρουμε στο πεδίο βολής χωρητικότητας. Κατά τη μετακίνηση, δημιουργείται ένα αρχείο μεταδεδομένων στην παύλα χωρητικότητας και τα μπλοκ του μεταφερόμενου αρχείου. Το αρχείο μεταδεδομένων σε επίπεδο συνδέσμου περιγράφει από τι μπλοκ αποτελείται το αρχείο μας. Στην περίπτωση της εικόνας, το πρώτο μας αρχείο αποτελείται από μπλοκ a, b, c και τα μεταδεδομένα περιέχουν συνδέσμους προς αυτά τα μπλοκ. Όταν έχουμε ένα δεύτερο αρχείο .vbk, έτοιμο για κίνηση και που αποτελείται από μπλοκ a, b και d, αναλύοντας τον δείκτη αφυδάτωσης, καταλαβαίνουμε ότι μόνο το μπλοκ d χρειάζεται να μεταφερθεί. Και το αρχείο μεταδεδομένων του θα περιέχει συνδέσμους προς δύο προηγούμενα μπλοκ και ένα νέο.

Κατά συνέπεια, η διαδικασία πλήρωσης αυτών των κενών χώρων με δεδομένα ονομάζεται επανυδάτωση. Χρησιμοποιεί ήδη το δικό του ευρετήριο επανυδάτωσης, με βάση το παλαιότερο αρχείο .vbk στην τοπική έκταση απόδοσης. Δηλαδή, εάν ο χρήστης θέλει να επιστρέψει ένα αρχείο από το πεδίο βολής χωρητικότητας, δημιουργούμε πρώτα ένα ευρετήριο των μπλοκ του παλαιότερου πλήρους αντιγράφου ασφαλείας και μεταφέρουμε μόνο τα μπλοκ που λείπουν από τη γκαλερί βολής χωρητικότητας. Στην περίπτωση που παρουσιάζεται στην εικόνα, για να επανυδατωθεί το FullBackup1.vbk σύμφωνα με τον δείκτη επανυδάτωσης, χρειαζόμαστε μόνο το μπλοκ C, το οποίο παίρνουμε από το πεδίο βολής χωρητικότητας. Εάν ένα αντικείμενο αποθήκευσης cloud χρησιμεύει ως πεδίο βολής χωρητικότητας, αυτό σας επιτρέπει να εξοικονομήσετε τεράστια χρηματικά ποσά.

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

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

Πώς έγινε

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

Λειτουργία αντιγραφής

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

Ο σκοπός αυτής της λειτουργίας είναι να διασφαλίσει ότι όλα τα δεδομένα που βρίσκονται στην τοπική έκταση έχουν ένα αντίγραφο στην παύλα χωρητικότητας.

Εάν συγκρίνετε τις λειτουργίες Μετακίνηση και Αντιγραφή κατά μέτωπο, θα μοιάζει με αυτό:

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

Κατά την εξέταση του νέου τρόπου λειτουργίας, προτείνω να περάσουμε από απλά παραδείγματα σε σύνθετα.

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

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

Τίθεται το ερώτημα - αν κοιτάξετε το UI, υπάρχει η ευκαιρία να επιλέξετε και τις δύο επιλογές ταυτόχρονα. Πώς θα λειτουργήσει μια τέτοια συνδυασμένη λειτουργία;

Ας καταλάβουμε.

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

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

Γιατί χρειαζόμαστε αυτήν τη λειτουργία αντιγραφής;

Είναι ακόμη καλύτερο να επαναδιατυπώσουμε την ερώτηση ως εξής: από ποιους κινδύνους προστατευόμαστε με τη βοήθειά του; Ποιο πρόβλημα μας βοηθά να λύσουμε;

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

Ας δούμε λοιπόν τα πιθανά σενάρια, από τα πιο απλά έως τα πιο σύνθετα.

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

Μια πιο θλιβερή ιστορία είναι ότι μια από τις εκτάσεις του αποθετηρίου SOBR μας έσπασε.

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

Τώρα ας δούμε κάθε κατάσταση ξεχωριστά.

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

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

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

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

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

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

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

Αυτό μάλλον αφορά τη λειτουργία αντιγραφής και προχωράμε

Σφραγισμένη λειτουργία

Η κύρια ιδέα είναι ότι νέα αντίγραφα ασφαλείας δεν μπορούν να εμφανιστούν στην επιλεγμένη έκταση SOBR του αποθετηρίου. Πριν από την έκδοση 10, είχαμε μόνο Maintenance Mode, όταν οποιαδήποτε εργασία με το αποθετήριο ήταν εντελώς απαγορευμένη. Ένα είδος hardcore mode για τον τερματισμό της αποθήκευσης, όπου είναι διαθέσιμο μόνο το κουμπί Evacuate, το οποίο μεταφέρει εφάπαξ εφεδρικά αντίγραφα σε άλλο βαθμό.

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

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

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

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

Υπάρχουν περιπτώσεις όπου η διαγραφή συμβαίνει νωρίτερα. Για παράδειγμα, αυτό είναι το Forward incremental με περιοδικές πληρωμές. Εάν δημιουργήσαμε πλήρη αντίγραφα ασφαλείας για τις δύο πρώτες ημέρες και την Πέμπτη αποφασίσουμε να σφραγίσουμε το αποθετήριο, τότε την Παρασκευή, όταν δημιουργηθεί ένα νέο αντίγραφο ασφαλείας, το αρχείο για τη Δευτέρα θα διαγραφεί επειδή δεν υπάρχουν εξαρτήσεις σε αυτό το σημείο. Και το ίδιο το σημείο δεν εξαρτάται από κανέναν. Στη συνέχεια περιμένουμε να δημιουργηθούν τέσσερα σημεία στη διαθέσιμη έκταση και διαγράφουμε τα υπόλοιπα τρία, τα οποία δεν μπορούν να διαγραφούν ανεξάρτητα το ένα από το άλλο.

Τα πράγματα είναι πιο απλά με το Reverse Incremental. Σε αυτό, τα παλαιότερα σημεία δεν εξαρτώνται από τίποτα και μπορούν να διαγραφούν με ασφάλεια. Επομένως, μόλις δημιουργηθεί ένα νέο .vbk σε νέα έκταση, τα παλιά .vrbs θα διαγράφονται ένα προς ένα.

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

Τα πράγματα είναι πιο περίπλοκα με το πεδίο βολής χωρητικότητας.

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

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

Ένα ενδιαφέρον παράδειγμα με το Forever Forever incremental. Εγκαθιστούμε τη διατήρηση σε τρία σημεία και ξεκινάμε τη δημιουργία αντιγράφων ασφαλείας τη Δευτέρα, τα οποία αντιγράφονται τακτικά στο cloud. Μετά τη σφράγιση του χώρου αποθήκευσης, συνεχίζουν να δημιουργούνται αντίγραφα ασφαλείας, διατηρώντας τρία σημεία, αλλά τα δεδομένα που είναι αποθηκευμένα στην παύλα χωρητικότητας παραμένουν εξαρτημένα και δεν μπορούν να διαγραφούν. Επομένως, περιμένουμε μέχρι την Πέμπτη, όταν το .vbk μας υπερβαίνει τη διατήρηση και μόνο τότε διαγράφουμε ήρεμα ολόκληρη την αποθηκευμένη αλυσίδα.

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

Αυτό είναι βασικά το μόνο που υπάρχει σε αυτό. Ας προχωρήσουμε λοιπόν στο πιο σκληροπυρηνικό χαρακτηριστικό -

Αμετάβλητο

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

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

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

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

Τώρα είναι η κατάλληλη στιγμή να εξηγήσουμε την τεχνολογία παραγωγής μπλοκ. Ή δημιουργία μπλοκ. Για να το κάνετε αυτό, εξετάστε την κατάσταση που οδήγησε στην εμφάνισή του.

Ας πάρουμε μια χρονική κλίμακα έξι ημερών και παρακάτω θα σημειώσουμε τον χρόνο της αναμενόμενης λήξης του αμετάβλητου. Την πρώτη μέρα παίρνουμε και δημιουργούμε ένα αρχείο που αποτελείται από το μπλοκ δεδομένων a και τα μεταδεδομένα του. Εάν το αμετάβλητο οριστεί σε τρεις ημέρες, είναι λογικό να υποθέσουμε ότι την τέταρτη ημέρα τα δεδομένα θα ξεκλειδωθούν και θα διαγραφούν. Τη δεύτερη μέρα θα προσθέσουμε ένα νέο αρχείο2, που αποτελείται από το μπλοκ b με τις ίδιες ρυθμίσεις. Το μπλοκ α πρέπει να αφαιρεθεί την τέταρτη ημέρα. Αλλά την τρίτη μέρα συμβαίνει κάτι τρομερό - δημιουργείται ένα αρχείο File3, που αποτελείται από ένα νέο μπλοκ d και έναν σύνδεσμο προς το παλιό μπλοκ a. Αυτό σημαίνει ότι για ένα μπλοκ και η σημαία του αμετάβλητου πρέπει να επαναφερθεί σε μια νέα ημερομηνία, η οποία μετατοπίζεται στην έκτη ημέρα. Και εδώ προκύπτει ένα πρόβλημα - σε πραγματικά αντίγραφα ασφαλείας υπάρχει ένας τεράστιος αριθμός τέτοιων μπλοκ. Και για να επεκτείνετε την περίοδο αμετάβλητου τους, πρέπει να κάνετε έναν τεράστιο αριθμό αιτημάτων κάθε φορά. Και στην πραγματικότητα, αυτή θα είναι μια σχεδόν ατελείωτη καθημερινή διαδικασία, αφού με μεγάλο βαθμό πιθανότητας θα βρούμε βαριές στοίβες από μπλοκ που έχουν αφαιρεθεί διπλότυπα με κάθε αντίγραφο. Τι σημαίνει μεγάλος αριθμός αιτημάτων από παρόχους αποθήκευσης αντικειμένων; Σωστά! Τεράστιος λογαριασμός στο τέλος του μήνα.

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

Ας συνεχίσουμε να εξετάζουμε την ίδια κατάσταση, αλλά με τη δημιουργία μπλοκ. Την πρώτη μέρα δημιουργούμε το αρχείο1 από το μπλοκ α και τα μεταδεδομένα. Προσθέτουμε την περίοδο δημιουργίας και το αμετάβλητο - αυτό σημαίνει ότι η ευκαιρία διαγραφής του αρχείου θα είναι την έκτη ημέρα. Αν τη δεύτερη μέρα δημιουργήσουμε το File2, που αποτελείται από το μπλοκ b και έναν σύνδεσμο προς το μπλοκ a, τότε δεν συμβαίνει τίποτα στην αναμενόμενη ημερομηνία διαγραφής. Στάθηκε όπως έκανε την έκτη μέρα. Και έτσι προσπαθούμε να εξοικονομήσουμε χρήματα στον αριθμό των αιτημάτων. Η μόνη περίπτωση κατά την οποία μπορεί να μετατεθεί η προθεσμία είναι εάν έχει λήξει η περίοδος παραγωγής. Δηλαδή, εάν την τρίτη ημέρα το νέο Αρχείο3 περιέχει έναν σύνδεσμο για να μπλοκάρει το α, τότε η γενιά 2 θα προστεθεί αφού το Gen1 έχει ήδη λήξει. Και η αναμενόμενη ημερομηνία για τη διαγραφή του μπλοκ α θα μετατοπιστεί στην όγδοη ημέρα. Αυτό μας επιτρέπει να μειώσουμε δραματικά τον αριθμό των αιτημάτων για παράταση της διάρκειας ζωής των αποκλεισμένων μπλοκ, γεγονός που εξοικονομεί έναν τόνο χρημάτων στους πελάτες.

Η ίδια η τεχνολογία είναι διαθέσιμη σε χρήστες υλικού συμβατού με S3 και S3, των οποίων οι κατασκευαστές εγγυώνται ότι η υλοποίησή τους δεν διαφέρει από αυτή της Amazon. Εξ ου και η απάντηση στο εύλογο ερώτημα γιατί το Azure δεν υποστηρίζεται - έχουν παρόμοιο χαρακτηριστικό, αλλά λειτουργεί σε επίπεδο κοντέινερ και όχι μεμονωμένων αντικειμένων. Παρεμπιπτόντως, η ίδια η Amazon έχει κλείδωμα αντικειμένων σε δύο τρόπους: συμμόρφωση και διακυβέρνηση. Στη δεύτερη περίπτωση, υπάρχει η πιθανότητα ο μεγαλύτερος διαχειριστής πάνω από τους διαχειριστές και ο root πάνω από τις ρίζες, παρά το κλείδωμα αντικειμένου, εξακολουθεί να διαγράφει τα δεδομένα. Στην περίπτωση της συμμόρφωσης, όλα είναι καλά καρφωμένα και κανείς δεν μπορεί να διαγράψει τα αντίγραφα ασφαλείας. Ακόμη και οι διαχειριστές της Amazon (σύμφωνα με τις επίσημες δηλώσεις τους). Αυτή είναι η λειτουργία που υποστηρίζουμε.

Και, ως συνήθως, μερικοί χρήσιμοι σύνδεσμοι:

• επί Δημιουργία μπλοκ με κάθε λεπτομέρεια.
• Όλες οι πληροφορίες για Veeam Backup & Replication 10 στα καλύτερά του
• О Βαθμίδα χωρητικότητας λεπτομερώς

Πηγή: www.habr.com