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

Σήμερα θα σας απασχολήσω με ένα θέμα το οποίο αφορά το backup. Aν και είναι Enterprise edition feature διαπίστωσα ότι ακόμα και αυτοί που διαθέτουν την συγκεκριμένη έκδοση αγνοούν αυτό, τουλάχιστον η πλειοψηφία.

Αυτό δεν είναι άλλο από την δυνατότητα να έχω MIRROR Backup στα backups τα οποία εκτελώ στον SQL Server.

Είναι γνωστό ότι κάθε backup που παίρνω μπαίνει σε ένα backup device το οποίο είτε μπορεί να είναι disk based είτε tape based. Επίσης αυτό  μπορεί να είναι logical (permanent  όπως οι παλαιότεροι λέμε) ή physical (temporary όπως οι παλαιότεροι λέμε).

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

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

Έστω ότι κάθε βράδυ κάποια ώρα έχω προγραμματίσει να εκτελώ ένα full backup στην Χ database. Είναι γνωστό φαντάζομαι ότι το full backup αποτελεί την βάση για τα επόμενα backups διαφορετικού τύπου όπως differential, transaction log backups κ.λπ.

Με βάση τις ανάγκες μου που βγαίνουν από την απάντηση που έχω δώσει στα RTO (Recovery Time Objective) & RPO (Recovery Point Objective) έχω διαμορφώσει ένα backup strategy για την συγκεκριμένη database. Έστω  λοιπόν ότι αυτό ορίζει ότι μετά από το full backup κάθε μια ώρα εκτελώ transaction log backup και κάθε 6 ώρες παίρνω differential backup.

Όλα αυτά σαν βάση έχουν το full backup που εκτέλεσα το βράδυ. Σε περίπτωση που το μέσο που έχω αποθηκεύσει κάποιο από τα συγκεκριμένα χαλάσει τότε σπάει η αλληλουχία και δεν μπορώ να φτάσω μέχρι το σημείο της πτώσης με ένα ομαλό τρόπο αλλά θα πρέπει να κάνω διάφορα δύσκολα πράγματα τα οποία δεν εγγυούνται 100% επιτυχία. Για αυτό λοιπόν θα πρέπει να είμαι προστατευμένος όσο το δυνατόν περισσότερο.

Αυτό στο παρελθόν δεν ήταν εύκολο να γίνει και περιείχε αρκετή ποσότητα συμβιβασμού που δεν υλοποιούσε το τι αποζητούσαμε στα RTO & RPO. Αρκετοί μετά το τέλος του νυκτερινού full backup εκτελούσαν αμέσως μετά ξανά την ίδια διαδικασία και έπαιρναν ένα ακόμα full backup. Αυτό είχε σαν συνέπεια όλα τα επόμενα backups (diff, tlog … ) σαν βάση είχαν τον τελευταίο. Αν αυτό δεν ήταν δυνατόν να γίνει restore τότε πηγαίνεις το προηγούμενο στο οποίο όμως δεν πατούν στο επόμενα, αποτέλεσμα να μπορείς να γυρίσεις στην στιγμή που αυτό είχε ολοκληρωθεί.

Εφόσον λοιπόν έχω ένα critical σύστημα το οποίο έχω σε Enterprise Edition του SQL Server  από 2008 και πάνω μπορώ να διεξάγω Mirror backups.
Κάθε εικόνα θα πρέπει για ευνόητους λόγους (αν χαλάσει το ένα να έχω το άλλο) να είναι σε διαφορετικό δίσκο αν  πχ παίρνω disk backup ή σε διαφορετικό tape να κάνω backup σε τέτοιο.

Επίσης θα πρέπει να επισημανθεί ότι όλα τα backup devices που εμπλέκονται σε μια τέτοια διαδικασία θα πρέπει να είναι του ίδιου τύπου. Δεν μπορώ να έχω πχ κάποια από αυτά να είναι disk και κάποια να είναι tape. Για να εκτελεστεί η συγκεκριμένη διαδικασία θα πρέπει να γράψω το backup statement καθώς από το SSMS UI αυτό δεν είναι μπορεί να γίνει.

Τέλος σε κάθε backup μπορώ πέρα από το βασικό device να έχω ακόμα τρία backup devices τα οποία στην ουσία παίζουν και το ρόλο των mirrors, στο σύνολο τους έχω τέσσερα που δεν είναι καθόλου κακό τι λέτε;

Κλείνοντας θα πρέπει να αναφέρω ότι η επιβάρυνση στην όλη διαδικασία είναι πάντα σχετική με το μέγεθος της database το είδος του backup και την ταχύτητα του μαγνητικού μέσου. Από την εμπειρία μου σε περιβάλλοντα παραγωγής αυτή είναι μεταξύ 8-14%.

Ένα παράδειγμα

-- CREATE SOME LOGIGAL (PERMANENT) DEVICES

exec sp_addumpdevice 'disk',dev1, 'F:\backup\dev1.bak'
exec sp_addumpdevice 'disk',dev2, 'G:\backup\dev2.bak'
exec sp_addumpdevice 'disk',dev3, 'H:\backup\dev3.bak'
exec sp_addumpdevice 'disk',dev4, 'I:\backup\dev4.bak'

-- FULL BACKUP 

BACKUP DATABASE [demo] 
TO dev1
MIRROR TO dev2 
MIRROR TO dev3
MIRROR TO dev4
GO

-- TRANSACTION LOG BACKUP

BACKUP LOG [demo] 
TO dev1
MIRROR TO dev2 
MIRROR TO dev3
MIRROR TO dev4
GO

-- DIFFERENTIAL BACKUP

BACKUP DATABASE [demo] 
TO dev1
MIRROR TO dev2 
MIRROR TO dev3
MIRROR TO dev4
WITH DIFFERENTIAL
GO

-- TAIL LOG TRANSACTION LOG BACKUP

BACKUP LOG [demo] 
TO dev1
MIRROR TO dev2 
MIRROR TO dev3
MIRROR TO dev4
WITH NO_TRUNCATE
GO

BACKUP LOG [demo] 
TO dev1
MIRROR TO dev2 
MIRROR TO dev3
MIRROR TO dev4
WITH NORECOVERY
GO

Keep Rocking with SQL Server

/*antonch*/