Hoe implementeer je back-ups met InterBase XE7 online dump

Dmitry Kuzmenko, 08-SEP-2016

InterBase ondersteunt sinds versie 2007 online dump - het online kopiëren van databasebestanden. In plaats van gbak -b/-c kun je hiermee na het kopiëren een direct bruikbare database verkrijgen, en je hoeft deze niet te “herstellen” vanuit een back-up (iets dat geen database is). Online dump is zeer snel, bijna net zo snel als het kopiëren van bestanden door het besturingssysteem.

Gebruik de volgende opdracht om een online dump van de database te maken

gbak -d [opties] database doel

(De volledige beschrijving van de dump vind je in de documentatie, Doc\OpGuide.pdf, of hier)

Net als bij het databasebestand mag het doel elke gewenste naam en extensie hebben. Het resultaat van de opdracht is een dumpbestand dat gelijkwaardig is aan de originele database, maar in alleen-lezen modus.

De tijd van de eerste uitvoering van deze opdracht is de tijd om de brondatabase te scannen (lezen) plus de tijd om het doelbestand te schrijven.

Zolang het doel in alleen-lezen modus is, is het gekoppeld aan het databasebestand. Bij de eerste dump wordt het volledige databasebestand gelezen en naar het doel gekopieerd. Bij de tweede en volgende dumps worden alleen gewijzigde pagina’s naar het doel geschreven. Dit wordt een “incrementele dump” genoemd.

Belangrijk! InterBase XE7 leest bij elke herhaalde dumpopdracht (uiteraard met dezelfde bestandsnamen) alleen gewijzigde pagina’s van de database en schrijft deze naar het doel. Andere versies vóór XE7 lezen de volledige brondatabase. De prestaties verschillen dus, en XE7 is veel sneller. Als er geen pagina’s in de brondatabase zijn gewijzigd, duurt een incrementele dump in XE7 ongeveer 1 seconde, terwijl InterBase2007-XE3 de tijd nodig heeft om het volledige databasebestand te lezen. De tijd hangt af van de grootte van de brondatabase en de opslagsnelheid. Bij een opslagsnelheid van ongeveer 400 MB/sec wordt een database van 100 GB bijvoorbeeld in 250 seconden gescand (4 min 10 sec).

Opmerking. InterBase XE7 ondersteunt databasebestandsindelingen van XE7 (ODS 16), XE/XE3 (ODS 15) en 2009 (ODS 13). De hierboven genoemde slimme scanfunctie werkt alleen met het databaseformaat van XE7 (ODS 16).

Als je het doel in de lees-schrijfmodus (normale modus) wilt zetten, gebruik dan de opdracht

gfix doel -mode read_write

Maar daarna verliest het doel de koppeling met de database, en is het vervolgens onmogelijk om gbak -d database doel opnieuw uit te voeren, omdat het doel als een “andere” database wordt beschouwd.

Als je het doel volledig wilt overschrijven in plaats van een incrementele dump, gebruik dan de optie -ov

gbak -d -ov database doel

Dump van de dump

De eerste dump van de dump werkt, maar de daaropvolgende incrementele dumps niet. Bijvoorbeeld, eerst

gbak -d database doel1

hier krijgen we doel1 als een volledige gedumpte database in alleen-lezen modus

Vervolgens,

gbak -d doel1 doel2

Zoals je ziet, maken we een dump van de dump. En ja, deze opdracht kopieert doel1 naar doel2. Beide doelen bevinden zich in de alleen-lezen modus. Maar als we deze twee opdrachten opnieuw uitvoeren, worden wijzigingen die van de database naar doel1 zijn gegaan niet naar doel2 gekopieerd. Doel2 blijft dus in de staat na de eerste, initiële kopie. En er worden geen fout- of waarschuwingsmeldingen gegeven.

Dus als je ooit een dump van een dump wilt maken, moet je alleen een volledige dump gebruiken

gbak -d -ov doel1 doel2

De optie -ov is verplicht om ervoor te zorgen dat doel2 wordt geschreven (en overschreven) met de bron van doel1.

Back-upschema 1

Voorbeeld van dumps op verschillende tijdsintervallen

gbak -d database doel

Wordt bijvoorbeeld elk uur uitgevoerd. Hier hebben we een productiebrondatabase en een “back-up”kopie doel, die één uur achterloopt.

Daarnaast kunnen we elke 24 uur ook uitvoeren

gbak -d database doel2

Hier hebben we de productiedatabase, doelkopie die 1 uur achterloopt, en doel2-kopie die 24 uur achterloopt.

Je kunt een willekeurig aantal dumps van één database maken.

Het spreekt voor zich dat doeldumps als alleen-lezen databases kunnen worden gebruikt voor elk doel - rapportage, analyses, enz., voor taken die niet in de actuele database hoeven te kijken.

Voordeel: Elke dump kan onafhankelijk worden gepland.

Nadeel: Vertragingen tussen de nieuwste en oudste dump.

Back-upschema 2

Sequentiële dump naar verschillende doelen. In dit geval moet je een planner (OS of aangepast) instellen om de volgende opdrachten één keer per opgegeven tijdsinterval uit te voeren

gbak -d database doel1

gbak -d database doel2

gbak -d database doel3

Als je een interval van 1 uur tussen deze opdrachten gebruikt, krijg je dumps (back-ups) zoals:

doel1 om 12:00, doel2 om 13:00, doel3 om 14:00. De volgende uitvoering van dump doel1 wordt om 15:00 bijgewerkt, enzovoort. Als resultaat hebben we kopieën van de databases van de afgelopen 3 uur.

Voordeel: we hebben dumps voor meerdere uren die dicht bij de originele database blijven

Nadeel: het is iets lastiger om deze opdrachten te plannen. In dit voorbeeld moeten dumpopdrachten bijvoorbeeld op exacte tijden worden gepland:

Dump naar doel1 om 00:00, 03:00, 06:00…

Dump naar doel2 om 01:00, 04:00, 07:00…

Dump naar doel3 om 02:00, 05:00, 08:00…

Samenvatting

Gbak -d kan worden gebruikt voor een dump naar lokale opslag en voor een dump via het netwerk - omdat een incrementele dump alleen gewijzigde pagina’s naar het doel stuurt. Het doel kan dus op een externe netwerkopslag worden geplaatst. Maar uiteraard moet het netwerk voldoende bandbreedte hebben om vergelijkbaar te zijn met lokale opslag. Anders zijn schrijfbewerkingen naar het doel traag.

Online dump kan niet alleen worden gebruikt als hulpmiddel om een online back-upkopie van de database te maken, maar ook als hulpmiddel voor “horizontale schaling” van het systeem, om de belasting van productie-, rapportage- en analyseapplicaties in evenwicht te brengen.

Hoewel je ziet dat online dump de snelste manier is om een online databasekopie te verkrijgen (in plaats van gbak -b/-c), kan dump, omdat het met pagina’s werkt, bepaalde schade aan pagina’s overslaan als de database beschadigd is. Daarom moet je de databaseconsistentie nog steeds controleren met de oude vertrouwde gbak -b/-c, maar je kunt dit minder vaak doen dan voorheen.