En guide till backup av databaser

– O, inget skydd kan stå emot en meteorits träff. Men precis som alla har ni en reserv, så ni behöver inte oroa er.

Stanislaw Lem, "Stjärndagböckerna av Ijon Tichy"

Säkerhetskopiering kallas för att spara en kopia av data någonstans utanför det primära lagringsstället.

Huvudsyftet med säkerhetskopiering är att återställa data efter att de har gått förlorade. Därför hörs det ofta att om det finns en kopia av databasen kan man alltid återställa data från den, och säkerhetskopiering är inte nödvändig. I verkligheten hjälper säkerhetskopiering till att lösa minst tre problem som inte kan lösas med en kopia, och man kan inte heller initiera en kopia utan en backup.

För det första möjliggör en säkerhetskopiering återställning av data efter en logisk felaktighet. Till exempel, om en bokförare har raderat en grupp transaktioner eller om en databasadministratör har förstört ett tabellutrymme. Båda operationerna är helt legitima i förhållande till databasen, och replikeringen kommer att återge dem i repliken.

För det andra är moderna databashanteringssystem mycket pålitliga programvaror, men ibland kan även interna strukturer i databasen skadas, vilket gör att åtkomst till data försvinner. Särskilt frustrerande är det att sådana störningar vanligtvis sker under hög belastning eller vid installation av någon uppdatering. Men både hög belastning och regelbundna uppdateringar innebär att databasen inte är en testversion, och data som lagras i den är värdefulla.

Slutligen, den tredje uppgiften som kräver tillgång till en säkerhetskopiering är kloning av databasen, till exempel för teständamål.

Säkerhetskopiering av databaser baseras på antingen av de två principerna:

• Utsökning av data med efterföljande lagring i ett godtyckligt format;
• Ett ögonblick av databasens filers tillstånd och lagring av loggar.

Låt oss gå igenom dessa principer och verktygen som implementerar dem mer i detalj.

Export av data

I uppsättningen verktyg som medföljer varje databashanteringssystem finns det nödvändigtvis verktyg för export och import av data. Data kan sparas antingen i textformat eller i ett binärt format som är specifikt för det aktuella databashanteringssystemet. Tabellen nedan visar sådana verktyg:

Binärt format
Textformat

Oracle
DataPump Export/DataPump Import
Exportera/Importera
SQL*Plus/SQL*Loader

PostgreSQL
pg_dump, pg_dumpall/pg_restore
pg_dump, pg_dumpall/psql

Microsoft SQL Server
bcp
bcp

DB2
unload/ladda
unload/ladda

MySQL

mysqldump, mysqlpump/mysql, mysqlimport

MongoDB
mongodump/mongorestore
mongoexport/mongoimport

Cassandra
nodetool snapshot/sstableloader
cqlsh

Textformatet är bra eftersom det kan redigeras eller till och med skapas av externa program, medan det binära formatet å sin sida är bra eftersom det möjliggör snabbare exportering och importering av data genom att spara resurser vid omvandling av format.

Trots enkelheten och tydligheten i idén att exportera data används denna metod sällan för att säkerhetskopiera belastade industriella databaser. Här är anledningarna till varför export inte är lämplig för en fullständig säkerhetskopiering:

• exportprocessen skapar en betydande belastning på källsystemet;
• exporten tar mycket tid - vid tidpunkten för exportens avslutande kommer den redan att vara föråldrad;
• att göra en konsekvent export av hela databasen vid hög belastning är praktiskt taget omöjligt, eftersom DBMS måste lagra en avbildning av sitt tillstånd vid tidpunkten för exportens början. Ju fler transaktioner som har genomförts sedan exportens början, desto större blir volymen av avbildningen (föråldrade kopior av data i PostgreSQL, undo-utrymme i Oracle, tempdb i Microsoft SQL Server, osv.);
• exporten bevarar den logiska strukturen hos data, men inte deras fysiska struktur - parametrarna för den fysiska lagringen av tabeller, index m.m.

Trots detta har export också sina fördelar:

• hög selektivitet: det går att exportera enskilda tabeller, specifika fält och till och med enskilda rader;
• de exporterade data kan laddas in i en databas av en annan version, och om exporten görs i textformat, även i en annan databas.

Således används export huvudsakligen för sådana uppgifter som säkerhetskopiering av små tabeller (t.ex. referenstabeller) eller distribution av datamängder med nästa version av applikationen.

Den vanligaste metoden för säkerhetskopiering av databaser är att kopiera databasfilerna.

"Kall" säkerhetskopiering av databasfiler

En uppenbar idé är att stoppa databasen och kopiera alla dess filer. En sådan säkerhetskopiering kallas "kall". Metoden är extremt pålitlig och enkel, men den har två uppenbara nackdelar:

• Från en "kall" säkerhetskopiering kan endast den databasens tillstånd återställas som fanns vid tidpunkten för stoppet; transaktioner som utförts efter att databasen startat igen kommer inte att ingå i den "kalla" säkerhetskopieringen;
• Det finns inte alltid ett tekniskt fönster för varje databas där databasen kan stoppas.

Om "kall" säkerhetskopiering passar dig, behöver du komma ihåg att

• "kall" kopia ibland måste inkludera loggar. Metoder för att bestämma vilka loggar som ska ingå i den "kalla" kopian är individuella för varje DBMS. Till exempel, i Oracle är det nödvändigt att kopiera så kallade online redo, det vill säga ett bestämt antal loggfiler i en speciell mapp, även när databasen stoppas korrekt. I PostgreSQL måste alla loggar sparas från loggen som innehåller den senaste kontrollpunkten, information om vilken finns i kontrollfilen.
• Databasens katalog kan innehålla ganska stora filer för temporära tabellutrymmen som inte nödvändigtvis behöver inkluderas i säkerhetskopieringen. För övrigt är denna observation också giltig för "het" säkerhetskopiering.

"Het" filbevarande

De flesta säkerhetskopior av moderna databaser görs genom att kopiera databasfiler utan att stoppa databasen. Här syns flera problem:

• Vid början av kopieringen kan innehållet i databasen skilja sig från innehållet i filerna, eftersom en del information finns i cachen och ännu inte är skriven till disken.
• Under kopieringen kan innehållet i databasen förändras. Om föränderliga datatyper används, ändras filinnehållet, och vid användning av oföränderliga strukturer ändras filuppsättningen: nya filer dyker upp medan gamla tas bort.
• Eftersom skrivning av data till databasen och läsning av DB-filer inte är synkroniserade kan säkerhetskopieringsprogrammet läsa en felaktig sida, där hälften är från den gamla versionen av sidan och den andra hälften är från den nya.

För att säkerhetskopian ska bli konsekvent finns det en kommando för varje DBMS som signalerar att säkerhetskopieringsprocessen har påbörjats. Syntaktiskt kan detta kommando se olika ut:

• i Oracle är det ett separat kommando ALTER DATABASE/TABLESPACE BEGIN BACKUP;
• i PostgreSQL – funktionen pg_start_backup();
• I Microsoft SQL Server och DB2 förbereds säkerhetskopieringen implicit under exekveringen av kommandot BACKUP DATABASE;
• I MySQL Enterprise, Cassandra och MongoDB förbereds det implicit av externa verktyg – mysqlbackup, OpsCenter och Ops Manager respektive.

Trots syntaktiska skillnader ser processen för förberedelse av säkerhetskopiering likadan ut.

Så här ser förberedelsen för säkerhetskopiering ut i databashanterare med änderliga diskstrukturer, det vill säga i alla traditionella disk-baserade relationssystem:

1. Tidpunkten för början av säkerhetskopieringen registreras; säkerhetskopian måste innehålla databasloggar från denna tidpunkt.
2. En kontrollpunkt utförs, vilket innebär att alla ändringar som har skett i databladen fram till den registrerade tidpunkten skrivs till disk. Detta säkerställer att loggarna fram till början av säkerhetskopieringen inte krävs vid återställning.
3. Ett särskilt loggningsläge aktiveras: om ett datablad ändras första gången efter att det har laddats från disk, kommer databasen att skriva hela sidan till loggen istället för att registrera förändringen. Vid den förberedande proceduren skrivs alla sidor ut till disk, och därför kommer den första förändringen alltid att skrivas helt till loggen. Men om sidan under säkerhetskopieringen skrivs ut till disk igen, kommer nästa förändring också att leda till en fullständig kopia av sidan i loggen. Detta säkerställer att om sidan blir felaktig vid kopiering av datafilen, gör loggen den korrekt igen.
4. Ändringar av databasfilernas huvuden blockeras, det vill säga den del av dem vars förändringar inte återspeglas i loggarna. Detta säkerställer att huvudet kopieras korrekt och att loggarna sedan tillämpas korrekt på datafilen.

När alla ovan nämnda procedurer har slutförts kan man kopiera datafiler med hjälp av operativsystemets verktyg – cp, rsync och andra. Aktivering av backupsystemet minskar databasens prestanda: för det första ökar volymen av loggar, och för det andra, om det under backupsystemet skulle uppstå ett fel, kommer återställningen att ta längre tid, eftersom filrubrikerna inte uppdateras. Ju snabbare backupen avslutas, desto bättre för databasen, därför är det lämpligt att använda verktyg som snapshots av filsystemet eller BCV (break copy volume) i RAID-arrayen. Vissa DBMS (Oracle, PostgreSQL) ger administratören möjlighet att själv välja kopieringsmetod, medan andra (Microsoft SQL Server) erbjuder ett gränssnitt för att integrera egna backupverktyg med filsystemets eller lagringssystemets mekanismer.

Efter att backupen har slutförts måste databasen återställas till sitt normala tillstånd. I Oracle görs detta med kommandot ALTER DATABASE/TABLESPACE END BACKUP, i PostgreSQL - genom att anropa funktionen pg_stop_backup(), och i andra databaser - med interna rutiner från motsvarande kommandon eller externa tjänster.

Så här ser tidsdiagrammet för backup-processen ut:

• Förberedelser för backup (begin backup) tar tid, ibland betydande. Även om speglade volymer eller filsystem med snapshots används, kommer backup-processen inte att vara ögonblicklig.
• Tillsammans med datafilerna måste loggarna sparas från början av backupförberedelserna till ögonblicket då databasen återställs till normalt tillstånd.
• Det går att återställa från denna backup vid tidpunkten då databasen återställs till normalt tillstånd. Återställning till en tidigare tidpunkt är inte möjligt.

För databaser som använder oföränderliga datakonstruktioner (minnessnapshots, LSM-träd) är situationen enklare. Förberedelserna för backup består av följande steg:

1. Data från minnet skrivs till disken.
2. En lista över filer som ingår i backupen registreras. Så länge backup-processen pågår är databasen förbjuden att ta bort dessa filer, även om de blir onödiga.

Vid signal om att säkerhetskopieringen är klar kan databasen med oföränderliga strukturer åter igen radera onödiga filer.

Återställning till punkt

En säkerhetskopiering tillåter att återställa databasen till det tillstånd den hade när kommandot för återgång från säkerhetskopieringsläge avslutades. Men en krasch som kräver återställning kan inträffa när som helst. Uppgiften att återställa databasens tillstånd till en godtycklig tidpunkt kallas "återställning till punkt" (point-in-time recovery).

För att möjliggöra detta bör loggar för databasen sparas från och med det att säkerhetskopieringen avslutades, och under återställningsprocessen ska loggar fortsätta att tillämpas på den återställda kopian. När databasen har återställts från säkerhetskopian vid tidpunkten för avslutningen av kopieringen, är tillståndet för databasen (filer och cachade sidor) garanterat korrekt, så en speciell loggningsmetod behövs inte. Genom att tillämpa loggar fram till den önskade tidpunkten kan man få databasens tillstånd vid vilken tidpunkt som helst.

Om hastigheten för återställning av säkerhetskopian begränsas endast av diskens bandbredd, är hastigheten för tillämpning av loggarna vanligtvis begränsad av processorns prestanda. Om ändringar i den primära databasen sker parallellt, utförs alla ändringar sekventiellt vid återställning – i den ordning de läses från loggen. Därför är återställningstiden linjärt relaterad till hur långt återställningspunkten ligger från tidpunkten för avslutningen av säkerhetskopieringen. Detta gör att man måste göra fullständiga säkerhetskopior ganska ofta – minst en gång i veckan för databaser med låg transaktionsbelastning och upp till en gång om dagen för högbelastade databaser.

Inkrementell säkerhetskopiering

För att snabba upp återställningen till punkt vill man gärna kunna utföra säkerhetskopiering så ofta som möjligt, men samtidigt inte upptar för mycket utrymme på diskarna och inte belastar databasen med säkerhetskopieringsuppgifter.

Lösningen på problemet är inkrementell säkerhetskopiering, det vill säga att endast de datorsidor som har ändrats sedan den senaste säkerhetskopieringen kopieras.
Inkrementell säkerhetskopiering är meningsfullt endast för databashanterare som använder föränderliga datastrukturer.

Inkrementet kan räknas från en fullständig säkerhetskopia (kumulativ kopia) eller från vilken tidigare kopia som helst (differentiell kopia).

Tyvärr finns det ingen enhetlig terminologi, och olika tillverkare använder olika termer:

Differentiell
Kumulativ

Oracle
Differential
Cumulative

PostgresPro
Inkrementell
—

Microsoft SQL Server
—
Differential

IBM DB2
Delta
Inkrementell

Vid förekomsten av inkrementella kopior ser återställningsprocessen till en viss punkt ut på följande sätt:

• den senaste fullständiga säkerhetskopian som gjorts innan återställningen återställs;
• inkrementella kopior återställs över den fullständiga kopian;
• loggar tillämpas från den punkt där säkerhetskopiering påbörjades till återställningspunkten.

När en kumulativ kopia finns tilhandahåller det en snabbare återställningsprocess. Till exempel, för att återställa databasen till en punkt mellan T3 och T4, måste två inkrementella kopior återställas, medan endast en behövs för att återställa efter T4.
Det är uppenbart att volymen av en kumulativ kopia är mindre än volymen av flera differentiella kopior, eftersom vissa sidor kan ha ändrats flera gånger och varje inkrementell kopia innehåller sin version av sidan.

Det finns tre sätt att skapa en inkrementell kopia:

1. skapa en fullständig kopia och beräkna skillnaden mot den föregående fullständiga kopian;
2. bearbeta loggar, skapa en lista över ändrade sidor och säkerhetskopiera sidorna i listan;
3. fråga databasen efter ändrade sidor.

Det första sättet sparar diskutrymme, men löser inte problemet med att minska belastningen på databasen. Dessutom, om vi har en fullständig säkerhetskopia, är det meningslöst att omvandla den till en inkrementell, eftersom återställning av en fullständig kopia är snabbare än att återställa en tidigare fullständig kopia och inkrementet. Problemet med att spara diskutrymme med en sådan metod bör bättre överlämnas till speciella komponenter med inbyggda dedupliceringsmekanismer. Detta kan vara antingen speciella lagringssystem (EMC DataDomain, HPE StorageWorks VLS, hela NetApp-sortimentet) eller programprodukter (ZFS, Veritas NetBackup PureFile, Windows Server Data Deduplication).

Den andra och tredje metoden skiljer sig åt i hur de identifierar listan över ändrade sidor. Att bearbeta loggar är mer resurskrävande, plus att för att genomföra det måste man känna till loggfilernas struktur. Att fråga databasen själv vilka sidor som har ändrats är det enklaste, men för detta måste databashanteringssystemets kärna ha funktionalitet för att spåra ändrade block (block change tracking).

Funktionen för inkrementell säkerhetskopiering skapades först i Oracle Recovery Manager (RMAN), som introducerades i Oracle 8i. Oracle implementerade omedelbart spårning av ändrade blok, så det finns ingen anledning att bearbeta loggar.

PostgreSQL spårar inte ändrade block, därför identifierar verktyget pg_probackup, som utvecklades av det ryska företaget Postgres Professional, ändrade sidor genom att analysera loggarna. Men företaget tillhandahåller även databashanteringssystemet PostgresPro, som inkluderar tillägget ptrack, som spårar ändringar av sidor. När pg_probackup används med PostgresPro-framställningen begär verktyget ändrade sidor direkt från databasen – precis som RMAN.

Microsoft SQL Server, precis som Oracle, spårar ändrade sidor, men kommandot BACKUP tillåter endast att göra fulla och kumulativa säkerhetskopior.

I DB2 finns möjlighet att spåra ändrade sidor, men som standard är den avstängd. När den aktiveras tillåter DB2 att göra fullständiga, differentierade och kumulativa säkerhetskopior.

En viktig skillnad mellan verktygen som beskrivs i den här avsnittet (förutom pg_probackup) och filbaserade säkerhetskopieringsverktyg är att de begär sidbilder från databasen, snarare än att läsa data från disken själva. Nackdelen med detta tillvägagångssätt är en viss extra belastning på databasen. Dock kompenseras denna nackdel mer än väl av att den lästa sidan alltid är korrekt, varför det inte finns något behov av att aktivera ett särskilt loggningsläge under säkerhetskopieringen.

Observera återigen att närvaron av inkrementella kopior inte upphäver kraven på att ha loggar för återställning till en godtycklig tidpunkt. Därför skrivs loggar kontinuerligt över på extern lagring i industriella databaser, och säkerhetskopior, både fullständiga och/eller inkrementella, skapas enligt schema.

Den bästa implementeringen av idén om inkrementell säkerhetskopiering idag är den program- och hårdvarukonfiguration (i Oracle-terminologi – engineered system) Zero Data Loss Recovery Appliance – en specialiserad lösning från Oracle för säkerhetskopiering av egen databas. Konfigurationen består av en kluster servrar med en stor mängd diskar, på vilka en modifierad version av Recovery Manager-programvaran är installerad och kan arbeta både med andra program- och hårdvarukonfigurationer från Oracle (Database Appliance, Exadata, SPARC Supercluster) samt med Oracle-databaser på traditionell infrastruktur. Till skillnad från "vanlig" RMAN implementerar ZDLRA konceptet "evig inkrement" (incremental forever). Systemet skapar en fullständig kopia av databasen en enda gång, och sedan gör det endast inkrementella kopior. Ytterligare RMAN-moduler möjliggör att kopior kombineras, vilket skapar nya fullständiga kopior från inkrementella.

Till den ryska utvecklarnas ära bör det noteras att även pg_probackup kan kombinera inkrementella kopior.

Till skillnad från många liknande frågor har frågan "vilken säkerhetskopieringsmetod är bättre" ett entydigt svar – den bästa är det inbyggda verktyget för den använda DBMS som möjliggör inkrementell säkerhetskopiering.

För databasutvecklaren är frågor om val av säkerhetskopieringsstrategi och integration av databaslagringslösningar i företagsinfrastrukturen mycket viktigare. Men dessa frågor ligger utanför ramen för denna artikel.

Källa: habr.com