go backsqlschool blogs list

Lesson: Backup/Restore in SQL Server 2008

by Antonios Chatzipavlis

Βλέποντας μέσα από το forum μας διάφορες συζητήσεις σχετικά με το θέμα του μεγέθους του transaction log (T-Log) διαπίστωσα ότι υπάρχει ένα θολό τοπίο γύρω από το θέμα disaster recovery (backup - restore) πάνω στον SQL Server.

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

Πριν ξεκινήσω να παρουσιάζω το θέμα θα πρέπει να ξεκαθαρίσω, και θα ήθελα αυτό να το έχετε σαν αρχή, στον SQL Server παίρνουμε SQL Server Backup και όχι οτιδήποτε άλλο.

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

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

Database Recovery Models

Πρώτα από όλα θα πρέπει να καταλάβουμε τι είναι τα database recovery models, τι κάνουν, ποια είναι και πως επηρεάζουν το disaster recovery strategy που θα ακολουθήσουμε.

Simple Recovery Model

Είναι το απλούστερο μοντέλο το οποίο μπορεί κάποιος να επιλέξει σε μια βάση δεδομένων.

Ενδείκνυται για :

1. μικρές βάσεις δεδομένων,

2. για βάσεις που έχουν μικρό αριθμό αλλαγών (transactions),

3. για τις περιπτώσεις που θέλουμε να έχουμε μικρό μέγεθος στο T-Log file,

4. για βάσεις που είναι read-only,

5. για τις βάσεις που είναι σε φάση development ή δουλεύουν developers με αυτές για την κατασκευή εφαρμογών.

Το συγκεκριμένο μοντέλο δουλεύει με τον εξής τρόπο, κάθε φορά που γίνεται διαδικασία checkpoint ή φτάνει να γεμίσει το φυσικό αρχείο του T-Log file γίνεται αυτόματα truncate με αποτέλεσμα να επαναχρησιμοποιείτε ο εσωτερικά ελεύθερος χώρος.

Το μειονέκτημα στο μοντέλο αυτό είναι ότι μπορείς να γυρίσεις στον τελευταίο full backup που έχεις πάρει στην περίπτωση που η βάση σκάσει.

Full Recovery Model

Είναι το default recovery model. Όλα τα transactions που γίνονται στην βάση καταγράφονται στην λεπτομέρεια τους σε επίπεδο data page και row και αυτό έχει σαν αποτέλεσμα να χρειάζεται περισσότερος χώρος για το T-Log file. Το πλεονεκτήματα του είναι ότι στις περιπτώσεις που έχω πτώση της βάσης μπορώ να γυρίσω ακριβώς στο σημείο της πτώσης της χάνοντας μόνο τα transactions που την στιγμή της πτώσης ήταν σε εξέλιξη δηλαδή δεν είχαν γίνει commit!.

Bulk-Logged Recovery Model

Είναι ίσως αυτό που πολλοί DBA δεν το έχουν καταλάβει πως δουλεύει!. Αυτό κάνει ακριβώς ότι κάνει και το Full Recovery Model με μια σημαντική διαφορά. Καταγράφει τα πάντα σε επίπεδο extent (8 συνεχόμενες σελίδες). Αυτό έχει σαν αποτέλεσμα να μπορώ να γυρίσω πάλι στο σημείο της πτώσης της βάσης αλλά χρειάζομαι περισσότερο χρόνο για να έρθει αυτή σε κατάσταση online.

Για να γίνει κατανοητό αυτό ας πάρουμε σαν παράδειγμα το εξής:

Έστω ότι έχω μια βάση που είναι σε Full Recovery Model και φτιάχνω ή συντηρώ κάποιον index που έχω σε αυτή. Αφού έχει τελειώσει η εργασία αυτή έστω ότι έχω πτώση της βάσης. Όταν θα κάνω restore η εργασία αυτή θα είναι έτοιμη. Εάν όμως είμαι σε Bulk-Logged Model τα πράγματα είναι λίγο διαφορετικά. Για να το κάνω πιο κατανοητό ας πούμε ότι καταγράφεται η ενέργεια και όχι το αποτέλεσμα της. Έτσι όταν θα κάνω restore θα πρέπει να ξανακάνει πάλι την ενέργεια αυτή, που όπως γίνεται εύκολα αντιληπτό από την φύση της ενέργειας θα πάρει χρόνο για να την ολοκληρώσει.

Σε αυτό το μοντέλο όλες οι bulk εργασίες γίνονται logged με το ελάχιστο δυνατό τρόπο. Τέτοιες εργασίες είναι:

· Bulk imports of data (BCP, BULK INSERT, OPENROWSET with BULK clause)

· BLOB operations ( WRITETEXT, UPDATETEXT)

· SELECT INTO statements

· CREATE/ALTER INDEX, ALTER INDEX REBUILD, DBCC REINDEX

Το μοντέλο αυτό είναι ιδανικό για περιπτώσεις που έχω data warehouses και βάσεις με μεγάλο όγκο από bulk εργασίες. Το μειονέκτημα του είναι δεν μπορώ να γυρίσω σε συγκεκριμένο σημείο (point-in-time) το οποίο όμως θα δούμε παρακάτω τι είναι αυτό.

SQL Server Backup Types

Για να δούμε όμως τις δυνατές επιλογές που έχουμε για backup στον SQL Server. Επίσης θα πρέπει να επισημάνω, κάτι το οποίο ισχύει για όλα τους τύπους, ότι μπορώ να πάρω backup ενώ υπάρχει κόσμος και δουλεύει πάνω στην βάση μου (το λέω γιατί μπορείς κάποιος να μην το έχει καταλάβει ότι αυτό γίνεται). Μπορώ να έχω όσα backups θέλω μέσα στην ημέρα αν αυτό δεν μου δημιουργεί προβλήματα απόδοσης στην βάση κατά τη στιγμή που γίνεται αυτή backup. Ναι υπάρχει κάποιο πέναλτι το οποίο επηρεάζεται από πολλούς παράγοντες όπως ταχύτητα μαγνητικών μέσων, μέγεθος βάσης και τύπος του backup.

Full Backup

Είναι η βάση για όλες τις άλλες επιλογές που έχω για backup στον SQL Server. Με άλλα λόγια δεν μπορώ να κάνω πχ Differential, Transaction, Tail-Log κλπ εάν δεν έχω πάρει έστω ένα Full Backup. Στην ουσία παίρνει τα πάντα backup με τον έξης τρόπο. Πρώτα κάνει την διαδικασία checkpoint όπου κατεβάζει με αυτή όλα τα data pages της βάσης, που παίρνω backup, από την buffer cache στον δίσκο και μετά ρουφάει σαν σκούπα hoover τα αρχεία από δίσκο και τα βάζει στο backup μου. Ο χρόνος εκτέλεσης μιας τέτοιας εργασίας είναι πάντα σχετικός με το μέγεθος το δεδομένων μου. Το μέγεθος του backup είναι πάντα το πραγματικό μέγεθος των δεδομένων που έχω στην βάση και όχι το φυσικό μέγεθος των αρχείων που υπάρχουν στο δίσκο. Εάν θέλει κάποιος να κάνει εκτίμηση του μεγέθους του Full Backup σε μια βάση του δεν έχει από το να εκτελέσει την sp_spaceused stored procedure και θα πάρει την απάντηση στο ερώτημα του. Επίσης θα πρέπει να γνωρίζουμε ότι Full Backup μπορώ να πάρω με οποιοδήποτε επιλεγμένο Recovery Model έχω στην βάση μου. Εν κατακλείδι ΠΑΝΤΑ FULL BACKUP είναι η ΒΑΣΗ ΟΛΩΝ.

Στην ουσία το επόμενο full backup που θα πάρω περιέχει μέσα του όλα τα προηγούμενα.

Differential Backup

Για να πάρω Differential Backup πρέπει να έχω πάρει Full Backup. Μπορώ να πάρω diffrential backup με όλα τα recovery models. Κάθε τέτοιου τύπου backup περιέχει ΟΛΕΣ τις αλλαγές που έχουν γίνει από το τελευταίο Full Backup που έχω πάρει. Στην ουσία κάθε νέο differential backup "καταργεί" όλα τα προηγούμενα diffential backups.

Ας πάρουμε ένα παράδειγμα. Έστω ότι έχω πάρει full backup στις 05:00 και στις 10:00 παίρνω differential backup. Αυτό περιέχει ότι έχει γίνει από τις 05:00 μέχρι τις 10:00. Εάν στις 13:00 ξαναπάρω differential αυτό περιέχει ότι έχει γίνει από τις 05:00 μέχρι τις 13:00.

Ελπίζω αυτό να έγινε κατανοητό διότι αρκετοί συνάδελφοι πιστεύουν ότι το κάθε differential περιέχει τις αλλαγές από το τελευταίο backup.

Ιδανικό σενάριο για μεγάλες βάσεις που το full backup παίρνει χρόνο. Επίσης το χρησιμοποιούμε και για να μειώσουμε τον αριθμό των αρχείων αλλά και το χρόνο που θα χρειαστούμε σε περίπτωση που θελήσουμε να κάνουμε restore.

Transaction Log Backup

Αυτός ο τύπος backup παίζει μόνο εφόσον στην βάση μου έχω FULL ή BULK-LOGGED Recovery Model.

Φυσικά για να πάρω T-Log backup θα πρέπει να έχω πάρει ένα full backup. Κάθε T-Log backup περιέχει τα transactions που έχουν γίνει στην βάση μου για το χρονικό διάστημα από το τελευταίο t-log backup ή το τελευταίο full εφόσον πριν από αυτό δεν υπάρχει t-log backup. Ο χρόνος που απαιτείται για αυτό συνήθως είναι μικρός και το πέναλτι στην απόδοση σχεδόν ασήμαντο. Επίσης θα πρέπει να τονιστεί ότι EINAI ΤΟ ΜΟΝΑΔΙΚΟ BACKUP ΠΟΥ ΚΑΝΕΙ TRUNCATE TO LOG FILE. (δείτε το άρθρο μου "Ο θαυμαστός κόσμος του Transaction Log")

Ας πάρουμε ένα παράδειγμα. Έστω ότι έχω πάρει full backup στις 05:00 και στις 07:00 παίρνω t-log backup αυτό περιέχει τα transactions που έχουν γίνει από τις 05:00 έως τις 07:00. Εάν στις 09:00 πάρω ξανά t-log backup αυτό θα περιέχει τα transactions που έχουν γίνει από τις 07:00 έως τις 09:00.

Προσοχή: Το κάθε t-log backup χρειάζεται την προηγούμενη βάση του για να γίνει restore. Εάν για παράδειγμα χάσω το t-log backup που πήρα στις 07:00 δεν θα μπορέσω να κάνω restore αυτό που πήρα στις 09:00 αυτό στην ορολογία του SQL Server το ονομάζουμε transaction log chain.

Tail-Log Backup

Ένα tail-log backup είναι στην ουσία ένα t-log backup το οποίο περιέχει το κομμάτι του log το οποίο δεν έχει παρθεί backup. Μα θα μου πει κάποιος αυτό δεν είναι t-log backup; Όχι ακριβώς. Για να γίνει κατανοητό θα πάρουμε ένα παράδειγμα. Έστω ότι κάθε μέρα στις 05:00 κάνω full backup και κάθε 2 ώρες από εκεί και μετά t-log backup. Έστω ότι στις 11:30 η βάση μου αποδημεί εις τον Κύριο. Σύμφωνα με αυτά που έχουμε πει μέχρι τώρα στα χέρια μου έχω backups που όταν θα τα κάνω restore θα με γυρίσουν στις 11:00 άρα χάνω ότι έχω κάνει από 11:00-11:30. Ξαναλέω ότι η βάση είναι off. Πριν αρχίσω να κάνω restore θέλω να βάλω στην τσέπη μου αυτό το μισάωρο. Εάν τα καταφέρω τότε θα είμαι σε θέση να γυρίσω στις 11:30. Και τώρα κάποιος θα πει, "και γιατί δεν προσπαθώ να πάρω t-log backup;". Αυτό δεν μπορεί να γίνει διότι πρέπει για μια ακόμα φορά να τονίσουμε ότι κάθε φορά που πάω να πάρω t-log backup αυτός κάνει διαδικασία checkpoint αλλά επειδή η βάση είναι off δεν μπορεί να πάρει και backup. Έτσι παίρνω tail-log backup όπου ρουφάει σαν σκουπα hoover το log file χωρίς να κάνει διαδικασία checkpoint. Μάλιστα από την έκδοση του SQL Server 2005 και σας ζητάει σε κάποιες περιπτώσεις να πάρετε πρώτα tail-log backup και μετά να κάνετε restore. Θα σας εξηγήσω παρακάτω τον τρόπο με τον οποίο μπορείτε να κάνετε κάτι τέτοιο.

File/Filegroup Backup

Είναι το δυσκολότερο σε υλοποίηση backup στον SQL Server μιας και πρέπει να ξέρεις αρκετά πράγματα για το πώς είναι δομημένη η βάση στην οποία θέλεις να το εφαρμόσεις. Ας πάρουμε ένα παράδειγμα για να το κατανοήσουμε καλύτερα. Έστω ότι έχω μια βάση που έχει 2 data files και 1 log file, αν και το log δεν με ενδιαφέρει στο συγκεκριμένο τύπο backup το λέω για να μην υπάρχει κάποια παρεξήγηση. Έστω αυτός που σχεδίασε την βάση αποφάσισε να βάλει τους πίνακες που δέχονται τα transactions πχ τιμολόγια, κινήσεις λογιστηρίου στο 2ο data file και όλους τους άλλους στο 1ο data file. Επίσης αυτή η βάση είναι τεράστια και ο χρόνος που χρειάζεται να την πάρεις full backup είναι 10 ώρες (υπερβολικό μεν αλλά το έχω δει σε βάση που είναι κάτι ΤΒ). Σε αυτή την περίπτωση μπορεί να παίρνεις full backup κάθε Κυριακή και κάθε μέρα στις 05:00 κάνεις bakup μόνο το 2ο data file το οποίο περιέχει τις κινήσεις.

Τώρα κάποιος θα μου πει και το filegroup; Δεν ξέρω αν γνωρίζεται τι είναι το filegroup. Μπορείτε να κοιτάξετε στα BOL του SQL Server αν δεν το ξέρετε, απλά εγώ εδώ θα σας πω ότι είναι λογικές οντότητες μέσα στης οποίες ανήκουν τα data files μιας βάσης. Κάθε filegroup ανήκει σε μια συγκέκριμένη βάση και μπορεί να έχει μέσα του περισσότερα από ένα data files. By default κάθε βάση έχει το primary filegroup στο οποίο ανήκει by default το πρώτο data file της βάσης (.mdf). Εάν στο παραπάνω παράδειγμα αντικαταστήσουμε τα files με filegroup θα έχουμε το ίδιο ακριβώς αποτέλεσμα του backup.

ΠΡΟΣΟΧΗ ΠΡΟΣΟΧΗ ΠΡΟΣΟΧΗ: ΜΕΤΑ ΑΠΟ ΚΑΘΕ FILE/FILEGROUP BACKUP ΠΑΙΡΝΟΥΜΕ Τ-LOG BACKUP. AYTO EINAI ΑΠΑΡΑΒΑΤΟΣ ΚΑΝΟΝΑΣ. Παίζει με Full & Bulk-Logged Recovery Model.

Partial Backup

Στην ουσία είναι το backup κάποιου ή κάποιον filegroup(s). Στο παράδειγμα που σας έδωσα στο file/filegroup backup ας έρθουμε να προσθέσουμε ακόμα ένα data file το οποίο θα ανήκει σε ένα ακόμα filegroup. Έτσι η βάση θα έχει τρία (3) data files έστω τα (a1.mdf,a2.ndf,a3.ndf) και έχω και τρία (3) filegroups το primary που έτσι και αλλιώς το έχω και το fg1 και fg2. Στο primary by default ανήκει το πρώτο data file και έχουμε a2.ndf->fg1 & a3.ndf->fg2. Στο 3ο data file βάζουμε τα δεδομένα που είναι από κλεισίματα προηγούμενων χρήσεων και τα οποία δεν θέλουμε αν τα αλλάζουν οι χρήστες. Αυτό είναι εύκολο να γίνει διότι μπορώ να κάνω το fg2 read-only. Ένα τώρα θελήσω να πάρω partial backup στην ουσία παίρνω full backup απλά προσδιορίζω αν θέλω να πάρω τα read only ή τα read-write filegroups. Παίζει με Full & Bulk-Logged Recovery Model.

Copy Only

Από τον SQL Server 2005 και μετά έχουμε διαθέσιμο τον συγκεκριμένο τύπο και ομολογώ ότι ήταν κάτι το οποίο έλειπε από το εργαλείο. Θα καταφύγω πάλι σε παράδειγμα για την κατανόηση του τύπου αυτού. Έστω ότι σε ημερήσια βάση έχω μια πολιτική για το backup σε μια βάση μου που είναι η εξής:

· Full Backup στις 05:00 πμ

· Transaction Log Backup κάθε μια ώρα

Στις 15:00 έρχεται το αφεντικό και μου λέει "Θέλω να πάρεις την βάση έτσι όπως είναι τώρα και να την βάλει στο laptop μου γιατί θέλω να πάω ένα ταξίδι και θέλω να έχω τα δεδομένα μαζί μου". Στις προηγούμενες εκδόσεις είχα θέμα με τέτοιου είδους ερωτήματα. Εάν για παράδειγμα έκανα το λάθος και έκανα full backup στην ουσία κατέστρεφα την αλληλουχία των t-logs backups από τις 15:00 και μετά, διότι αυτά θα είχαν σαν βάση το full backup που μόλις έκανα. Έτσι στην περίπτωση που θα ήθελα να κάνω restore στην συγκεκριμένη ημέρα δεν θα ξεκίναγα από το full backup που πήρα στις 05:00 αλλά από αυτό που πήρα στις 15:00. Εάν ήθελα να γυρίσω πριν τις 15:00 θα ξεκίναγα από των 05:00, αλλά θα έπρεπε να τα κάνω όλα με την σειρά που τα πήρα και φυσικά θα χρειαζόμουν περισσότερο χρόνο. Βέβαια όλα θα ήταν καλά αν το backup στις 15:00 το κρατούσα στο μέσο που παίρνω τα backups μου. Για σκεφτείτε όμως τι θα γίνει αν μετά από την μεταφορά στο laptop του αφεντικού το έσβηνα; Πολύ απλά αν ήθελα να γυρίσω στην συγκεκριμένη μέρα αυτό θα ήταν εφικτό να γίνει αλλά μέχρι τις 14:00 όπου ήταν τα τελευταίο valid t-log backup.

To Copy Only αυτό ακριβώς το πρόβλημα λύνει. Μπορείς να πάρεις full backup οποιαδήποτε στιγμή μέσα στην ημέρα θέλεις χωρίς να επηρεάζεις την συνέχεια στην πολιτική του backup που έχεις.

How To Backup Database

Αφού είδαμε, και ελπίζω να έγιναν κατανοητοί οι διάφοροι τύποι του backup, είναι η στιγμή να δούμε και πως παίρνουμε backup αυτούς. Για να το κάνουμε αυτό μπορούμε να χρησιμοποιήσουμε το SQL Server Management Studio ή T-SQL. Δεν θα δώσω ιδιαίτερη βάση στο περιβάλλον του SSMS διότι κυρίως το χρησιμοποιούμε για να πάρουμε ad-hoc backups. Το T-SQL είναι αυτό που μας χρειάζεται διότι αφού το δοκιμάσουμε μετά το κάνουμε schedule. Ναι ξέρω τι θα μου πείτε ότι μπορώ να το κάνω schedule και μέσα από τον SSMS (Maintenance Plans, κλπ), δεν θα διαφωνήσω μαζί σας απλά πιστεύω ότι ο καλύτερος τρόπος εκμάθησης είναι με T-SQL.

Backup Devices

Πριν αρχίσω να σας δείχνω τους τρόπους και τις εντολές backup, θέλω να σας πω μερικά πράγματα σχετικά με τα backup devices στα οποία μπαίνουν τα backups που παίρνουμε. Αυτά μπορεί να είναι είτε στον σκληρό δίσκο σας είτε σε ταινία, θα πρέπει όμως να γνωρίζεται ότι η συσκευή της ταινίας πρέπει να είναι φυσικά συνδεδεμένη στη μηχανή στην οποία έχετε βάλει τον SQL Server. Δεν μπορείς π.χ να πάρεις tape backup σε βάση όταν το tape device είναι συνδεμένο στον domain controler server και έχεις σε άλλο server τον SQL Server. Επίσης για τα disk devices αυτά θα πρέπει να είναι δίσκους που βλέπει φυσικά ο server στον οποίο έχουμε εγκαταστήσει τον SQL Server. Εάν θέλουμε να είναι κάποιος share folder μπορεί να γίνει μόνο με UNC Name και όχι με map drive, και φυσικά το account το οποίο ξεκινάει το sql service να έχει τα απαραίτητα read-write permissions σε αυτό.

Για να σας κάνω την ζωή ευκολότερη θα σας έλεγα να θεωρήσετε ότι το backup device είναι μια συρταριέρα με πολλά συρτάρια, όπου το κάθε ένα συρτάρι είναι ένα backup που παίρνουμε, οποιουδήποτε τύπου (full, diff, t-log) και από οποιαδήποτε βάση. Το μόνο που θα πρέπει να ξέρω είναι τι έχω σε κάθε συρτάρι, το οποίο φυσικά δεν χρειάζεται να το θυμάμαι μιας υπάρχει τρόπος που θα δούμε παρακάτω πως γίνεται να βρω τι έχω μέσα σε αυτό. Θα σας έδινα όμως μια συμβουλή και αυτή είναι backup device να είναι με backups από μια συγκεκριμένη βάση ώστε να μην χάσετε την μπάλα.

Υπάρχουν δύο είδη backup devices, τα permanent και τα temporary. Η ουσιαστική διαφορά τους είναι ότι τα permanent τα βλέπεις μέσα από SSMS και μπορείς να τα διαχειριστείς με γραφικό περιβάλλον, ενώ τα temporary μόνο με T-SQL μπορείς να τα διαχειριστείς και φυσικά δεν τα βλέπεις από το SSMS. Υπάρχει ακόμα μία διαφορά σε αυτά και είναι ο τρόπος με τον οποίο δημιουργούνται. Τα permanent δημιουργούνται είτε μέσα από το γραφικό περιβάλλον είτε με T-SQL πριν πάρω κάποιο backup, ενώ τα temporary με την εντολή που θα δώσω για να πάρω backup.

Για να φτιάξω ένα permanent backup device με το SSMS πάω στο Object Explorer Window > Server Objects > Backup Devices > Right Click > New Backup Device. Στο διάλογο που μας δίνεται δίνουμε το όνομα του device και το destination (disk or tape). Ενώ με T-SQL χρησιμοποιώ την sp_addumpdevice πχ

EXEC master.dbo.sp_addumpdevice 'disk', 'demodevice', 'C:\....\demodevice.bak'

GO

Σημείωση : Μέχρι να βάλω το πρώτο backup στο device αυτό δεν υπάρχει σαν αρχείο στο δίσκο αν είναι τύπου disk.

Όπως είπα και παραπάνω για να φτιάξω temporary device αυτό γίνεται μόνο με T-SQL και μόνο κατά την στιγμή που πάω να πάρω backup π.χ.

BACKUP DATABASE demoDB TO DISK='C:\...\tempDevName.bak'

BACKUP LOG demoDB TO DISK='C:\...\tempDevName.bak'

BACKUP Statement

Αντιγραφή από τα SQL Server Books Online.

Backing Up a Whole Database

BACKUP DATABASE { database_name | @database_name_var }

TO <backup_device> [ ,...n ]

[ <MIRROR TO clause> ] [ next-mirror-to ]

[ WITH { DIFFERENTIAL | <general_WITH_options> [ ,...n ] } ]

[;]

Backing Up Specific Files or Filegroups

BACKUP DATABASE { database_name | @database_name_var }

<file_or_filegroup> [ ,...n ]

TO <backup_device> [ ,...n ]

[ <MIRROR TO clause> ] [ next-mirror-to ]

[ WITH { DIFFERENTIAL | <general_WITH_options> [ ,...n ] } ]

[;]

Creating a Partial Backup

BACKUP DATABASE { database_name | @database_name_var }

READ_WRITE_FILEGROUPS [ , <read_only_filegroup> [ ,...n ] ]

TO <backup_device> [ ,...n ]

[ <MIRROR TO clause> ] [ next-mirror-to ]

[ WITH { DIFFERENTIAL | <general_WITH_options> [ ,...n ] } ]

[;]

Backing Up the Transaction Log (full and bulk-logged recovery models)

BACKUP LOG { database_name | @database_name_var }

TO <backup_device> [ ,...n ]

[ <MIRROR TO clause> ] [ next-mirror-to ]

[ WITH { <general_WITH_options> | <log-specific_optionspec> } [ ,...n ] ]

[;]

<backup_device>::=

{

{ logical_device_name | @logical_device_name_var }

| { DISK | TAPE } =

{ 'physical_device_name' | @physical_device_name_var }

}

<MIRROR TO clause>::=

MIRROR TO <backup_device> [ ,...n ]

<file_or_filegroup>::=

{

FILE = { logical_file_name | @logical_file_name_var }

| FILEGROUP = { logical_filegroup_name | @logical_filegroup_name_var }

}

<read_only_filegroup>::=

FILEGROUP = { logical_filegroup_name | @logical_filegroup_name_var }

<general_WITH_options> [ ,...n ]::=

--Backup Set Options

COPY_ONLY

| { COMPRESSION | NO_COMPRESSION }

| DESCRIPTION = { 'text' | @text_variable }

| NAME = { backup_set_name | @backup_set_name_var }

| PASSWORD = { password | @password_variable }

| { EXPIREDATE = { 'date' | @date_var }

| RETAINDAYS = { days | @days_var } }

--Media Set Options

{ NOINIT | INIT }

| { NOSKIP | SKIP }

| { NOFORMAT | FORMAT }

| MEDIADESCRIPTION = { 'text' | @text_variable }

| MEDIANAME = { media_name | @media_name_variable }

| MEDIAPASSWORD = { mediapassword | @mediapassword_variable }

| BLOCKSIZE = { blocksize | @blocksize_variable }

--Data Transfer Options

BUFFERCOUNT = { buffercount | @buffercount_variable }

| MAXTRANSFERSIZE = { maxtransfersize | @maxtransfersize_variable }

--Error Management Options

{ NO_CHECKSUM | CHECKSUM }

| { STOP_ON_ERROR | CONTINUE_AFTER_ERROR }

--Compatibility Options

RESTART

--Monitoring Options

STATS [ = percentage ]

--Tape Options

{ REWIND | NOREWIND }

| { UNLOAD | NOUNLOAD }

--Log-specific Options

{ NORECOVERY | STANDBY = undo_file_name }

| NO_TRUNCATE

Θα σταθώ όμως σε μερικά options του BACKUP statement

Mirror Backup - Enterprise Edition Only

Με το mirror κάνω αυτό που λέει και η λέξη με μια κίνηση έχω δύο devices που περιέχουν το ίδιο backup. Αυτά όμως πρέπει να είναι του ίδιου τύπου πχ disk και όχι το ένα disk και το άλλο tape. Αρκετά χρήσιμο διότι έτσι εξασφαλίζω ότι θα έχω περισσότερη ασφάλεια.

Compression Backup - Enterprise Edition Only

Πολλές φορές μέχρι τώρα για να εξοικονομήσουμε χώρο στο δίσκο αφού τελειώναμε με το backup μας κάναμε compress το device. Πλέον αυτό μπορεί να γίνει αυτόματα από τον SQL Server. Υπάρχει ένα πέναλτι σε χρησιμοποιούμενους πόρους από το σύστημα αλλά είναι πολύ λιγότεροι από αυτούς που χρησιμοποιούσα όταν έκανα μόνος τη διαδικασία με εξωτερικά εργαλεία. Γενικά θα πρέπει να δεις αν το πέναλτι που έχεις αξίζει να το έχεις. Με αυτό θέλω να πω ότι πρέπει να δεις το πόσο compression ratio και αυτό μπορείς να το δεις με αυτό το query

SELECT backup_size/compressed_backup_size FROM msdb.dbo.backupset

Striped Backups

Είναι η δυνατότητα να έχω το backup σε περισσότερα από ένα backup device (μέχρι 64). Χρήσιμο σε περιπτώσεις που βλέπω ότι έχω μια διαδικασία backup να παίρνει μεγάλο χρόνο πχ 4 ώρες, με αυτό μειωνεται ο χρονος στο μισό αν χρησιμοποιήσω 2 backup devices. Ακόμα μια χρήση του είναι όταν έχω πρόβλημα χώρου είτε με το δίσκο που είναι το device είτε με το χώρο τoυ tape (αρκεί βέβαια να έχω δύο tape device).

How To Restore Database

Η διαδικασία του restore χωρίζεται σε τρεις φάσεις:

1. Data Copy Phase

2. Redo Phase

3. Undo Phase and Recovery

Copy Data Phase

Είναι η πρώτη φάση σε κάθε restore που κάνουμε. Σε αυτή την φάση γίνονται copy όλα (data, log, indexes) από τα backup της βάσης στα database files. Με το τέλος της φάσης αυτής όλα τα περιέχομενα της βάσης έχουν γίνει reset στα περιεχόμενα του backup που κάνουμε restore. Αυτό γίνεται με τα full και differential backups.

Redo Phase

Σε αυτή την φάση γίνονται apply όλα τα logged transactions στα δεδομένα που έγιναν copy στην προηγούμενη φάση. Αυτό γίνεται κατά τη στιγμή που γίνονται restore τα transactions log backup. Στην ουσία κοιτάζει ποια transactions που τα logs έχουν δεν υπάρχουν μέσα στα data files και τα κάνει apply.

Undo Phase and Recovery

Με το τέλος της προηγούμενης φάσης το επόμενο βήμα είναι βρει τα transactions τα οποία δεν έχουν γίνει commit και κάνει rollback ότι έχουν αυτά κάνει με σκοπό να κρατηθεί η ακεραιότητα και συνοχή των δεδομένων. Αυτό γίνεται διαβάζοντας τα transaction logs. Αφού τελειώσει με την διαδικασία Undo το επόμενο βήμα είναι να προχωρήσει στην επόμενη εσωτερική εργασία της φάσης αυτή που είναι το Recovery Process με την οποία φέρνει στη βάση σε κατάσταση λειτουργίας (online).

Τι σημαίνουν οι φάσεις αυτές για την διαδικασία Restore;

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

· FULL BACKUP στις 00:00.

· DIFFERENTIAL BACKUP στις 06:00, 12:00, 18:00

· TRANSACTION LOG BACUP κάθε μία ώρα στις εναπομείνασες ώρες

Στη παρακάτω εικόνα βλέπουμε το σενάριο μας.

image

Η ώρα είναι 19:30 και η βάση μας σκάει….

Τι πρέπει να κάνουμε restore και πως;

1. Προσπαθούμε να πάρουμε tail-log backup. Εάν το καταφέρουμε γυρνάμε ακριβώς στο σημείο της πτώσης 19:30. Αλλιώς αναγκαστικά γυρνάμε στις 19:00.

2. Κάνουμε restore to full backup που έχουμε πάρει τα μεσάνυκτα αλλά χωρίς να ενεργοποιήσουμε τις φάσεις 2 & 3. Αυτό γίνεται βάζοντας στην εντολή RESTORE DATABASE το option NORECOVERY. Αυτό το κάνουμε διότι έχουμε να κάνουμε restore και άλλα backups που μας χρειάζονται μέχρι να φτάσουμε στο επιθυμητό σημείου που είναι το σημείο της πτώσης μιας το full backup περιέχει την εικόνα της βάσης όπως ήταν τα μεσάνυκτα.

3. Επειδή στο σενάριο μας έχουμε differential backups το επόμενο βήμα είναι να κάνουμε restore το ποιο πρόσφατο που έχουμε και δεν είναι άλλο από αυτό των 18:00 όπου και αυτό θα γίνει χωρίς να ενεργοποιήσουμε τις φάσεις 2 & 3. (WITH NORECOVERY).

4. Μετά κάνουμε restore το t-log backup που έχουμε μετά και αυτό είναι των 19:00. Εδώ τώρα υπάρχουν δύο δρόμοι.

a. Ο πρώτος δρόμος είναι αυτός που έχει προκύψει από την περίπτωση να μην έχουμε στα χέρια μας tail-log backup. Σε αυτή την περίπτωση με το τέλος του restore θέλουμε να ενεργοποιηθούν οι φάσεις 2 & 3 μιας και δεν έχω κάτι άλλο να κάνω restore έτσι επιλέγω αυτό να το κατεβάζω με την επιλογή WITH RECOVERY, οπότε στο τέλος της θα έχω Online την βάση μου, αλλά θα έχω χάσει αυτή την μίση ώρα.

b. Ο δεύτερος είναι αυτό που έχει προκύψει από τη περίπτωση να έχω tail-log backup στα χέρια μου. Οπότε επειδή έχω να κάνω restore και αυτό, το t-log backup των 19:00 το κάνω restore χωρίς να ενεργοποιήσω τις φάσεις 2 & 3.

5. Εφόσον έχω tail-log backup, το κάνω restore και επιλέγω να γίνουν οι φάσεις 2 & 3 (WITH RECOVERY).

Από το παραπάνω παράδειγμα γίνεται κατανοητό ότι υπάρχει ένας βασικός κανόνας ο οποίος λέει: "ΚΑΝΩ RESTORE ΟΛΑ ΤΑ BACKUPS ΠΟΥ ΕΧΩ ΜΕ ΝΟRECOVERY ΕΚΤΟΣ ΤΟΥ ΤΕΛΕΥΤΑΙΟΥ ΠΟΥ ΤΟ ΚΑΝΩ ΜΕ RECOVERY, ΧΩΡΙΣ ΟΜΩΣ ΝΑ ΞΕΧΝΑΩ ΠΡΙΝ ΚΑΝΩ RESTORE NΑ ΠΡΟΣΠΑΘΗΣΩ ΝΑ ΠΑΡΩ TAIL-LOG BACKUP".

Restore Statement

Αντιγραφή από τα SQL Server Books Online.

--To Restore an Entire Database from a Full database backup (a Complete Restore):

RESTORE DATABASE { database_name | @database_name_var }

[ FROM <backup_device> [ ,...n ] ]

[ WITH

{

[ RECOVERY | NORECOVERY | STANDBY =

{standby_file_name | @standby_file_name_var }

]

| , <general_WITH_options> [ ,...n ]

| , <replication_WITH_option>

| , <change_data_capture_WITH_option>

| , <service_broker_WITH options>

| , <point_in_time_WITH_options—RESTORE_DATABASE>

} [ ,...n ]

]

[;]

--To perform the first step of the initial restore sequence

-- of a piecemeal restore:

RESTORE DATABASE { database_name | @database_name_var }

<files_or_filegroups> [ ,...n ]

[ FROM <backup_device> [ ,...n ] ]

WITH

PARTIAL, NORECOVERY

[ , <general_WITH_options> [ ,...n ]

| , <point_in_time_WITH_options—RESTORE_DATABASE>

] [ ,...n ]

[;]

--To Restore Specific Files or Filegroups:

RESTORE DATABASE { database_name | @database_name_var }

<file_or_filegroup> [ ,...n ]

[ FROM <backup_device> [ ,...n ] ]

WITH

{

[ RECOVERY | NORECOVERY ]

[ , <general_WITH_options> [ ,...n ] ]

} [ ,...n ]

[;]

--To Restore Specific Pages:

RESTORE DATABASE { database_name | @database_name_var }

PAGE = 'file:page [ ,...n ]'

[ , <file_or_filegroups> ] [ ,...n ]

[ FROM <backup_device> [ ,...n ] ]

WITH

NORECOVERY

[ , <general_WITH_options> [ ,...n ] ]

[;]

--To Restore a Transaction Log:

RESTORE LOG { database_name | @database_name_var }

[ <file_or_filegroup_or_pages> [ ,...n ] ]

[ FROM <backup_device> [ ,...n ] ]

[ WITH

{

[ RECOVERY | NORECOVERY | STANDBY =

{standby_file_name | @standby_file_name_var }

]

| , <general_WITH_options> [ ,...n ]

| , <replication_WITH_option>

| , <point_in_time_WITH_options—RESTORE_LOG>

} [ ,...n ]

]

[;]

--To Revert a Database to a Database Snapshot:

RESTORE DATABASE { database_name | @database_name_var }

FROM DATABASE_SNAPSHOT = database_snapshot_name

<backup_device>::=

{

{ logical_backup_device_name |

@logical_backup_device_name_var }

| { DISK | TAPE } = { 'physical_backup_device_name' |

@physical_backup_device_name_var }

}

<files_or_filegroups>::=

{

FILE = { logical_file_name_in_backup | @logical_file_name_in_backup_var }

| FILEGROUP = { logical_filegroup_name | @logical_filegroup_name_var }

| READ_WRITE_FILEGROUPS

}

<general_WITH_options> [ ,...n ]::=

--Restore Operation Options

MOVE 'logical_file_name_in_backup' TO 'operating_system_file_name'

[ ,...n ]

| REPLACE

| RESTART

| RESTRICTED_USER

--Backup Set Options

| FILE = { backup_set_file_number | @backup_set_file_number }

| PASSWORD = { password | @password_variable }

--Media Set Options

| MEDIANAME = { media_name | @media_name_variable }

| MEDIAPASSWORD = { mediapassword | @mediapassword_variable }

| BLOCKSIZE = { blocksize | @blocksize_variable }

--Data Transfer Options

| BUFFERCOUNT = { buffercount | @buffercount_variable }

| MAXTRANSFERSIZE = { maxtransfersize | @maxtransfersize_variable }

--Error Management Options

| { CHECKSUM | NO_CHECKSUM }

| { STOP_ON_ERROR | CONTINUE_AFTER_ERROR }

--Monitoring Options

| STATS [ = percentage ]

--Tape Options

| { REWIND | NOREWIND }

| { UNLOAD | NOUNLOAD }

<replication_WITH_option>::=

| KEEP_REPLICATION

<change_data_capture_WITH_option>::=

| KEEP_CDC

<service_broker_WITH_options>::=

| ENABLE_BROKER

| ERROR_BROKER_CONVERSATIONS

| NEW_BROKER

<point_in_time_WITH_options—RESTORE_DATABASE>::=

| {

STOPAT = { 'datetime' | @datetime_var }

| STOPATMARK = { 'lsn:lsn_number' }

[ AFTER 'datetime' ]

| STOPBEFOREMARK = { 'lsn:lsn_number' }

[ AFTER 'datetime' ]

}

<point_in_time_WITH_options—RESTORE_LOG>::=

| {

STOPAT = { 'datetime' | @datetime_var }

| STOPATMARK = { 'mark_name' | 'lsn:lsn_number' }

[ AFTER 'datetime' ]

| STOPBEFOREMARK = { 'mark_name' | 'lsn:lsn_number' }

[ AFTER 'datetime' ]

}

Παράδειγμα Backup

Ας πάρουμε για παράδειγμα το τελευταίο μας

· FULL BACKUP στις 00:00.

· DIFFERENTIAL BACKUP στις 06:00, 12:00, 18:00

· TRANSACTION LOG BACUP κάθε μία ώρα στις εναπομείνασες ώρες

image

1. Φτιάχνω ένα permanent device

EXEC sp_addumpdevice 'disk','pdev1','c:\temp\pdev1.bak'

GO

2. Παίρνω το Full backup στις 00:00

BACKUP DATABASE BackupDemoDB

TO PDEV1

WITH INIT, STATS

GO

3. Για το Differential backup το statement είναι

BACKUP DATABASE BackupDemoDB

TO PDEV1

WITH DIFFERENTIAL, STATS

GO

3. Για το transaction log backup το statement είναι

BACKUP LOG BackupDemoDB

TO PDEV1

WITH DIFFERENTIAL, STATS

GO

Και όπως είπαμε παραπάνω η βάση μου σκάει στις 19:30

Παράδειγμα Restore

1. Πρώτη κίνηση είναι να πάρω tail-log backup

BACKUP LOG BackupDemoDB

TO PDEV1

WITH NO_TRUNCATE, STATS

GO

2. H επόμενη κίνηση είναι κάνω restore το full backup που έχω από τις 00:00. όμως όλα τα backups τα έχω στο ίδιο backup device. Έτσι πρέπει να μάθω τι θα επιλέξω μέσα από αυτό. Για αυτό το λόγο εκτελώ το statement

RESTORE HEADERONLY FROM PDEV1

Από το αποτέλεσμα που θα δω με ενδιαφέρουν τα πεδία BackupType , Position, και DatabaseName για την περίπτωση που έχω backup από διαφορετικές βάσεις στο ίδιο backup device. Εδώ δεν έχουμε.

Το πεδίο BackupType δείχνει τον τύπο του backup (1=FULL, 5=DIFFERENTIAL, 2=TRANSACTION LOG) και το πεδίο Position την θέση του. Αν θυμάστε πιο πάνω το παράδειγμα με την συρταριέρα είναι ας πούμε το συρτάρι. Έτσι αφού έχουμε τις απαραίτητες πληροφορίες προχωράμε

3. Κάνουμε restore to full backup με ΝΟRECOVERY μιας και πρόκειτε να κάνουμε restore και άλλα backups. Αλλά για να το επιλέξουμε από το backup device χρησιμοποιούμε το FILE=? όπου αντικαθηστούμε το ? με το αριθμό του Position που έχουμε βρει από το βήμα 2 και στο οποίο αντιστοιχεί το Full backup (BackupType=1)

RESTORE DATABASE BackupDemoDB FROM PDEV1 WITH FILE=1, NORECOVERY

4. Κάνουμε restore το differential backup των 18:00

RESTORE DATABASE BackupDemoDB FROM PDEV1 WITH FILE=19, NORECOVERY

5. Κάνουμε restore το t-log backup των 19:00

α. για την περίπτωση που έχουμε tail-log backup από το βήμα 1

RESTORE LOG BackupDemoDB FROM PDEV1 WITH FILE=20, NORECOVERY

β. εάν δεν έχουμε tail-log

RESTORE LOG BackupDemoDB FROM PDEV1 WITH FILE=20, RECOVERY

6. Εφόσον έχουμε tail-log

RESTORE LOG BackupDemoDB FROM PDEV1 WITH FILE=21, RECOVERY

Επίλογος

Σε αυτό το άρθρο σκοπός μου ήταν να κάνω μια καλή εισαγωγή σε αρεκτό βάθος όμως για το τι είναι backup & restore στον SQL Server. Δεν ασχολήθηκα με κάποια σενάρια πχ file/filegroup backup, όμως είναι κάτι που θα το κάνω σύντομα.

Ημερομηνία: 14 March 2010 00:23
Αξιολόγηση: ( 1 )
Tags:
Share it:

Σχόλια - Comments

user-gravatar

Στις 13 Apr 2013 @ 11:42 PM o/η John Sfetsoris έγραψε:

Καλησπέρα πολύ καλή δουλειά όπως και όλες οι άλλες. Συγχαρητήρια :)ΕρώτησηΠως μπορώ να κάνω restore μια βάση που είναι offline ή damaged και να γυρίσω στο σημείο που έπεσε? Ας πούμε έχω full backup στις 5:00, diff στις 9:00, tlog στις 10:00, 11:00 και η βάση πέφτει στις 11:30 και δεν μπορώ να πάρω tail-log αφού η βάση είναι offline, ή damaged, ή deleted ( ή μήπως μπορώ???)ΕυχαριστώΓιάννης Σφετσώρης

user-gravatar

Στις 14 Apr 2013 @ 12:15 AM o/η Antonios Chatzipavlis έγραψε:

Καλησπέρα, δυστυχώς δεν μπορείς να κάνεις και πολλά αν όλα έχουν σβηστεί. Αν όμως είσαι στις άλλες περιπτώσεις και έχεις το transaction log file στην θέση του τότε κάτι μπορείς να γίνει. Υπάρχει μια διαδικασία που ονομάζεται hack-attach και μπορείς να την δεις όπως την περιγράφει ο Paul Randal στα http://www.sqlskills.com/blogs/paul/disaster-recovery-101-hack-attach-a-damaged-database/ και http://www.sqlskills.com/blogs/paul/disaster-recovery-101-backing-up-the-tail-of-the-log/

Αφήστε το σχόλιο σας - Leave your comment

Τα σχόλια έχουν κλείσει.
Επιτρέπονται μόνο τα σχόλια από τα μέλη του SqlSchool.gr.


newsletter subscription

Εάν επιθυμείτε να λαμβάνετε ενημέρωση από εμάς, δώστε μας το e-mail σας.
PASS chapter logo
Official Professional Association for SQL Server (PASS) chapter for Greece
Join to PASS