Δημιουργία αυτόματου αντιγράφου ασφαλείας της βάσης δεδομένων SQL στον διακομιστή SQL Express Edition. Κατανόηση βοηθητικών προγραμμάτων για δημιουργία αντιγράφων ασφαλείας βάσης δεδομένων Αντιγραφή δεδομένων sql

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

Για να μάθετε πότε δημιουργήθηκαν αντίγραφα ασφαλείας μιας συγκεκριμένης βάσης δεδομένων, καθώς και πότε έγινε επαναφορά της βάσης δεδομένων από ένα αντίγραφο ασφαλείας, μπορείτε να χρησιμοποιήσετε την τυπική αναφορά " » (Δημιουργία αντιγράφων ασφαλείας και επαναφορά συμβάντων). Για να δημιουργήσετε αυτήν την αναφορά, πρέπει να κάνετε δεξί κλικ στην αντίστοιχη βάση δεδομένων στο Object Browser (Αποτελέσματα διακομιστή) και να επιλέξετε « Αναφορές" (Αναφορές) - " Τυπική αναφορά" (Τυπικές αναφορές) - " Δημιουργία αντιγράφων ασφαλείας και επαναφορά συμβάντων» (Δημιουργία αντιγράφων ασφαλείας και επαναφορά συμβάντων).

Η αναφορά που δημιουργήθηκε περιέχει τα ακόλουθα δεδομένα:

• Μέσος χρόνος που απαιτείται για τις λειτουργίες δημιουργίας αντιγράφων ασφαλείας
• Επιτυχείς λειτουργίες δημιουργίας αντιγράφων ασφαλείας
• Σφάλματα λειτουργίας δημιουργίας αντιγράφων ασφαλείας
• Επιτυχείς λειτουργίες επαναφοράς

Για να προβάλετε αυτές τις πληροφορίες, πρέπει να αναπτύξετε την αντίστοιχη ομαδοποίηση στην αναφορά.

Σας βοήθησε αυτό το άρθρο;

Αυτό το άρθρο θα σας πει πώς να δημιουργήσετε με μη αυτόματο τρόπο ένα πλήρες αντίγραφο ασφαλείας της βάσης δεδομένων χρησιμοποιώντας το πρόγραμμα Microsoft SQL Server Management Studio.

1. Δημιουργήστε ένα αντίγραφο ασφαλείας

Στην πραγματικότητα είναι πολύ απλό. Εκκινήστε τον εξοπλισμό" » (« Αρχή» — « Ολα τα προγράμματα» — « SQL Server 2008 R2» — « Microsoft SQL Server Management Studio") και εισαγάγετε τα στοιχεία σύνδεσής σας.

Στη συνέχεια, στο Object Browser ανοίξτε την καρτέλα " Βάση δεδομένων» και κάντε δεξί κλικ στη βάση δεδομένων για την οποία πρέπει να δημιουργήσετε αντίγραφο ασφαλείας. Στο μενού περιβάλλοντος που εμφανίζεται, επιλέξτε « Καθήκοντα» ( Καθήκοντα) — « Δημιουργήστε ένα αντίγραφο ασφαλείας» ( Αντιγράφων ασφαλείας…) .

Το παράθυρο " Αντίγραφο ασφαλείας βάσης δεδομένων» ( Δημιουργία αντιγράφων ασφαλείας της βάσης δεδομένων) . Ας βεβαιωθούμε ότι αξίζει» Γεμάτος» ( Γεμάτος), εάν είναι απαραίτητο, ορίστε ένα όνομα και περιγραφή και υποδείξτε επίσης τον σκοπό του αντιγράφου ασφαλείας. Από προεπιλογή, είναι επιλεγμένη η διαδρομή στον σκληρό δίσκο του υπολογιστή προς το φάκελο Backup της κύριας θέσης των βάσεων δεδομένων του διακομιστή SQL. Για να αλλάξετε τη θέση του αντιγράφου, κάντε πρώτα κλικ στο " Διαγράφω» ( Αφαιρώ) για να διαγράψετε μια υπάρχουσα ανάθεση και, στη συνέχεια, " Προσθήκη» ( Προσθήκη...) για να προσθέσετε ένα νέο.

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

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

2. Επαναφορά μιας βάσης δεδομένων από ένα αντίγραφο ασφαλείας

Η ανάκαμψη ακολουθεί ένα παρόμοιο μοτίβο. ΣΕ " Περιβάλλον Microsoft SQL Server Management Studio» επιλέξτε μια βάση από το οποίο γίνεται το αντίγραφο ασφαλείας, κάντε δεξί κλικ πάνω του, επιλέξτε « Καθήκοντα» ( Καθήκοντα) — « Επαναφέρω» ( Επαναφέρω) — « Βάση δεδομένων…» ( Βάση δεδομένων…).

Το παράθυρο " Ανάκτηση βάσης δεδομένων» ( Επαναφορά βάσης δεδομένων). Εδώ, ως πηγή, αναφέρουμε « Από συσκευή» ( Από συσκευή) και επιλέξτε το αρχείο αντιγράφου ασφαλείας (που δημιουργήθηκε στο βήμα 1).

Ορίστε τη σημαία" Επαναφέρω» ( Επαναφέρω) δίπλα στο επιλεγμένο αντίγραφο ασφαλείας. Εάν είναι απαραίτητο, στο " Επιλογές» ( Επιλογές), μπορείτε να καθορίσετε πρόσθετες παραμέτρους ανάκτησης, η σημασία των οποίων μπορεί να διαβαστεί.

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

3. Επαναφορά αντιγράφου ασφαλείας σε άλλη βάση δεδομένων (αντιγραφή δεδομένων)

Εάν χρειάζεται να φορτώσετε δεδομένα στη βάση δεδομένων, διαφορετικό από αυτό από το οποίο έγινε το αντίγραφο ασφαλείας, τότε κατά τη φόρτωση, εκτός από τις ενέργειες που περιγράφονται στην παράγραφο 2, είναι απαραίτητο στο « Επιλογές" (Επιλογές) ορίστε τα ονόματα αρχείων αυτής της βάσης δεδομένων και ορίστε τη σημαία " Αντικαταστήστε την υπάρχουσα βάση δεδομένων"(ΜΕ ΑΝΤΙΚΑΤΑΣΤΑΣΗ).

Σας βοήθησε αυτό το άρθρο;

Ας εξετάσουμε μια ανεπιθύμητη κατάσταση. Δηλαδή: για κάποιο λόγο η βάση δεδομένων απέτυχε. Τι έχουμε; Ένα πλήρες αντίγραφο, ένα διαφορικό αντίγραφο για χθες, αλλά υπάρχουν και δεδομένα για το σήμερα, ήταν πραγματικά απαραίτητο να γίνεται ένα διαφορικό αντίγραφο κάθε ώρα; - Οχι! Τρώω ημερολόγιο συναλλαγών.
Αρχείο καταγραφής συναλλαγών - Ένα αρχείο καταγραφής που καταγράφει όλες τις συναλλαγές και όλες τις αλλαγές της βάσης δεδομένων που πραγματοποιούνται από κάθε συναλλαγή. Εκείνοι. οποιαδήποτε ενέργεια με τη βάση δεδομένων καταγράφεται βήμα προς βήμα στο αρχείο καταγραφής. Κάθε εγγραφή επισημαίνεται από το DBMS για να καθορίσει εάν η συναλλαγή έχει ολοκληρωθεί, εάν έχει ολοκληρωθεί ή όχι. Με τη βοήθειά του, μπορείτε να επαναφέρετε την κατάσταση της βάσης δεδομένων όχι μόνο μετά από αποτυχία, αλλά και σε περίπτωση απροσδόκητων ενεργειών με δεδομένα. Επιστρέψτε σε μια συγκεκριμένη ώρα. Όπως και με τη βάση δεδομένων, το αρχείο καταγραφής συναλλαγών πρέπει να δημιουργεί αντίγραφα ασφαλείας, πλήρες, διαφορικό, αυξητικό. Για να επαναφέρετε μέρος του αρχείου καταγραφής συναλλαγών μετά από μια αποτυχία στο διάστημα μεταξύ της δημιουργίας αντιγράφων ασφαλείας, πρέπει να δημιουργήσετε αντίγραφα ασφαλείας του τελικού τμήματος του αρχείου καταγραφής, το οποίο, στην πραγματικότητα, είναι το σημείο οριστικοποίησης του αντιγράφου ασφαλείας. Εκτελείται μετά από αποτυχία, ως σημείο αντίστροφης μέτρησης.
Έτσι, για να επαναφέρουμε μια βάση δεδομένων μετά από μια αποτυχία, χρειαζόμαστε ένα τρέχον πλήρες αντίγραφο της βάσης δεδομένων, ένα διαφορικό αντίγραφο της βάσης δεδομένων και ένα αντίγραφο του αρχείου καταγραφής συναλλαγών.

Υπάρχουν 3 μοντέλα ανάκτησης για την ίδια τη βάση δεδομένων - απλά, πλήρη και μαζικά καταγεγραμμένα. Σκεφτείτε:

1. Απλό μοντέλο - χρησιμοποιείται μόνο πλήρης πλεονασμός. Καμία διαφορά. αντίγραφα ασφαλείας, καθώς και αντίγραφα καταγραφής συναλλαγών. Τα πλήρη αντίγραφα πρέπει να δημιουργούνται όσο το δυνατόν συχνότερα. Σχετικό για βάσεις δεδομένων που χρησιμοποιούνται "μόνο για ανάγνωση".
2. Το μοντέλο πλήρους ανάκτησης είναι το μοντέλο που χρησιμοποιείται περισσότερο, στο οποίο είναι διαθέσιμες όλες οι λειτουργίες δημιουργίας αντιγράφων ασφαλείας και ανάκτησης δεδομένων. Υποστηρίζει την ανάκτηση μεμονωμένων σελίδων δεδομένων. Οι συναλλαγές καταγράφονται πλήρως και το αρχείο καταγραφής συναλλαγών αποθηκεύεται.
3. Το μοντέλο Bulk-Logged προορίζεται ως συμπλήρωμα του μοντέλου πλήρους ανάκτησης. Οι περισσότερες μαζικές λειτουργίες δεν υποστηρίζουν την καταγραφή και, κατά συνέπεια, δεν υποστηρίζει την ανάκτηση βάσης δεδομένων σε ένα συγκεκριμένο χρονικό σημείο.

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

• Χρησιμοποιώντας τον ενσωματωμένο προγραμματιστή εργασιών MS SQL
• Χρήση γλώσσας Transact-SQL
• Χρήση του sqlcmd και του OS Task Scheduler
• Χειροκίνητα (κάτι που δεν μας ταιριάζει, επειδή ένας διαχειριστής που εργάζεται πρέπει να τα βάζει συνεχώς)

Ας θεωρήσουμε την πρώτη επιλογή ως την πιο χρησιμοποιήσιμη. Για αυτό, χρησιμοποιούνται Windows Server 2008 R2 Enterprise και MS SQL Server 2008 Eng.

Λοιπόν, ας πούμε ότι έχουμε μια βάση δεδομένων TECH:

Ας προχωρήσουμε στο εργαλείο δημιουργίας θέσεων εργασίας:

Πατήστε το δεξί κουμπί του ποντικιού και καλέστε τον Master Joba:
Επιλέξτε το πλαίσιο ελέγχου "Εκτελέστε κάθε εργασία ξεχωριστά", εκτελούμε μόνο μία ενέργεια

Ο πλοίαρχος είναι χωρίς τουρμπάνι, αλλά το μέγεθος του τουρμπάνι δεν είναι το κύριο πράγμα)) Επιλέγουμε τον τύπο της επιθυμίας, στην περίπτωσή μας - πλήρη κράτηση:

Ο δάσκαλος Joba, όπως αποδεικνύεται, είναι λίγο Εβραίος, οπότε ρωτά ξανά:

"Αξίζει να επιλέξετε πρόσθετες παραμέτρους, ω νεαρό paddawan!":
Εδώ επιλέγουμε τη βάση δεδομένων, την περίοδο αποθήκευσης αντιγράφων ασφαλείας, τη διεύθυνση (κασέτα ή δίσκο), τη διαδρομή αποθήκευσης και το πιο σημαντικό - τον προγραμματιστή εργασιών!

"Δεν πρέπει να ξεχνάτε τη βάση δεδομένων όταν επιλέγετε τη δική σας Συγκεντρώστε τις δυνάμεις σας και επιλέξτε μια βάση δεδομένων":

"Βιάζεστε να δημιουργήσετε την εργασία πολύ γρήγορα, κάντε κλικ στο κουμπί στο κάτω μέρος με το όνομα Καθορισμός - Ορισμός."
Στην πραγματικότητα, ο προγραμματιστής εργασιών, όπου επιλέγουμε τον τύπο (επανάληψη, μία φορά κ.λπ.), ημέρα, ώρα, τύπο έναρξης:

Αυτό είναι, το δημιουργήσαμε. Ο Master Joba είναι δροσερός και πράσινος. Εξετάζουμε την κατάσταση στα Σχέδια Συντήρησης:

Για τους παρανοϊκούς, μην φοβάστε να το παραδεχτείτε στον καθρέφτη, αξίζει να κοιτάξετε την ψυχή του SQL Server Agent - Job Activity Monitor, το Job Wizard θα σας δείξει τα πάντα λεπτομερώς:

Τώρα, εάν πληρούνται οι καθορισμένες προϋποθέσεις, θα πρέπει να δημιουργηθεί ένα πλήρες αντίγραφο ασφαλείας της βάσης δεδομένων. Χρησιμοποιώντας την ίδια αρχή, δημιουργείται ένα διαφορικό αντίγραφο ασφαλείας και ένα αντίγραφο ασφαλείας του αρχείου καταγραφής συναλλαγών (αυτά τα υποστοιχεία βρίσκονται κάτω από το "Πλήρης δημιουργία αντιγράφων ασφαλείας" στη λίστα επιλογής εργασιών).
Στρίψτε τα αυτιά MSSQL όπως θέλετε, μην τα ξεβιδώσετε

Στο επόμενο άρθρο - δημιουργία χρησιμοποιώντας Transact-SQL και μερικά παραδείγματα.

Ας επαναφέρουμε τη βάση δεδομένων "Test _Recovery" στο " t 4».

Ας ξεκινήσουμε την επαναφορά της βάσης δεδομένων από ένα πλήρες αντίγραφο ασφαλείας "Full2_Test_Recovery.bak" χρησιμοποιώντας το "SQL Server Management Studio" " Κάντε δεξί κλικ στη βάση δεδομένων " Test_Recovery ", στο μενού που εμφανίζεται, επιλέξτε "Εργασίες», μετά «Επαναφορά», μετά «Βάση δεδομένων».

Στο παράθυρο που εμφανίζεται "Επαναφορά βάσης δεδομένων" στην ενότητα "Πηγή", επιλέξτε "Συσκευή". Επόμενο « Προσθήκη ", εισάγετε τη διαδρομή "\\ vniz - tst - bkp 01. τεστ . local\Backup_SQL\Full 2_Test_Recovery. bak", κάντε κλικ στο "Ok". Στην ενότητα "Προορισμός", επιλέξτε Βάση δεδομένων "Ανάκτηση δοκιμής"

Κάντε κλικ στο "Ok"

Η βάση θα αποκατασταθεί με επιτυχία.

Ας δούμε την επαναφορά μιας βάσης δεδομένων χρησιμοποιώντας το Transact-SQL.

Κάντε δεξί κλικ στη βάση δεδομένων «Test_Recovery» και επιλέξτε «New Query» από το μενού που εμφανίζεται:

Στο παράθυρο που εμφανίζεται, πληκτρολογήστε:

ΧΡΗΣΗ κύριος

ΕΠΑΝΑΦΕΡΩ ΒΑΣΗ ΔΕΔΟΜΕΝΩΝ Test_Recovery

ΑΠΟ ΔΙΣΚΟΣ = "\\vniz-tst-bkp01.test.local\Backup_SQL\Full2_Test_Recovery.bak"

ΜΕ ΑΝΤΙΚΑΘΙΣΤΩ

Η βάση θα αποκατασταθεί με επιτυχία.

Σε αυτό το παράδειγμα χρησιμοποιήσαμε την παράμετρο "REPLACE":

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

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

• Έλεγχος για επαναφορά σε μια υπάρχουσα βάση δεδομένων ενός αντιγράφου ασφαλείας που δημιουργήθηκε για μια άλλη βάση δεδομένων.Όταν χρησιμοποιείτε την επιλογή ΑΝΤΙΚΑΤΑΣΤΑΣΗ, μια επαναφορά μπορεί να γράψει δεδομένα σε μια υπάρχουσα βάση δεδομένων, ανεξάρτητα από το ποιες βάσεις δεδομένων περιέχονται στο σύνολο αντιγράφων ασφαλείας, ακόμα κι αν το καθορισμένο όνομα δεδομένων είναι διαφορετικό από αυτό που γράφτηκε στο σύνολο αντιγράφων ασφαλείας. Αυτό μπορεί να έχει ως αποτέλεσμα την κατά λάθος αντικατάσταση της βάσης δεδομένων από άλλη βάση δεδομένων.
• Δοκιμή για την ανάκτηση μιας βάσης δεδομένων που χρησιμοποιεί το μοντέλο πλήρους ανάκτησης ή το μοντέλο ανάκτησης μαζικής καταγραφής για το οποίο δεν δημιουργήθηκε αντίγραφο ασφαλείας ουράς και δεν εφαρμόστηκε η επιλογή STOPAT.Όταν χρησιμοποιείτε την επιλογή ΑΝΤΙΚΑΤΑΣΤΑΣΗ, ενδέχεται να χάσετε δεσμευμένα δεδομένα επειδή τα πιο πρόσφατα καταγεγραμμένα δεδομένα δεν έχουν αντιγραφεί ακόμη στο αντίγραφο ασφαλείας.
• Αντικαταστήσετε τα υπάρχοντα αρχεία.

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

Εισαγωγή

Αυτό το άρθρο περιγράφει το πιο συνηθισμένο αντίγραφο ασφαλείας 1C IB χρησιμοποιώντας εργαλεία MS SQL Server 2008 R2, εξηγεί γιατί πρέπει να το κάνετε με αυτόν τον τρόπο και όχι με άλλο τρόπο και καταρρίπτει αρκετούς μύθους. Το άρθρο περιέχει πολλές αναφορές στην τεκμηρίωση MS SQL. Αυτό το άρθρο είναι περισσότερο μια επισκόπηση των μηχανισμών δημιουργίας αντιγράφων ασφαλείας παρά ένας ολοκληρωμένος οδηγός. Αλλά για όσους αντιμετωπίζουν αυτήν την εργασία για πρώτη φορά, δίνονται απλές και βήμα προς βήμα οδηγίες που ισχύουν σε απλές καταστάσεις. Το άρθρο δεν προορίζεται για γκουρού διαχείρισης, οι γκουρού τα γνωρίζουν ήδη όλα αυτά, αλλά υποτίθεται ότι ο αναγνώστης μπορεί να εγκαταστήσει ο ίδιος τον MS SQL Server και να αναγκάσει αυτό το θαύμα της εχθρικής τεχνολογίας να δημιουργήσει μια βάση δεδομένων στα βάθη της, η οποία με τη σειρά του είναι μπορεί να αναγκάσει να αποθηκεύσει δεδομένα 1C.

Θεωρώ ότι η εντολή TSQL BACKUP DATABASE (και ο αδελφός της BACKUP LOG) είναι ουσιαστικά το μόνο μέσο δημιουργίας αντιγράφων ασφαλείας βάσεων δεδομένων 1C χρησιμοποιώντας τον MS SQL Server ως DBMS. Γιατί; Ας δούμε ποιες μεθόδους έχουμε γενικά:

Πως	Πρόστιμο	Κακώς	Σύνολο
Μεταφόρτωση σε dt	Πολύ συμπαγής μορφή.	Χρειάζεται πολύς χρόνος για να διαμορφωθεί, απαιτεί αποκλειστική πρόσβαση, δεν αποθηκεύει κάποια ασήμαντα δεδομένα (όπως ρυθμίσεις χρήστη σε προηγούμενες εκδόσεις) και χρειάζεται πολύς χρόνος για να αναπτυχθεί.	Δεν είναι τόσο μια μέθοδος δημιουργίας αντιγράφων ασφαλείας όσο είναι ένας τρόπος μεταφοράς δεδομένων από το ένα περιβάλλον στο άλλο. Ιδανικό για στενά κανάλια.
Αντιγραφή αρχείων mdf και ldf	Ένας πολύ ξεκάθαρος τρόπος για αρχάριους διαχειριστές.	Απαιτεί την απελευθέρωση των αρχείων βάσης δεδομένων από το κλείδωμα, και αυτό είναι δυνατό εάν η βάση δεδομένων είναι απενεργοποιημένη (λήψη εντολής εκτός σύνδεσης από το μενού περιβάλλοντος), αποσυναρμολογηθεί (αποσύνδεση) ή απλώς διακοπεί ο διακομιστής. Προφανώς, οι χρήστες δεν θα μπορούν να εργαστούν αυτήν τη στιγμή.	Αυτή η μέθοδος είναι λογικό να χρησιμοποιείται εάν και μόνο εάν έχει ήδη συμβεί ατύχημα, έτσι ώστε όταν προσπαθείτε να ανακάμψετε, τουλάχιστον να έχετε την ευκαιρία να επιστρέψετε στην επιλογή από την οποία ξεκίνησε η ανάκτηση.
Δημιουργία αντιγράφων ασφαλείας με χρήση λειτουργικού συστήματος ή hypervisor	Ένας βολικός τρόπος για περιβάλλοντα ανάπτυξης και δοκιμής.	Δεν είναι πάντα φιλικό με την ακεραιότητα των δεδομένων. Μέθοδος έντασης πόρων.	Μπορεί να έχει περιορισμένη χρήση για ανάπτυξη. Δεν έχει καμία πρακτική σημασία σε ένα περιβάλλον τροφίμων.
Δημιουργία αντιγράφων ασφαλείας με χρήση MS SQL	Δεν απαιτείται χρόνος διακοπής λειτουργίας. Σας επιτρέπει να επαναφέρετε μια πλήρη κατάσταση σε μια αυθαίρετη στιγμή, εάν ανησυχείτε για αυτό εκ των προτέρων. Εξαιρετικός αυτοματισμός. Οικονομικό σε χρόνο και άλλους πόρους.	Όχι πολύ συμπαγής μορφή. Δεν γνωρίζουν όλοι πώς να χρησιμοποιούν αυτήν τη μέθοδο στον απαιτούμενο βαθμό.	Για περιβάλλοντα τροφίμων - το κύριο εργαλείο.

Οι κύριες δυσκολίες κατά τη χρήση αντιγράφων ασφαλείας με χρήση ενσωματωμένων εργαλείων MS SQL προκύπτουν από μια βασική παρανόηση των αρχών λειτουργίας. Αυτό εξηγείται εν μέρει από τη μεγάλη τεμπελιά, εν μέρει από την έλλειψη απλής και κατανοητής εξήγησης σε επίπεδο «έτοιμων συνταγών» (χμμ, ας πούμε, δεν έχω συναντήσει καμία), και η κατάσταση επιδεινώνεται επίσης. από τη μυθολογική συμβουλή του «υπόγκουρου» στα φόρουμ. Δεν ξέρω τι να κάνω με την τεμπελιά, αλλά θα προσπαθήσω να εξηγήσω τα βασικά του backup.

Τι και γιατί εξοικονομούμε;

Πριν από πολύ καιρό, σε έναν μακρινό γαλαξία, υπήρχε ένα τέτοιο προϊόν μηχανικής και λογιστικής σκέψης όπως το 1C: Enterprise 7.7. Προφανώς λόγω του γεγονότος ότι οι πρώτες εκδόσεις του 1C:Enterprise αναπτύχθηκαν για να χρησιμοποιούν τη δημοφιλή μορφή αρχείου dbf, η έκδοσή του SQL δεν αποθήκευε αρκετές πληροφορίες στη βάση δεδομένων για να θεωρήσει το αντίγραφο ασφαλείας MS SQL ολοκληρωμένο και ακόμη και με κάθε αλλαγή στη δομή του ήταν σπασμένα οι συνθήκες λειτουργίας του μοντέλου πλήρους ανάκτησης, επομένως ήταν απαραίτητο να προχωρήσουμε σε διάφορα μήκη για να αναγκάσουμε το εφεδρικό σύστημα να εκτελέσει την κύρια λειτουργία του. Αλλά από τότε που κυκλοφόρησε η έκδοση 8, τα DBA μπόρεσαν επιτέλους να χαλαρώσουν. Τα τυπικά εργαλεία δημιουργίας αντιγράφων ασφαλείας σάς επιτρέπουν να δημιουργήσετε ένα πλήρες και ολιστικό σύστημα δημιουργίας αντιγράφων ασφαλείας. Μόνο το ημερολόγιο και ορισμένα μικρά πράγματα, όπως ρυθμίσεις για τη θέση των φορμών (σε παλαιότερες εκδόσεις) δεν περιλαμβάνονται στο αντίγραφο ασφαλείας, αλλά η απώλεια αυτών των δεδομένων δεν επηρεάζει τη λειτουργικότητα του συστήματος, αν και είναι σίγουρα σωστό και χρήσιμο να δημιουργήστε αντίγραφα ασφαλείας του ημερολογίου.

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

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

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

• Εξασφαλίστε τη φυσική ασφάλεια των διακομιστών σας: πυρκαγιές, πλημμύρες, φτωχά τροφοδοτικά, καθαριστές, εργάτες κατασκευών, μετεωρίτες και άγρια ​​ζώα περιμένουν στη γωνία για να καταστρέψουν το δωμάτιο διακομιστή σας.
• Αντιμετωπίστε τις απειλές για την ασφάλεια των πληροφοριών με υπευθυνότητα.
• Κάντε επιδέξια αλλαγές στο σύστημα και βεβαιωθείτε εκ των προτέρων ότι αυτές οι αλλαγές δεν θα οδηγήσουν σε φθορά. Εκτός από ένα σχέδιο για την πραγματοποίηση αλλαγών, καλό είναι να έχετε ένα σχέδιο για το «τι να κάνετε εάν όλα πάνε στραβά».
• Χρησιμοποιήστε ενεργά τεχνολογίες για να αυξήσετε τη διαθεσιμότητα και την αξιοπιστία του συστήματος αντί να αντιμετωπίζετε αργότερα τις συνέπειες των ατυχημάτων. Για το MS SQL θα πρέπει να δώσετε προσοχή στα ακόλουθα χαρακτηριστικά:
  • Χρήση συμπλεγμάτων MS SQL (αν και, για να είμαι ειλικρινής, νομίζω ότι αυτός είναι ένας από τους πιο δαπανηρούς και άχρηστους τρόπους για να απασχολήσετε έναν διαχειριστή βάσης δεδομένων για συστήματα που δεν απαιτούν 24x7)
  • Κατοπτρισμός βάσεων δεδομένων (σύγχρονη και ασύγχρονη ανάλογα με τη διαθεσιμότητα, την απόδοση και τις απαιτήσεις κόστους)
  • Παράδοση αρχείου καταγραφής συναλλαγών
  • Αντιγραφή με χρήση εργαλείων 1C (κατανεμημένες βάσεις δεδομένων)

Ανάλογα με τις απαιτήσεις διαθεσιμότητας του συστήματος και τον προϋπολογισμό που διατίθεται για αυτούς τους σκοπούς, είναι πολύ πιθανό να επιλέξετε λύσεις που θα μειώσουν το χρόνο διακοπής λειτουργίας και τον χρόνο αποκατάστασης αστοχίας κατά 1-2 τάξεις μεγέθους. Δεν χρειάζεται να φοβάστε τις τεχνολογίες προσβασιμότητας: είναι αρκετά απλές για να τις μάθετε σε λίγες μέρες με βασικές γνώσεις MS SQL.

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

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

Βασικές πληροφορίες σχετικά με την αποθήκευση και την επεξεργασία δεδομένων MS SQL

Τα δεδομένα στο MS SQL αποθηκεύονται συνήθως σε αρχεία δεδομένων (εφεξής θα αναφέρεται ως FD - μια συντομογραφία που δεν χρησιμοποιείται συνήθως· σε αυτό το άρθρο θα υπάρχουν πολλές ακόμη όχι πολύ συνηθισμένες συντομογραφίες) με τις επεκτάσεις mdf ή ndf. Εκτός από αυτά τα αρχεία, υπάρχουν και αρχεία καταγραφής συναλλαγών (TL), τα οποία αποθηκεύονται σε αρχεία με επέκταση .ldf. Συχνά, οι αρχάριοι διαχειριστές είναι ανεύθυνοι και επιπόλαιοι όταν πρόκειται για VT, τόσο όσον αφορά την απόδοση όσο και την αξιοπιστία αποθήκευσης. Αυτό είναι ένα πολύ σοβαρό λάθος. Στην πραγματικότητα, είναι μάλλον το αντίθετο, εάν υπάρχει ένα αξιόπιστα λειτουργικό εφεδρικό σύστημα και μπορεί να διατεθεί πολύς χρόνος για την επαναφορά του συστήματος, τότε μπορείτε να αποθηκεύσετε δεδομένα σε ένα γρήγορο, αλλά εξαιρετικά αναξιόπιστο RAID-0, αλλά τότε τα δεδομένα πρέπει να αποθηκευτεί σε ξεχωριστό αξιόπιστο και παραγωγικό πόρο (αν και θα ήταν στο RAID-1). Γιατί αυτό? Ας ρίξουμε μια πιο προσεκτική ματιά. Επιτρέψτε μου να κάνω αμέσως μια επιφύλαξη ότι η παρουσίαση είναι κάπως απλοποιημένη, αλλά επαρκής για μια αρχική κατανόηση.

Το FD αποθηκεύει δεδομένα σε σελίδες των 8 kilobyte (οι οποίες συνδυάζονται σε έκταση 64 kilobyte, αλλά αυτό δεν είναι σημαντικό). MS SQL δεν εγγυάταιότι αμέσως μετά την εκτέλεση μιας εντολής αλλαγής δεδομένων, αυτές οι αλλαγές θα πάνε στο FD. Όχι, απλώς η σελίδα στη μνήμη επισημαίνεται ως "απαιτείται αποθήκευση". Εάν ο διακομιστής έχει αρκετούς πόρους, τότε σύντομα αυτά τα δεδομένα θα βρίσκονται στο δίσκο. Επιπλέον, ο διακομιστής λειτουργεί «αισιόδοξα» και εάν αυτές οι αλλαγές συμβαίνουν σε μια συναλλαγή, τότε μπορεί κάλλιστα να καταλήξουν στον δίσκο πριν από τη δέσμευση της συναλλαγής. Δηλαδή, στη γενική περίπτωση, κατά την ενεργό λειτουργία, το ΦΔ περιέχει διάσπαρτα ημιτελή στοιχεία και ημιτελείς συναλλαγές, για τις οποίες είναι άγνωστο αν θα ακυρωθούν ή θα δεσμευτούν. Υπάρχει μια ειδική εντολή "CHECKPOINT", η οποία λέει στον διακομιστή ότι πρέπει να ξεπλύνει όλα τα μη αποθηκευμένα δεδομένα στο δίσκο "αυτή τη στιγμή", αλλά το πεδίο εφαρμογής αυτής της εντολής είναι αρκετά συγκεκριμένο. Αρκεί να πούμε ότι το 1C δεν το χρησιμοποιεί (δεν το έχω συναντήσει) και να καταλάβουμε ότι κατά τη λειτουργία το FD συνήθως δεν είναι σε άθικτη κατάσταση.

Για να αντιμετωπίσουμε αυτό το χάος, χρειαζόμαστε απλώς VT. Σε αυτό καταγράφονται τα ακόλουθα γεγονότα:

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

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

Είναι σημαντικό αυτές οι πληροφορίες να γράφονται αμέσως στο δίσκο. Μέχρι να καταγραφούν οι πληροφορίες στο VT, η εντολή δεν θεωρείται ότι έχει εκτελεστεί. Σε μια κανονική κατάσταση, όταν το μέγεθος του VT είναι επαρκές και όταν δεν είναι πολύ κατακερματισμένο, οι εγγραφές γράφονται σε αυτό διαδοχικά σε μικρές εγγραφές (όχι απαραίτητα πολλαπλάσια των 8 kb). Μόνο τα δεδομένα που είναι πραγματικά απαραίτητα για την ανάκτηση περιλαμβάνονται στο αρχείο καταγραφής συναλλαγών. Συγκεκριμένα Δενλαμβάνονται πληροφορίες σχετικά με το κείμενο αιτήματος που οδήγησε στις τροποποιήσεις, ποιο σχέδιο εκτέλεσης είχε αυτό το αίτημα, ποιος χρήστης το ξεκίνησε και άλλες πληροφορίες που δεν είναι απαραίτητες για ανάκτηση. Το ερώτημα μπορεί να παρέχει κάποιες πληροφορίες για τη δομή δεδομένων καταγραφής συναλλαγών

Επιλέξτε * από::fn_dblog(null,null)

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

Εάν υπάρχει έστω και η παραμικρή πιθανότητα, τότε σε περιβάλλον προϊόντος, τα VT θα πρέπει να βρίσκονται σε ξεχωριστά (από όλα τα άλλα) φυσικά μέσα, κατά προτίμηση με ελάχιστο χρόνο πρόσβασης για διαδοχική εγγραφή και με μέγιστη αξιοπιστία. Για απλά συστήματα, το RAID-1 είναι αρκετά κατάλληλο.

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

Η ακύρωση μιας συναλλαγής στον MS SQL Server διαρκεί συνήθως συγκρίσιμη με τη συνολική διάρκεια των λειτουργιών για την αλλαγή των δεδομένων της ίδιας της συναλλαγής. Προσπαθήστε να μην ακυρώσετε συναλλαγές ή να πάρετε την απόφαση να ακυρώσετε όσο το δυνατόν νωρίτερα.

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

Τι συμβαίνει όταν το VT φτάσει στο τέλος του αρχείου; Είναι απλό - εάν υπάρχει ελεύθερος χώρος στην αρχή, τότε θα αρχίσει να γράφει στον ελεύθερο χώρο στην αρχή του αρχείου πριν από τον κατειλημμένο χώρο. Σαν θηλιά μαγνητική ταινία. Εάν δεν υπάρχει χώρος στην αρχή, τότε ο διακομιστής θα προσπαθήσει συνήθως να επεκτείνει το αρχείο καταγραφής συναλλαγών, ενώ για τον διακομιστή το νέο κομμάτι που εκχωρείται είναι ένα νέο εικονικό αρχείο καταγραφής συναλλαγών, από το οποίο μπορεί να υπάρχουν πολλά στο φυσικό αρχείο συναλλαγών , αλλά αυτό δεν έχει να κάνει με τη δημιουργία αντιγράφων ασφαλείας. Εάν ο διακομιστής αποτύχει να επεκτείνει το αρχείο (ο χώρος στο δίσκο έχει εξαντληθεί ή οι ρυθμίσεις απαγορεύουν την επέκταση του αρχείου), τότε η τρέχουσα συναλλαγή θα ακυρωθεί με σφάλμα 9002.

Ωχ. Τι πρέπει να γίνει για να διασφαλιστεί ότι υπάρχει πάντα μια θέση στο σιδηρόδρομο; Εδώ φτάνουμε στο εφεδρικό σύστημα και τα μοντέλα ανάκτησης. Για να ακυρώσετε συναλλαγές και να επαναφέρετε τη σωστή κατάσταση του διακομιστή σε περίπτωση ξαφνικού τερματισμού λειτουργίας, είναι απαραίτητο να αποθηκεύσετε εγγραφές στο JT, ξεκινώντας από την έναρξη της πρώτης ανοιχτής συναλλαγής. Αυτό το ελάχιστο γράφεται και αποθηκεύεται σε ZhT Αναγκαίως. Ανεξάρτητα από τον καιρό, τις ρυθμίσεις διακομιστή και τις επιθυμίες του διαχειριστή. Ο διακομιστής δεν μπορεί να επιτρέψει να μην υπάρχουν αυτές οι πληροφορίες. Επομένως, εάν ανοίξετε μια συναλλαγή σε μία περίοδο λειτουργίας και εκτελέσετε διαφορετικές ενέργειες σε άλλες, το αρχείο καταγραφής συναλλαγών μπορεί να τελειώσει απροσδόκητα. Η παλαιότερη συναλλαγή μπορεί να αναγνωριστεί με την εντολή DBCC OPENTRAN. Αλλά αυτό είναι μόνο το απαραίτητο ελάχιστο των πληροφοριών. Το τι θα συμβεί στη συνέχεια εξαρτάται από μοντέλα ανάκτησης. Υπάρχουν τρία από αυτά στον SQL Server:

• Απλός— αποθηκεύεται μόνο το υπόλοιπο του VT που είναι απαραίτητο για τη ζωή.
• Γεμάτος— ολόκληρο το VT αποθηκεύεται από το τελευταίο αντίγραφο ασφαλείας αρχείο καταγραφής συναλλαγών. Παρακαλώ σημειώστε, όχι από τη στιγμή της πλήρους δημιουργίας αντιγράφων ασφαλείας!
• Μαζική καταγραφή— μέρος (συνήθως ένα πολύ μικρό μέρος) των λειτουργιών καταγράφονται σε πολύ συμπαγή μορφή (ουσιαστικά απλώς μια εγγραφή ότι αυτή ή η συγκεκριμένη σελίδα του αρχείου δεδομένων έχει αλλάξει). Διαφορετικά πανομοιότυπο με το Full.

Υπάρχουν αρκετοί μύθοι που σχετίζονται με τα μοντέλα ανάκτησης.

• Το Simple σάς επιτρέπει να μειώσετε το φορτίο στο υποσύστημα του δίσκου. Αυτό είναι λάθος. γράφεται ακριβώς το ίδιο ποσό με το Bulk loged, μόνο που θεωρείται δωρεάν πολύ νωρίτερα.
• Η μαζική καταγραφή σάς επιτρέπει να μειώσετε το φορτίο στο υποσύστημα του δίσκου. Για 1C αυτό σχεδόν δεν ισχύει. Στην πραγματικότητα, μία από τις λίγες λειτουργίες που μπορεί να υποκύψουν σε ελάχιστη καταγραφή χωρίς πρόσθετους χορούς με ντέφι είναι η φόρτωση δεδομένων από μια αποστολή σε μορφή dt και η αναδιάρθρωση πινάκων.
• Όταν χρησιμοποιείτε το μοντέλο μαζικής καταγραφής, ορισμένες συναλλαγές δεν περιλαμβάνονται στο αντίγραφο ασφαλείας του αρχείου καταγραφής συναλλαγών και δεν σας επιτρέπει να επαναφέρετε την κατάσταση κατά τη στιγμή της δημιουργίας αυτού του αντιγράφου ασφαλείας. Αυτό δεν είναι απολύτως αληθές. Εάν η λειτουργία έχει καταγραφεί ελάχιστα, τότε οι τρέχουσες σελίδες με δεδομένα θα συμπεριληφθούν στο αντίγραφο ασφαλείας και θα είναι δυνατή η αναπαραγωγή του αρχείου καταγραφής συναλλαγών μέχρι το τέλος (αν και αυτό δεν είναι δυνατό σε αυθαίρετη χρονική στιγμή, εάν υπάρχουν ελάχιστα καταγεγραμμένες λειτουργίες).

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

• Δομή αρχείου καταγραφής συναλλαγών
• • Μοντέλα ανάκτησης και διαχείριση αρχείων καταγραφής συναλλαγών
  • Διαχείριση αρχείων καταγραφής συναλλαγών
• Χρήση αντιγράφων ασφαλείας καταγραφής συναλλαγών

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

Ανάλογα με τον τύπο του σχηματισμού, τα αντίγραφα ασφαλείας είναι τριών τύπων:

• Γεμάτος(Γεμάτος)
• Διαφορικός(Διαφορικό, διαφορά)
• Κούτσουρο(Εφεδρικό αντίγραφο των αρχείων καταγραφής συναλλαγών, δεδομένου του πόσο συχνά χρησιμοποιείται αυτός ο όρος, θα τον συντομεύσουμε σε RKZhT)

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

Η πλήρης και η διαφορική αντιγραφή λειτουργούν το ίδιο για το Simple και το Full. Το αντίγραφο ασφαλείας του αρχείου καταγραφής συναλλαγών λείπει εντελώς από το Simple.

Πλήρες αντίγραφο ασφαλείας

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

Διαφορικό αντίγραφο ασφαλείας

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

Σημαντικά σημεία:

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

RKZhT

Περιέχει αντίγραφο του VT για ορισμένο χρονικό διάστημα. Συνήθως από τη στιγμή του τελευταίου RKZhT μέχρι το σχηματισμό του σημερινού RKZhT. Το RKZHT σάς επιτρέπει να επαναφέρετε την κατάσταση από ένα αντίγραφο που έχει αποκατασταθεί σε λειτουργία NORECOVERY σε οποιαδήποτε χρονική στιγμή περιλαμβάνεται στην περίοδο του αποκαταστημένου αντιγράφου του ZHT σε οποιοδήποτε επόμενο χρονικό σημείο που περιλαμβάνεται στο διάστημα του αποκαταστημένου αντιγράφου ασφαλείας. Όταν δημιουργείτε ένα αντίγραφο ασφαλείας με τυπικές παραμέτρους, ελευθερώνεται χώρος στο αρχείο καταγραφής συναλλαγών (μέχρι τη στιγμή της τελευταίας ανοιχτής συναλλαγής).

Προφανώς, το RKZhT δεν έχει νόημα στο μοντέλο Simple (τότε το ZhT περιέχει μόνο πληροφορίες από τη στιγμή της τελευταίας μη κλειστής συναλλαγής).

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

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

Συνήθεις παρανοήσεις και μύθοι:

• "Το RKZhT περιέχει δεδομένα καταγραφής συναλλαγών από τη στιγμή του προηγούμενου πλήρους ή διαφορικού αντιγράφου ασφαλείας."Όχι, δεν είναι αλήθεια. Το RKZhT περιέχει επίσης, με την πρώτη ματιά, άχρηστα δεδομένα μεταξύ του προηγούμενου RKZhT και του επόμενου πλήρους αντιγράφου ασφαλείας.
• "Ένα πλήρες ή διαφορικό αντίγραφο ασφαλείας θα πρέπει να ελευθερώσει χώρο μέσα στο αρχείο καταγραφής συναλλαγών."Όχι, δεν είναι αλήθεια. Τα πλήρη και διαφορικά αντίγραφα ασφαλείας δεν επηρεάζουν την αλυσίδα RKZhT.
• Το VT πρέπει να καθαρίζεται περιοδικά με το χέρι, να μειώνεται και να τεμαχίζεται.Όχι, δεν είναι απαραίτητο και, αντίθετα, είναι ανεπιθύμητο. Εάν απελευθερώσετε το VT μεταξύ του RCVT, η αλυσίδα RCVT που απαιτείται για την αποκατάσταση θα σπάσει. Και η συνεχής μείωση/επέκταση του αρχείου θα οδηγήσει σε φυσικό και λογικό κατακερματισμό του.

Πώς λειτουργεί με απλά λόγια

Ας υπάρχει μια βάση δεδομένων 1000 GB. Κάθε μέρα η βάση δεδομένων αυξάνεται κατά 2 GB, ενώ 10 GB παλαιών δεδομένων αλλάζουν. Έχουν δημιουργηθεί τα ακόλουθα αντίγραφα ασφαλείας

• Πλήρες αντίγραφο του F1 από 0:00 1 Φεβρουαρίου (όγκος 1000 GB, η συμπίεση δεν λαμβάνεται υπόψη για την απλότητα της εικόνας)
  • Διαφορικό αντίγραφο του D1.1 από 0:00 2 Φεβρουαρίου (όγκος 12 GB)
  • Διαφορικό αντίγραφο του D1.2 από 0:00 3 Φεβρουαρίου (όγκος 19 GB)
  • Διαφορικό αντίγραφο του D1.3 από 0:00 4 Φεβρουαρίου (όγκος 25 GB)
  • Διαφορικό αντίγραφο του D1.4 από 0:00 5 Φεβρουαρίου (όγκος 31 GB)
  • Διαφορά αντίγραφο D1.5 από 0:00 6 Φεβρουαρίου (όγκος 36 GB)
  • Διαφορικό αντίγραφο του D1.6 από 0:00 7 Φεβρουαρίου (όγκος 40 GB)
• Πλήρες αντίγραφο του F2 από τις 0:00 8 Φεβρουαρίου (τόμος 1014 GB)
  • Διαφορικό αντίγραφο του D2.1 από 0:00 9 Φεβρουαρίου (όγκος 12 GB)
  • Διαφορικό αντίγραφο του D2.2 από 0:00 10 Φεβρουαρίου (όγκος 19 GB)
  • Διαφορικό αντίγραφο του D2.3 από 0:00 11 Φεβρουαρίου (όγκος 25 GB)
  • Διαφορικό αντίγραφο του D2.4 από 0:00 12 Φεβρουαρίου (όγκος 31 GB)
  • Διαφορά αντίγραφο D2.5 από 0:00 13 Φεβρουαρίου (όγκος 36 GB)
  • Διαφορικό αντίγραφο του D2.6 από 0:00 14 Φεβρουαρίου (όγκος 40 GB)

Χρησιμοποιώντας αυτό το σύνολο, μπορούμε να επαναφέρουμε δεδομένα στις 0:00 οποιαδήποτε ημέρα από την 1η Φεβρουαρίου έως τις 14 Φεβρουαρίου. Για να γίνει αυτό, πρέπει να πάρουμε ένα πλήρες αντίγραφο του F1 για την εβδομάδα 1-7 Φεβρουαρίου ή ένα πλήρες αντίγραφο του F2 για τις 8-14 Φεβρουαρίου, να το επαναφέρουμε στη λειτουργία NORECOVERY και στη συνέχεια να εφαρμόσουμε ένα διαφορικό αντίγραφο της επιθυμητής ημέρας.

Πώς λειτουργεί πλήρως

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

• RKZhT 1 για την περίοδο από τις 12:00 31 Ιανουαρίου έως τις 12:00 2 Φεβρουαρίου (περίπου 30 GB)
• RKZhT 2 για την περίοδο από τις 12:00 2 Φεβρουαρίου έως τις 12:00 4 Φεβρουαρίου (περίπου 30 GB)
• RKZhT 3 για την περίοδο από 12:00 4 Φεβρουαρίου έως 12:00 6 Φεβρουαρίου (περίπου 30 GB)
• RKZhT 4 για την περίοδο από τις 12:00 6 Φεβρουαρίου έως τις 12:00 7 Φεβρουαρίου (περίπου 30 GB)
• RKZhT 5 για την περίοδο από 12:00 8 Φεβρουαρίου έως 12:00 10 Φεβρουαρίου (περίπου 30 GB)
• RKZhT 6 για την περίοδο από 12:00 10 Φεβρουαρίου έως 12:00 12 Φεβρουαρίου (περίπου 30 GB)
• RKZhT 7 για την περίοδο από 12:00 12 Φεβρουαρίου έως 12:00 14 Φεβρουαρίου (περίπου 30 GB)
• RKZhT 8 για την περίοδο από 12:00 14 Φεβρουαρίου έως 12:00 16 Φεβρουαρίου (περίπου 30 GB)

Σημείωση:

1. Το μέγεθος του RKZhT θα είναι περίπου σταθερό.
2. Μπορούμε να κάνουμε αντίγραφα ασφαλείας λιγότερο συχνά από τα διαφορικά ή τα πλήρη, ή μπορούμε να τα κάνουμε πιο συχνά, τότε θα είναι μικρότερα σε μέγεθος.
3. Μπορούμε τώρα να επαναφέρουμε την κατάσταση του συστήματος σε οποιοδήποτε σημείο από τις 0:00 της 1ης Φεβρουαρίου, όταν έχουμε το παλαιότερο πλήρες αντίγραφο, έως τις 12:00 της 16ης Φεβρουαρίου.

Στην απλούστερη περίπτωση, πρέπει να επαναφέρουμε:

1. Τελευταίο πλήρες αντίγραφο πριν από την ανάκτηση
2. Τελευταίο διαφορικό αντίγραφο πριν από την ανάκτηση
3. Όλα τα RKZhT, από τη στιγμή της τελευταίας αντιγραφής διαφοράς μέχρι τη στιγμή της αποκατάστασης

• Πλήρες αντίγραφο του F2 από τις 0:00 8 Φεβρουαρίου
• Διαφορά αντίτυπο Δ2.2 από 0:00 10 Φεβρουαρίου
• RKZhT 6 για την περίοδο από 12:00 10 Ιανουαρίου έως 12:00 12 Φεβρουαρίου

Πρώτα, θα γίνει επαναφορά του F2, μετά το D2.2 και μετά το RKZhT 6 έως τις 13:13:13 στις 10 Φεβρουαρίου. Αλλά ένα σημαντικό πλεονέκτημα του μοντέλου Full είναι ότι έχουμε την επιλογή - να χρησιμοποιήσουμε το τελευταίο πλήρες ή διαφορικό αντίγραφο ή ΟΧΙ το τελευταίο. Για παράδειγμα, εάν ανακαλύφθηκε ότι το αντίγραφο του D2.2 ήταν κατεστραμμένο και έπρεπε να το επαναφέρουμε στη στιγμή πριν από τις 13:13:13 στις 10 Φεβρουαρίου, τότε για το απλό μοντέλο αυτό θα σήμαινε ότι θα μπορούσαμε να επαναφέρουμε μόνο το δεδομένα μέχρι τη στιγμή D2.1. Με το Full - "DON"T PANIC", έχουμε τις ακόλουθες επιλογές:

1. Επαναφέρετε το F2, μετά το D2.1, μετά το RKZHT 5 και μετά το RKZHT 6 μέχρι τις 13:13:13 στις 10 Φεβρουαρίου.
2. Επαναφέρετε το F2, μετά το RKZHT 4, μετά το RKZHT 5 και μετά το RKZHT 6 μέχρι τις 13:13:13 στις 10 Φεβρουαρίου.
3. Εναλλακτικά, επαναφέρετε την F1 και εκτελέστε όλα τα RKZhT έως και RKZhT 6 έως τις 13:13:13 της 10ης Φεβρουαρίου.

Όπως μπορείτε να δείτε, το πλήρες μοντέλο μας δίνει περισσότερες επιλογές.

Τώρα ας φανταστούμε ότι είμαστε πολύ πονηροί. Και μερικές μέρες πριν την αποτυχία (13:13:13 10 Φεβρουαρίου) ξέρουμε ότι θα υπάρξει αποτυχία. Επαναφέρουμε τη βάση δεδομένων σε έναν γειτονικό διακομιστή από ένα πλήρες αντίγραφο ασφαλείας, αφήνοντας την ευκαιρία να συγκεντρώσουμε τις επόμενες καταστάσεις με διαφορικά αντίγραφα ή RKZhT, δηλαδή την αφήσαμε σε λειτουργία NORECOVERY. Και κάθε φορά, αμέσως μετά το σχηματισμό του RKZhT, το εφαρμόζουμε σε αυτήν την εφεδρική βάση, αφήνοντάς το σε λειτουργία NORECOVERY. Ουάου! Γιατί, τώρα θα μας πάρει μόνο 10-15 λεπτά για να επαναφέρουμε τη βάση δεδομένων, αντί να επαναφέρουμε μια τεράστια βάση δεδομένων! Συγχαρητήρια, εφεύραμε εκ νέου την αποστολή κορμών, έναν από τους τρόπους μείωσης του χρόνου διακοπής λειτουργίας. Εάν μεταφέρετε δεδομένα με αυτόν τον τρόπο όχι μία φορά ανά περίοδο, αλλά συνεχώς, τότε θα λάβετε κατοπτρισμό και εάν η βάση πηγής περιμένει να ενημερωθεί η βάση κατοπτρισμού, τότε πρόκειται για σύγχρονο κατοπτρισμό, εάν δεν περιμένει, τότε είναι ασύγχρονος .

Μπορείτε να διαβάσετε περισσότερα σχετικά με τα εργαλεία υψηλής διαθεσιμότητας στη βοήθεια:

• Υψηλή διαθεσιμότητα (μηχανή βάσης δεδομένων)
  • Κατανόηση λύσεων υψηλής διαθεσιμότητας
  • Υψηλό επίπεδο προσβασιμότητας. Αλληλεπίδραση και συνεργασία

Άλλα ζητήματα δημιουργίας αντιγράφων ασφαλείας

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

Ομάδες αρχείων

1C: Η επιχείρηση ουσιαστικά δεν ξέρει πώς να συνεργάζεται με ομάδες αρχείων. Υπάρχει μια ενιαία ομάδα αρχείων και αυτό είναι. Στην πραγματικότητα, ένας προγραμματιστής ή ένας διαχειριστής βάσης δεδομένων MS SQL είναι σε θέση να τοποθετήσει μερικούς πίνακες, ευρετήρια ή ακόμα και κομμάτια πινάκων και ευρετηρίων σε ξεχωριστές ομάδες αρχείων (στην απλούστερη έκδοση, σε ξεχωριστά αρχεία). Αυτό είναι απαραίτητο είτε για να επιταχυνθεί η πρόσβαση σε ορισμένα δεδομένα (τοποθετώντας τα σε πολύ γρήγορα μέσα), είτε αντίστροφα, θυσιάζοντας την ταχύτητα και τοποθετώντας τα σε φθηνότερα μέσα (για παράδειγμα, ελάχιστα χρησιμοποιημένα αλλά ογκώδη δεδομένα). Όταν εργάζεστε με ομάδες αρχείων, είναι δυνατό να δημιουργήσετε αντίγραφα ασφαλείας ξεχωριστά και μπορείτε επίσης να τα επαναφέρετε ξεχωριστά, αλλά πρέπει να λάβετε υπόψη ότι όλες οι ομάδες αρχείων θα πρέπει να "πιαστούν" μέχρι ένα σημείο, γυρίζοντας το RKZhT.

Αρχεία δεδομένων

Εάν ένα άτομο διαχειρίζεται την τοποθέτηση δεδομένων σε διαφορετικές ομάδες αρχείων, τότε όταν υπάρχουν πολλά αρχεία μέσα στην ομάδα αρχείων, τότε ο MS SQL Server ωθεί τα δεδομένα σε αυτά ανεξάρτητα (αν ο όγκος των αρχείων είναι ίσος, θα προσπαθήσει ομοιόμορφα). Από πλευράς εφαρμογής, αυτό χρησιμοποιείται για τον παραλληλισμό των λειτουργιών I/O. Αλλά από την άποψη των αντιγράφων ασφαλείας, υπάρχει ένα άλλο σημείο. Για πολύ μεγάλες βάσεις δεδομένων στην εποχή πριν από την SQL 2008, ήταν τυπικό πρόβλημα η εκχώρηση ενός συνεχόμενου παραθύρου για ένα πλήρες αντίγραφο ασφαλείας και ο δίσκος προορισμού για αυτό το αντίγραφο ασφαλείας μπορεί απλώς να μην το φιλοξενήσει. Ο ευκολότερος τρόπος σε αυτήν την περίπτωση ήταν να δημιουργήσετε ένα αντίγραφο ασφαλείας κάθε αρχείου (ή ομάδας αρχείων) στο δικό του παράθυρο. Τώρα, με την ενεργή εξάπλωση της συμπίεσης εφεδρικών αντιγράφων, αυτό το πρόβλημα έχει γίνει λιγότερο, αλλά αυτή η τεχνική μπορεί ακόμα να ληφθεί υπόψη.

Εφεδρική συμπίεση

Ο MS SQL Server 2008 εισήγαγε μια δυνατότητα super-mega-ultra. Από εδώ και στο εξής, τα αντίγραφα ασφαλείας μπορούν να συμπιέζονται όταν δημιουργούνται εν κινήσει. Αυτό μειώνει το μέγεθος ενός αντιγράφου ασφαλείας βάσης δεδομένων 1C κατά 5-10 φορές. Και λαμβάνοντας υπόψη ότι η απόδοση του υποσυστήματος δίσκου είναι συνήθως το σημείο συμφόρησης του DBMS, αυτό όχι μόνο μειώνει το κόστος αποθήκευσης, αλλά επίσης επιταχύνει σημαντικά τη δημιουργία αντιγράφων ασφαλείας (αν και το φορτίο στους επεξεργαστές αυξάνεται, αλλά συνήθως η ισχύς του επεξεργαστή είναι αρκετά επαρκής στον διακομιστής DBMS).

Εάν στην έκδοση του 2008 αυτή η δυνατότητα ήταν διαθέσιμη μόνο για την έκδοση Enterprise (η οποία είναι πολύ ακριβή), τότε το 2008 R2 αυτή η δυνατότητα δόθηκε στην Standard έκδοση, η οποία είναι πολύ ευχάριστη.

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

Ένα αρχείο αντιγράφου ασφαλείας - πολλά εσωτερικά

Στην πραγματικότητα, ένα αντίγραφο ασφαλείας δεν είναι απλώς ένα αρχείο, είναι ένα αρκετά περίπλοκο δοχείο στο οποίο μπορούν να αποθηκευτούν πολλά αντίγραφα ασφαλείας. Αυτή η προσέγγιση έχει μια πολύ αρχαία ιστορία (προσωπικά την παρατηρώ από την έκδοση 6.5), αλλά αυτή τη στιγμή για τους διαχειριστές των "κανονικών" βάσεων δεδομένων, ειδικά των βάσεων δεδομένων 1C, δεν υπάρχουν σοβαροί λόγοι να μην χρησιμοποιούν το "ένα αντίγραφο ασφαλείας - ένα αρχείο» προσέγγιση . Για γενική ανάπτυξη, είναι χρήσιμο να εξερευνήσετε τη δυνατότητα να τοποθετήσετε πολλά αντίγραφα ασφαλείας σε ένα αρχείο, αλλά πιθανότατα δεν θα χρειαστεί να το χρησιμοποιήσετε (ή, αν χρειαστεί, θα τακτοποιήσει τα συντρίμμια ενός επίδοξου διαχειριστή ο οποίος χρησιμοποίησε ανεπιφύλακτα αυτή την ευκαιρία).

Πολλαπλά αντίγραφα καθρέφτη

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

Παραδείγματα εφεδρικών συστημάτων

Αρκετή θεωρία. Ήρθε η ώρα να αποδείξετε με την πράξη ότι όλη αυτή η κουζίνα λειτουργεί.

Ρύθμιση τυπικής κράτησης διακομιστή μέσω Σχεδίων Συντήρησης

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

Χρήση του οδηγού δημιουργίας σχεδίου υπηρεσίας

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

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

• Χρησιμοποιήστε αντίγραφο ασφαλείας καθρέφτη
• Χρησιμοποιήστε ρυθμίσεις συμπίεσης διαφορετικές από τις ρυθμίσεις διακομιστή
• Δεν επιτρέπει ευέλικτη απόκριση σε αναδυόμενες καταστάσεις (χωρίς δυνατότητες χειρισμού σφαλμάτων)
• Δεν επιτρέπει την ευέλικτη χρήση των ρυθμίσεων ασφαλείας
• Τα σχέδια υπηρεσίας είναι πολύ άβολα να αναπτυχθούν (και να διατηρηθούν τα ίδια) σε μεγάλο αριθμό διακομιστών (ακόμα και, ίσως, ήδη σε 3-4)

Ακολουθούν τυπικές εντολές δημιουργίας αντιγράφων ασφαλείας

Πλήρες αντίγραφο ασφαλείας

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

ΑΝΤΙΓΡΑΦΗ ΒΑΣΗΣ ΔΕΔΟΜΕΝΩΝ ΣΤΟ ΔΙΣΚΟ = N"C:\Backup\mydb.bak" WITH INIT, FORMAT, STATS = 1, CHECKSUM

Διαφορικό αντίγραφο ασφαλείας

Ομοίως - αντίγραφο διαφοράς

ΑΝΤΙΓΡΑΦΗ ΒΑΣΗΣ ΔΕΔΟΜΕΝΩΝ ΣΤΟ ΔΙΣΚΟ = N"C:\Backup\mydb.diff" ΜΕ ΔΙΑΦΟΡΙΚΟΣ, INIT, FORMAT, STATS = 1, CHECKSUM

RKZhT

Αντίγραφο ασφαλείας του αρχείου καταγραφής συναλλαγών

BACKUP LOG TO DISK = N"C:\Backup\mydb.trn" WITH INIT, FORMAT

Αντίγραφο ασφαλείας καθρέφτη

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

ΑΝΤΙΓΡΑΦΗ ΒΑΣΗΣ ΔΕΔΟΜΕΝΩΝ ΣΤΟ ΔΙΣΚΟ = N"C:\Backup\mydb.bak", ΚΑΘΡΕΦΤΗΣ ΠΡΟΣΔΙΣΚΟΣ = N"\\safe-server\backup\mydb.bak" WITH INIT, FORMAT

Ένα σημαντικό σημείο που συχνά χάνεται: ο χρήστης για λογαριασμό του οποίου εκκινείται η διαδικασία του MSSQL Server πρέπει να έχει πρόσβαση στον πόρο "\\safe-server\backup\", διαφορετικά η αντιγραφή θα αποτύχει. Εάν ο MSSQL Server εκκινηθεί για λογαριασμό του συστήματος, τότε θα πρέπει να δοθεί πρόσβαση στον χρήστη τομέα "server_name$", αλλά είναι ακόμα καλύτερο να ρυθμίσετε σωστά τις παραμέτρους του MS SQL ώστε να εκτελείται για λογαριασμό ενός ειδικά δημιουργημένου χρήστη.

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