– Åh, intet tilflugtssted kan modstå et meteornedslag. Men ligesom alle andre har du en backup, så du behøver ikke bekymre dig.
Stanislav Lem, "Stjernedagbøgerne af Ijon Tichy"
Backup refererer til opbevaring af en kopi af data et eller andet sted uden for hovedlagringsstedet.
Hovedformålet med backup er at genoprette data efter tab. Derfor hører man ofte, at med en replika af databasen kan data altid genoprettes, og backup er unødvendig. I virkeligheden løser backup mindst tre opgaver, som ikke kan løses med en replika, og man kan ikke engang initialisere replikaen uden en backup.
For det første gør en backup det muligt at genoprette data efter en logisk fejl. For eksempel, hvis revisoren sletter en gruppe posteringer, eller databasen administratoren ødelægger et tabelrum. Begge operationer er fuldstændig legitime set fra databasen perspektiv, og replikationsprocessen vil gengive dem i replika-databasen.
For det andet er moderne DBMS'er meget pålidelige softwarepakker, men af og til sker der stadig skader på databasen interne strukturer, hvorefter adgangen til data går tabt. Dette er særligt ærgerligt, da sådanne overtrædelser ofte sker under høj belastning eller ved installation af en eller anden opdatering. Men både høj belastning og regelmæssige opdateringer tyder på, at databasen bestemt ikke er testmæssig, og de data, der opbevares i den, er værdifulde.
Endelig er den tredje opgave, hvis løsning kræver en backup, kloning af databasen, for eksempel til testformål.
Backup af databaser er på en eller anden måde baseret på et af to principper:
- Udtagning af data efterfulgt af gemt i et vilkårligt format;
- Snapshot af databasefiler og opbevaring af logs.
Lad os se nærmere på disse principper og de værktøjer, der implementerer dem.
Dataudtræk
Blandt de værktøjer, der følger med enhver DBMS, er der altid værktøjer til at eksportere og importere data. Data gemmes enten i tekstformat eller i et binært format, der er specifikt for den pågældende DBMS. Tabellen nedenfor viser sådanne værktøjer:
Binært format
Tekstformat
Oracle
DataPump Export/DataPump Import
Eksport/Import
SQL*Plus/SQL*Loader
PostgreSQL
pg_dump, pg_dumpall/pg_restore
pg_dump, pg_dumpall/psql
Microsoft SQL Server
bcp
bcp
DB2
unload/load
unload/load
MySQL
mysqldump, mysqlpump/mysql, mysqlimport
MongoDB
mongodump/mongorestore
mongoexport/mongoimport
Cassandra
nodetool snapshot/sstableloader
cqlsh
Den tekstbaserede format er godt, fordi det kan redigeres eller endda oprettes af eksterne programmer, mens det binære format på sin side er godt, fordi det muliggør hurtigere eksport og import af data ved at spare ressourcer på formatkonvertering.
På trods af enkelheden og åbenlyse idéen om datatransport, anvendes denne metode sjældent til at sikkerhedskopiere belastede industrielle databaser. Her er grundene til, at eksport ikke er egnet til fuldgyldig sikkerhedskopiering:
- eksportprocessen skaber en betydelig belastning på kilde-systemet;
- eksporten tager lang tid – ved afslutningen af eksporten vil den allerede være forældet;
- det er praktisk talt umuligt at opnå en sammenhængende eksport af hele databasen under høj belastning, da DBMS er tvunget til at gemme et snapshot af sin tilstand på det tidspunkt, hvor eksporten starter. Jo flere transaktioner der er foretaget siden eksports start, desto større bliver størrelsen af snapshot (forældede data i PostgreSQL, undo-område i Oracle, tempdb i Microsoft SQL Server osv.);
- eksporten bevarer den logiske struktur af data, men ikke den fysiske struktur – parametre for fysisk lagring af tabeller, indekser osv.
Alligevel har eksporten sine fordele:
- høj selektivitet: man kan eksportere specifikke tabeller, specifikke felter og endda specifikke rækker;
- eksporterede data kan indlæses i en database af en anden version, og hvis eksporten er lavet i tekstformat, kan den også indlæses i en anden database.
Derfor bruges eksport primært til opgaver såsom sikkerhedskopiering af små tabeller (f.eks. ordbøger) eller distribution af datasæt med den næste udgivelse af applikationen.
Den mest anvendte metode til sikkerhedskopiering af databaser er dog at kopiere databasefiler.
"Kold" opbevaring af DB-filer
Den åbenlyse idé er at stoppe databasen og kopiere alle dens filer. En sådan sikkerhedskopiering kaldes "kold". Metoden er ekstremt pålidelig og simpel, men den har to åbenlyse ulemper:
- Fra en "kold" backup kan man kun gendanne den tilstand af databasen, der var på tidspunktet for nedlukning; transaktioner, der er foretaget efter genstart af databasen, vil ikke være inkluderet i den "kolde" backup.
- Langt fra hver database har et teknologisk vindue, hvor databasen kan stoppes.
Hvis du er tilfreds med "kold" backup, skal du huske på, at
- "Kold" kopi skal nogle gange også inkludere logs. Metoderne til at bestemme, hvilke logs der skal indgå i "kold" kopien, er individuelle for hver database. For eksempel i Oracle skal man kopiere de såkaldte online redo, som er et bestemt antal logfiler i en særlig mappe, selv når databasen er stoppet korrekt. I PostgreSQL skal alle logs gemmes fra den log, der indeholder det sidste kontrolpunkt, hvis information findes i kontrolfilen.
- Databasen kan indeholde ret store filer af temporære tabeller, som ikke nødvendigvis skal inkluderes i backupen. Forresten er denne bemærkning også korrekt for "hot" backup.
"Hot" filbevaring
De fleste backup af moderne databaser udføres ved at kopiere databaser uden at stoppe dem. Her opstår der flere problemer:
- Ved begyndelsen af kopieringen kan indholdet af databasen ikke stemme overens med indholdet af filerne, da en del information befinder sig i cachen og endnu ikke er skrevet til disken.
- Under kopieringen kan indholdet af databasen ændre sig. Hvis der anvendes muterbare datalagringsstrukturer, ændres indholdet af filerne, og ved brug af uforanderlige strukturer ændres sæt af filer: nye filer vises, og gamle slettes.
- Da skrivning af data til databasen og læsning af databasefiler ikke er synkroniseret, kan backupprogrammet læse en ugyldig side, hvor den ene halvdel er fra den gamle version af siden, og den anden halvdel fra den nye.
For at sikre, at backupen er konsistent, har hver database et kommando, der angiver, at backupprocessen er startet. Syntaktisk kan denne kommando se forskellig ud:
- I Oracle er det en separat kommando ALTER DATABASE/TABLESPACE BEGIN BACKUP;
- I PostgreSQL er det funktionen pg_start_backup();
- I Microsoft SQL Server og DB2 forberedes sikkerhedskopieringen implicit under udførelsen af BACKUP DATABASE-kommandoen;
- I MySQL Enterprise, Cassandra og MongoDB forberedes det implicit af eksterne værktøjer – hhv. mysqlbackup, OpsCenter og Ops Manager.
På trods af syntaktiske forskelle ser forberedelsesprocessen til sikkerhedskopiering ens ud.
Sådan ser forberedelsen til sikkerhedskopiering ud i databaser med ændrede disktopologier, altså i alle traditionelle disk-baserede relationelle systemer:
- Tidspunktet for begyndelsen af sikkerhedskopieringen registreres; sikkerhedskopien skal indeholde databasejournaler fra dette tidspunkt.
- Der udføres et kontrolpunkt, hvilket betyder, at alle ændringer, der skete på datablade før det registrerede tidspunkt, skrives til disken. Dette sikrer, at journalerne før begyndelsen af sikkerhedskopieringen ikke vil være nødvendige ved gendannelse.
- En særlig journaliseringsmodus aktiveres: hvis et datablade ændres første gang efter det er blevet indlæst fra disken, så i stedet for at skrive ændringen af bladet ind i journalen, vil databasen skrive hele bladet. Under forberedelsesproceduren skrives alle blade ud til disken, hvilket betyder, at ved den første ændring vil blokken altid blive skrevet helt ind i journalen. Men hvis bladet igen skrives til disken under sikkerhedskopieringen, vil den næste ændring også resultere i, at en fuld kopi af bladet fremgår i journalen. Dette sikrer, at hvis filen med dataene under kopiering skulle blive beskadiget, vil anvendelsen af journalen gøre den korrekt igen.
- Ændring af headerne på datafilerne blokeres, det vil sige den del, hvis ændringer ikke afspejles i journalerne. Dette sikrer, at headeren kopieres korrekt, og at journalerne derefter anvendes korrekt på datafilerne.
Når alle ovenstående procedurer er udført, kan man kopiere datofiler ved hjælp af operativsystemets værktøjer – cp, rsync og andre. Aktivering af backup-tilstand reducerer databaseydelsen: for det første øges mængden af logs, og for det andet, hvis der opstår fejl under backup-tilstanden, vil gendannelsen tage længere tid, da headerne for datofiler ikke opdateres. Jo hurtigere backupen er afsluttet, desto bedre er det for databasen, så det er passende at anvende værktøjer som snapshots af filsystemet eller BCV (breakable copy volume) i diskarrayet. Nogle databasesystemer (Oracle, PostgreSQL) giver administratoren mulighed for selv at vælge metode til kopiering, mens andre (Microsoft SQL Server) tilbyder et interface til at integrere egne backupværktøjer med filsystemernes eller SAN'ernes mekanismer.
Når backup er afsluttet, skal databasen sættes tilbage til normal tilstand. I Oracle gøres dette med kommandoen ALTER DATABASE/TABLESPACE END BACKUP, i PostgreSQL med funktionen pg_stop_backup(), og i andre databaser med interne underprogrammer fra de relevante kommandoer eller eksterne tjenester.
Her er et eksempel på den tidsmæssige diagram for backup-processen:
- Forberedelse til backup (begin backup) tager tid, undertiden betydelig. Selv når der bruges spejlede volumener eller filsystemer med snapshot-muligheder, vil backup-processen ikke være øjeblikkelig.
- Sammen med datofilerne skal loggene gemmes fra starttidspunktet for backup-forberedelsen til databasen er tilbage i normal tilstand.
- Man kan gendanne fra denne backup på tidspunktet for, at databasen er tilbage i normal tilstand. Gendannelse til et tidligere tidspunkt er ikke muligt.
For databaser, der bruger uforanderlige datastrukturer (snapshots af hukommelse, LSM-træer) er situationen enklere. Forberedelse til backup består af følgende trin:
- Data fra hukommelsen skrives til disk.
- En liste over filer, der indgår i backupen, fastlægges. Indtil backup-processen er afsluttet, er databasen forbudt at slette disse filer, selvom de ikke længere er nødvendige.
Når signalet om afslutning af sikkerhedskopieringen modtages, kan databasen med uforanderlige strukturer igen slette unødvendige filer.
Gendan til punkt
Sikkerhedskopieringen giver mulighed for at gendanne database til det tidspunkt, hvor kommandoen om tilbagevenden fra sikkerhedskopiering blev afsluttet. Imidlertid kan der opstå en nedbrudssituation, som kræver gendannelse, når som helst. Opgaven med at gendanne database til et vilkårligt tidspunkt kaldes 'gendannelse til punkt' (point-in-time recovery).
For at muliggøre denne funktion skal databasen gemme logs fra det øjeblik, sikkerhedskopieringen er afsluttet, og under gendannelsen skal man fortsætte med at anvende logs på den gendannede kopi. Når databasen er gendannet fra sikkerhedskopien ved afslutning af kopieringen, er tilstanden for databasen (filer og cachede sider) garanteret korrekt, så der er ikke behov for en særlig logging tilstand. Ved at anvende logs til det ønskede tidspunkt kan man opnå database tilstanden på ethvert tidspunkt.
Hvis hastigheden af gendannelsen af sikkerhedskopien begrænses af diskens båndbredde, så er hastigheden for anvendelse af logs normalt begrænset af processorens ydeevne. Hvis der foretages ændringer i den primære database parallelt, så bliver alle ændringer gendannet sekventielt – i den rækkefølge, de er læst fra loggen. Således afhænger gendannelsestiden lineært af, hvor langt gendannelsespunktet er fra afslutningspunktet for sikkerhedskopieringen. Derfor er det nødvendigt at lave komplette sikkerhedskopier ret ofte - mindst én gang om ugen for databaser med lille transaktionsbelastning og op til daglige sikkerhedskopier for højtbelastede databaser.
Inkrementel sikkerhedskopiering
For at fremskynde gendannelsen til punkt vil man gerne have mulighed for at udføre sikkerhedskopiering så ofte som muligt, men uden at optage for meget plads på diske og uden at belaste databasen med sikkerhedskopieringsopgaver.
Løsningen på denne opgave er inkrementel sikkerhedskopiering, hvilket vil sige at man kun kopierer de datablade, der er ændret siden den foregående sikkerhedskopiering.
Inkrementel backup giver kun mening for databaser, der bruger ændrede datastrukturer.
Inkrementet kan tælles fra en fuld backup (kumulativ kopi) eller fra en hvilken som helst tidligere kopi (differential kopi).
Desværre findes der ikke en enhedsterminologi, og forskellige producenter bruger forskellige termer:
Differential
Kumulativ
Oracle
Differential
Kumulativ
PostgresPro
Inkrementel
—
Microsoft SQL Server
—
Differential
IBM DB2
Delta
Inkrementel
Når der er inkrementelle kopier, ser processen for gendannelse til et punkt således ud:
- den seneste fulde backup, der blev lavet før gendannelsespunktet, gendannes;
- inkrementelle kopier gendannes oven på den fulde kopi;
- logfiler anvendes fra starten af backupen til gendannelsespunktet.
Tilgængeligheden af en kumulativ kopi fremskynder gendannelsesprocessen. For eksempel kræver gendannelsen af databasen til et punkt mellem T3 og T4 gendannelse af to inkrementelle kopier, mens gendannelsen efter T4 kun kræver én.
Det er åbenlyst, at størrelsen på én kumulativ kopi er mindre end størrelsen på flere differentielle kopier, fordi nogle sider er blevet ændret flere gange, og hver inkrementel kopi indeholder sin version af siden.
Der er tre måder at oprette en inkrementel kopi på:
- oprette en fuld kopi og beregne forskellen fra den tidligere fulde kopi;
- analysere logfiler, oprette en liste over ændrede sider og tage backup af siderne i denne liste;
- forespørge de ændrede sider i databasen.
Den første metode sparer diskplads, men løser ikke opgaven med at reducere belastningen på databasen. Desuden, hvis vi har en fuld backup, er det meningsløst at transformere den til en inkrementel, da gendannelsen af den fulde kopi er hurtigere end gendannelsen af den tidligere fulde kopi og inkrementet. Opgaven med at spare diskplads ved denne tilgang bør bedst overlades til specielle komponenter med indbyggede deduplikeringsmekanismer. Dette kan være både specialiserede lagringssystemer (EMC DataDomain, HPE StorageWorks VLS, hele NetApp-serien) og softwareprodukter (ZFS, Veritas NetBackup PureFile, Windows Server Data Deduplication).
Den anden og tredje metode adskiller sig i, hvordan de bestemmer listen over ændrede sider. Analysering af logfiler er mere ressourcekrævende, og der kræves kendskab til strukturen af logfilerne for at implementere det. At spørge selve databasen, hvilke sider der er ændret, er enklere, men for det skal DBMS-kernen have funktionalitet til at spore ændrede blokke (block change tracking).
Funktionaliteten til inkrementel sikkerhedskopiering blev først skabt i Oracle Recovery Manager (RMAN), som blev introduceret i Oracle 8i. Oracle implementerede straks sporing af ændrede blokke, så der er ikke behov for at analysere logfiler.
PostgreSQL sporer ikke ændrede blokke, så værktøjet pg_probackup, udviklet af det russiske firma Postgres Professional, identificerer ændrede sider ved at analysere loggen. Dog tilbyder virksomheden også DBMS PostgresPro, som inkluderer udvidelsen ptrack, der sporer ændringen af sider. Når man bruger pg_probackup med DBMS PostgresPro, anmoder værktøjet om ændrede sider fra databasen – præcis som RMAN.
Microsoft SQL Server, ligesom Oracle, sporer ændrede sider, men kommandoen BACKUP tillader kun at lave komplette og kumulative sikkerhedskopier.
I DB2 er der mulighed for at spore ændrede sider, men det er som standard deaktiveret. Efter aktivering vil DB2 tillade at lave komplette, differentielle og kumulative sikkerhedskopier.
En vigtig forskel mellem de værktøjer, der er beskrevet i dette afsnit (bortset fra pg_probackup) og filbaserede sikkerhedskopieringsværktøjer er, at de anmoder om sidebilleder fra databasen, i stedet for at læse dataene fra disken selv. Ulempen ved denne tilgang er en lille ekstra belastning på databasen. Men denne ulempe opvejes med god samvittighed, fordi den læste side altid er korrekt, og derfor er der ikke behov for at aktivere en særlig logningsmode under sikkerhedskopieringen.
Bemærk igen, at tilstedeværelsen af inkrementelle kopier ikke annullerer kravene til at have logfiler til at gendanne til et vilkårligt tidspunkt. Derfor bliver logfiler konstant omskrevet til et eksternt medium, og sikkerhedskopier, både komplette og/eller inkrementelle, oprettes efter en fast tidsplan.
Den bedste nuværende implementering af ideen omkring inkrementel sikkerhedskopiering er det programvare-hardware kompleks (i Oracle-terminologi – engineered system) Zero Data Loss Recovery Appliance – en specialiseret løsning fra Oracle til sikkerhedskopiering af sin egen database. Kompleksen er en klynge servere med et stort antal diske, hvorpå der er installeret en modificeret version af Recovery Manager software og kan arbejde både med andre programvare-hardware kompleks fra Oracle (Database Appliance, Exadata, SPARC Supercluster) og med Oracle databaser på traditionel infrastruktur. I modsætning til den "almindelige" RMAN implementerer ZDLRA konceptet "evig inkrement" (incremental forever). Systemet laver én gang en fuld kopi af databasen, hvorefter der kun laves inkrementelle kopier. Yderligere RMAN-moduler giver mulighed for at kombinere kopier og lave nye fulde kopier ud fra inkrementelle.
Til ære for de russiske udviklere skal det bemærkes, at pg_probackup også kan kombinere inkrementelle kopier.
I modsætning til mange lignende spørgsmål, har spørgsmålet "hvilken sikkerhedskopieringsmetode er bedst" et entydigt svar – den bedste metode er den native værktøj til den anvendte databasesystem, der muliggør inkrementel sikkerhedskopiering.
For en databaseadministrator er valget af strategi for sikkerhedskopiering og integrationen af værktøjer til sikkerhedskopiering af databaser i den virksomhedsmæssige infrastruktur betydeligt vigtigere. Men disse emner ligger uden for rammerne af denne artikel.
Kilde: habr.com
