12 veelvoorkomende fouten bij het back-uppen van databases

door Alexey Kovyazin, 11 november 2015

Download PDF (Engels) Dit artikel was oorspronkelijk bedoeld voor Firebird DBMS-ontwikkelaars en -beheerders, maar contacten met beheerders van andere databases maakten duidelijk dat de meeste fouten ook onder hen gemeengoed zijn en dat letterlijk iedereen over bijna dezelfde stenen struikelt. Als je iets aan deze lijst kunt toevoegen (zelfs iets specifieks voor een bepaald DBMS), neem dan contact met ons op via ons e-mailadres [email protected].

1. De vorige back-upkopie verwijderen voordat een nieuwe back-upkopie is gemaakt

Deze fout komt het meest voor bij beginners die zich niet realiseren dat het hoofddoel van een back-upkopie van een database niet alleen is om een kopie van de database te maken, maar om de downtime van een informatiesysteem (waarvan de database een belangrijk onderdeel is) zo kort mogelijk te houden.

Als gevolg daarvan blijft het systeem onbeschermd vanaf het moment dat de laatste back-upkopie wordt verwijderd tot het moment dat de nieuwe wordt gemaakt, omdat de database in deze periode geen enkele back-upkopie heeft. Aangezien het maken van een back-upkopie behoorlijk wat tijd kan kosten, is dit het perfecte moment voor de wet van Murphy om in werking te treden. Deze aanpak werkt vooral goed in combinatie met Probleem 7 (zie hieronder).

Aanbevelingen: verwijder de vorige back-upkopie niet voordat de nieuwe is gemaakt! (en maak geen nieuwe back-upkopie naar een bestaand bestand).

Aanbeveling voor Firebird: Er is een FBDataGuard-tool opgenomen in HQbird (een geavanceerd distributiepakket van Firebird) die de vroegste back-upkopie in de geschiedenis pas verwijdert nadat een nieuwe is gemaakt.

2. Een bestaande database overschrijven tijdens het herstellen ervan uit een back-upkopie

Deze fout komt minder vaak voor, hoewel de gevolgen veel erger kunnen zijn. Als de back-upkopie niet is geverifieerd en beschadigd blijkt te zijn (zie Probleem 6), heb je noch de vorige kopie van de database, noch een geldige back-upkopie.

Een puinhoop als deze gebeurt meestal op een vrijdagavond wanneer het hectisch wordt en wanneer de aanwijzingen van het management nogal tegenstrijdig worden. Een beetje pech en een langdurig weekend in de serverruimte ligt voor je klaar.

Firebird heeft enige bescherming tegen deze fout - het zal niet mogelijk zijn om een database uit een back-upkopie te herstellen met behulp van het gbak-hulpprogramma als de standaard -create-schakelaar is ingeschakeld en als de opgegeven bestandsnaam naar een bestaande database verwijst. Helaas is er een manier om deze bescherming te omzeilen: de -rep-schakelaar staat nog steeds toe om het bestaande bestand te overschrijven.

Aanbeveling: overschrijf nooit het bestand van een werkende database zonder een schriftelijke opdracht van je management.

Aanbeveling voor Firebird: Gebruik FBDataGuard, want het overschrijft nooit het databasebestand.

3. Back-up/herstel in één stap gebruiken zonder een tussenliggend back-upbestand

Standaard in-/uitvoerstromen maken het mogelijk om met veel DBMS’en (waaronder Firebird) een grappige truc uit te halen: een streaming back-up implementeren waarbij de database er direct uit wordt hersteld. Als gevolg daarvan wordt er geen tussenliggend back-upbestand gemaakt. Het is handig voor routineonderhoud en voor het uitvoeren van een testherstelbewerking (mits er een andere back-upkopie beschikbaar is), maar je mag het niet gebruiken voor automatische back-up!

Als er zich bijvoorbeeld een ernstige schijffout voordoet tijdens dit back-up/herstelproces, kan de oorspronkelijke database beschadigd raken terwijl er nog geen nieuwe database is gemaakt. Als je natuurlijk rekening houdt met Probleem 1 en er een databasekopie van de vorige poging is, gaan alleen de gegevens verloren die in de database zijn aangemaakt of bijgewerkt nadat die kopie werd gemaakt.

Aanbevelingen: gebruik geen back-up/herstel in één stap in de automatische modus en controleer in de handmatige modus altijd de beschikbaarheid van een kopie die actueel genoeg is.

4. Back-upkopieën en de database opslaan op één en hetzelfde fysieke apparaat

Velen van jullie vinden het misschien grappig dat het advies dat we geven nogal kinderachtig is - het abc van back-up. Dat klopt, maar de database en de schijf kunnen door de populariteit van virtuele omgevingen op één en hetzelfde gegevensopslagsysteem terechtkomen. En het zal zeker op het meest ongelegen moment falen. Bovendien zijn er nog steeds mensen die geloven dat er niets met hun gegevens kan gebeuren als ze RAID-arrays gebruiken (versie 1 of hoger :)). Daarnaast zijn er mensen die geloven dat sommige “merk”-servers faalvrij zijn, maar dat is een speciaal geval.

Aanbevelingen: sla back-upkopieën en de database niet op één apparaat op, hoe betrouwbaar het ook mag lijken.

5. Geen controle over de succesvolle voltooiing van het back-upproces

Het is een vrij veelvoorkomende fout bij zowel beheerders als het hoofd van IT-afdelingen. Als je de resultaten van het back-upproces niet controleert, kun je het net zo goed helemaal niet uitvoeren. Je moet meldingen ontvangen over het succesvol voltooide back-upproces per e-mail of, nog beter, ook via sms. En de afwezigheid van dergelijke meldingen is een teken van een probleem!

Een oplettende lezer die tot dit punt in ons artikel is gekomen (hoewel het nog te vroeg is om daarvoor een prijs te geven) kan vragen: ‘Maar wat heeft dat met het management te maken?’ Dit is wat - de beheerder configureert meestal het back-upproces, maar hij vindt het te saai om meldingen te controleren, vooral wanneer ze in een aparte map worden opgeslagen, dus het kan geen kwaad om aanvullende rapporten over de status van het proces aan te vragen. Het gaat om de vraag wie de schuldige is wanneer het lijkt alsof er back-upkopieën waren, maar ze er op het moment dat je ze nodig hebt eigenlijk niet zijn :)

! eenmaal gecombineerd met Probleem 2, hebben we noch de database noch de back-upkopie ervan.

Aanbevelingen: gebruik back-upautomatiseringstools die succesvolle en mislukte back-upprocessen kunnen bewaken, gebruikers op de hoogte stellen van problemen en samenvattende controletools bieden (dit is vooral relevant wanneer je tientallen en honderden back-upprocessen op verschillende servers moet controleren).

Aanbeveling voor Firebird: FBDataGuard controleert of het back-upproces is voltooid en stuurt de bijbehorende melding. Voor systemen met veel databases is er samenvattende monitoring op tweede niveau met behulp van de Control Center-tool waarmee je de statussen van alle bewaakte servers en databases op één pagina kunt zien.

6. Geen back-upvalidatie

Het feit dat back-upkopieën ergens zijn opgeslagen, betekent niet dat ze daaruit kunnen worden gelezen.

Daarom moet je de back-upkopieën die je maakt regelmatig verifiëren om er zeker van te zijn dat ze niet beschadigd zijn of naar /dev/null zijn gekopieerd.

Aanbeveling voor Firebird: je kunt back-upvalidatie automatiseren met behulp van FBDataGuard.

7. Geen databasegezondheidscontroles bij het gebruik van niet-geverifieerde back-upkopieën

Meestal gebruiken databases verschillende soorten back-up - dumps, reguliere back-upkopieën, enz. Zonder in details te treden, kunnen we twee categorieën onderscheiden: geverifieerd en niet-geverifieerd. In het geval van Firebird zijn dat gbak en nbackup.

Gbak leest de hele database op het niveau van records om een back-upbestand te maken en maakt een database door records in een nieuwe database in te voegen, waardoor de back-upkopie wordt geverifieerd (er zijn manieren waarop fouten in de herstelde kopie kunnen sluipen, maar dat is een andere manier waarop de databasebeheerder dingen kan verprutsen met betrekking tot slecht georganiseerde migratie) en de database zelf (als deze van begin tot eind kan worden gelezen, is deze hoogstwaarschijnlijk niet beschadigd).

Nbackup (ook wel incrementele back-up genoemd) vergrendelt tijdelijk het hoofd databasebestand voor updates (in de consistente staat) en maakt het mogelijk om het databasebestand snel te kopiëren (volledig of gedeeltelijk/incrementeel).

In het geval van grote Firebird-databases (groter dan 500 GB) is het raadzaam om nbackup te gebruiken om gebruikersbewerkingen niet te vertragen, maar tegelijkertijd is het noodzakelijk om de database te valideren, omdat de niet-geverifieerde back-upkopieën die het maakt, kopieën van databasepagina’s zijn en als er een fout op het niveau van records zit (als gevolg van een RAM-storing) of op logisch niveau, zal een niet-geverifieerde back-upkopie deze ook bevatten, net als de oorspronkelijke database.

Om dit te voorkomen, moet je online validatie voor de oorspronkelijke database gebruiken (online validatie met behulp van gfix is beschikbaar vanaf Firebird-versie 2.5.4, terwijl onze FBDataGuard-tool online databasevalidatie ondersteunt voor versies 1.5-2.5).

Het is ook raadzaam om af en toe (bijvoorbeeld één keer per week) een geverifieerde back-up uit te voeren naast een niet-geverifieerde back-up.

Aanbeveling voor Firebird: naast online gezondheidscontrole stelt FBDataGuard je in staat om het back-upherstelproces in de automatische modus te testen.

8. Geen controle over vrije ruimte voor back-upkopieën

Eigenlijk is het een klassieke fout: als er niet genoeg ruimte is, nemen back-upkopieën alle vrije ruimte in beslag en eindigt het proces met een fout. Het opslaan van back-upkopieën op één schijf met de database kan leiden tot een onderbreking in de werking van de database en het opslaan ervan op de systeemschijf kan resulteren in een systeemstoring.

In combinatie met Probleem 4 is de best mogelijke uitkomst die waarbij het systeem stopt met functioneren omdat de database ook vrije ruimte nodig heeft, maar die wordt ingenomen door back-upkopieën. Wat betreft de combinatie met Problemen 5 en 2, die laat ons weer met noch de database noch de back-upkopie ervan achter.

Aanbevelingen: gebruik back-uptools die de back-upgrootte voorspellen en je waarschuwen voor het mogelijke gebrek aan vrije ruimte.

Aanbeveling voor Firebird: FBDataGuard controleert de grootte van de vrije ruimte voor back-updoeleinden en ook de grootte van de vrije ruimte op de schijf met databases en op de systeemschijf.

9. Geen controle over de tijd die nodig is om een back-upkopie te maken

Het back-upproces duurde letterlijk een half jaar geleden 40 minuten en dan plotseling duurt het al drie uur - hoe komt dat? De grootte van de database is mogelijk toegenomen of er is een schijf uitgevallen uit je RAID-array, wat heeft geleid tot aanzienlijk tragere schrijfprestaties, en al je back-upkopieën staan op het punt deze wereld te verlaten. Of een goede collega van je heeft nog een back-upsysteem tegelijkertijd gestart (trouwens, Firebird staat toe om meerdere back-upprocessen tegelijkertijd uit te voeren, hoewel het niet helemaal duidelijk is waarom iemand dat ooit nodig zou hebben). Als je de tijd die nodig is om een back-upkopie te maken niet controleert, kun je een nieuw ontstaan probleem over het hoofd zien en de kans missen om het op te lossen voordat het massaal wordt.

Bovendien, als het back-upsysteem de statussen van back-uptaken niet bewaakt en ze gewoon volgens schema uitvoert, kun je gemakkelijk “te vroeg van start gaan”, wat betekent de situatie waarin het systeem een nieuw back-upproces start terwijl het vorige nog niet is afgelopen.

Aanbevelingen: gebruik tools die de tijd controleren die het back-upproces in beslag neemt!

Aanbeveling voor Firebird: FBDataGuard controleert de tijd die het back-upproces in beslag neemt.

10. Een back-up van de database maken terwijl updates van het besturingssysteem worden toegepast

Het is een heel veelvoorkomend probleem, vooral in combinatie met Probleem 9 en ingeschakelde automatische Windows-updates (standaard worden updates om 3 uur ’s nachts toegepast). Het leidt in het beste geval tot een vertraging, maar als het besturingssysteem opnieuw wordt opgestart om de updates toe te passen, raakt de back-upkopie beschadigd. Het goede nieuws is tenminste dat het besturingssysteem niet elke dag wordt bijgewerkt.

Aanbevelingen: plan updates van het besturingssysteem in wanneer ze het back-upproces niet verstoren.

11. Een back-up van de database maken met behulp van bestandsback-uptools of back-uptools voor virtuele machines terwijl de databaseserver draait

Veel beheerders vergeten dat elk DBMS een actieve en complexe cache heeft die gegevens bevat die worden gelezen en geschreven, terwijl de databasebestanden zelf in de random-access-modus worden geopend. Daarom is het noodzakelijk om speciale back-uptypes te gebruiken in plaats van de loutere bestandsback-up (inclusief het simpelweg kopiëren van databasebestanden) of de back-up van de virtuele machine. Bestandsback-uptools lezen de database sequentieel en dat kan behoorlijk lang duren, vooral bij grote databases, dus het is onmogelijk om de integriteit van de gemaakte back-upkopie te garanderen.

Virtuele machines kunnen gebruikmaken van de mechanismen van snapshots en Changed Block Tracking, maar het is noodzakelijk om de gemaakte back-upkopieën te synchroniseren om een consistente back-upkopie van de database te verkrijgen, omdat de back-upkopie inconsistent zal zijn in geval van actieve schrijfbewerkingen op de database op het moment van het verzamelen van de gewijzigde blokken.

Voor degenen die hun databases willen back-uppen met behulp van bestands- of virtuele-machine-back-uptools, kunnen we twee methoden aanbieden:

1. sluit de DBMS-services en -processen volledig af, zodat er niets in de cache staat,
2. gebruik agents en/of scripts die de database in een speciale modus zetten waardoor het veilig is om het databasebestand sequentieel te kopiëren. Er bestaat bijvoorbeeld een mechanisme genaamd VSS writer voor MSSQL-databases. Op verzoek schakelt het de database naar de snapshot-vriendelijke modus op het moment dat een snapshot wordt gemaakt. Als u mechanismen gebruikt op basis van Changed Block Tracking, moet u er zelf voor zorgen dat de database consistent is op het moment van synchronisatie.

Als u de database niet naar de back-upvriendelijke modus schakelt, zal de resulterende databasekopie eruitzien alsof er een harde reset (bijvoorbeeld een stroomstoring) heeft plaatsgevonden op de hostcomputer. Dit betrouwbaarheidsniveau is absoluut onvoldoende voor de meeste bedrijven. U kunt hier meer over leren in het artikel “Peculiarities of Working with Databases on Virtual Machines”.

Voor Firebird is het noodzakelijk om het hoofdbestand van de database met behulp van nbackup te vergrendelen voordat het back-upproces begint en het te ontgrendelen nadat het proces is voltooid. Voor andere DBMS’en bestaan er vergelijkbare tools om de overeenkomstige modi in/uit te schakelen.

Sommige databasebeheerders zijn ervan overtuigd dat ze hun databases veilig kunnen back-uppen met behulp van standaard bestandsback-uptools als het DBMS een transactielogboek heeft, omdat hooguit alleen dit logboek beschadigd zal raken. Het is een gevaarlijke misvatting die DBMS-ontwikkelaars niet ondersteunen.

De wortels van deze misvatting zijn duidelijk: agressieve reclame door de ontwikkelaars van virtuele machines en back-uptools vermeldt gewoonlijk niet dat databases evenals andere intensief bijgewerkte bestanden geavanceerde configuratie vereisen. Geloof de hype niet - niet alle yoghurts hebben gelijke voordelen.

Aanbevelingen: gebruik geen bestands- en VM-back-uptools zonder de overeenkomstige automatiseringstools voor databases.

Aanbeveling voor Firebird: gebruik FBDataGuard (uit het HQbird-distributiepakket), het biedt integratie met VSS-bewuste back-uptools.

12. Back-up vervangen door replicatie

Gegevensback-up en gegevensreplicatie worden gebruikt om de betrouwbaarheid te vergroten en gegevensverlies te voorkomen, maar toch zijn ze heel verschillend.

Iedereen houdt van replicatie vanwege de mogelijkheid om gegevens op een andere server te synchroniseren met minimale vertraging, maar back-up heeft ook enkele onbetwiste voordelen. Bijvoorbeeld, in geval van accidentele (of opzettelijke) gegevensverwijdering zal replicatie de wijzigingen snel en onverstoorbaar naar de replica sturen, terwijl back-up (vooral met kopieën op alleen-lezen media) immuun is voor dergelijke bewerkingen. Het vergt de nodige inspanning om zowel replicatie als back-up correct te configureren en toch bestaat de mogelijkheid van fouten altijd.

Aanbevelingen: Als u replicatie hebt geconfigureerd, verwaarloos dan de back-upkopieën niet, gebruik beide.

Aanbeveling voor Firebird: gebruik het HQbird Enterprise-distributiepakket, het bevat zowel back-up- als replicatietools.

Samenvatting

Het is niet zo eenvoudig om back-up voor uw favoriete DBMS te configureren, dus gewoonlijk gebruiken databasebeheerders van organisaties waar ze hun gegevens waarderen professionele back-uptools waarmee ze rekening kunnen houden met de hierboven genoemde kwesties en de problemen kunnen voorkomen.

Voor Firebird (excuses voor de reclame) bestaat er een pakket genaamd HQbird dat FBDataGuard bevat.

Ook biedt ons bedrijf volledige back-up- en ondersteuningsdiensten voor Firebird en andere databases; dit is een goede keuze voor degenen die niet op de hoogte zijn van alle technische details van back-ups.

En koester natuurlijk uw beheerdersparanoia, bijvoorbeeld: sta op en controleer nu meteen uw back-upkopieën :)

Contacten

Stel gerust al uw vragen: [email protected]

Wilt u nieuws en artikelen over Firebird ontvangen? Sluit u bij ons aan op Telegram https://t.me/firebirdsql