12 veelgemaakte 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 bij hen voorkomen 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 onze e-mail [email protected].

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

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

Als gevolg hiervan blijft het systeem onbeschermd vanaf het moment dat de laatste back-up wordt verwijderd tot het moment dat de nieuwe wordt gemaakt, omdat de database gedurende deze periode geen enkele back-up heeft. Omdat het maken van een back-up behoorlijk lang kan duren, is het het perfecte moment voor de wet van Murphy om in werking te treden. Deze aanpak werkt vooral goed in combinatie met punt 7 (zie hieronder).

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

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

2. Een bestaande database overschrijven tijdens het herstellen vanuit een back-up

Deze fout komt minder vaak voor, maar de gevolgen kunnen veel erger zijn. Als de back-up niet is geverifieerd en beschadigd blijkt te zijn (zie punt 6), heb je noch de vorige databasekopie, noch een geldige back-up.

Zo’n puinhoop gebeurt meestal op een vrijdagavond wanneer het hectisch is en de aanwijzingen van het management nogal tegenstrijdig zijn. Een beetje pech en een langzaam weekend in de serverruimte is jouw deel.

Firebird heeft een soort bescherming tegen deze fout: het is niet mogelijk om een database vanuit een back-up te herstellen met behulp van het hulpprogramma gbak als de standaard schakelaar -create 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 maakt het nog steeds mogelijk 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 omdat dit nooit het databasebestand overschrijft.

3. Een eenstaps back-up/herstel gebruiken zonder een tussenliggend back-upbestand

Standaard invoer-/uitvoerstromen maken het mogelijk om een grappige truc uit te halen met veel DBMS’en (waaronder Firebird): een streaming back-up implementeren met direct herstel van de database. Er wordt daardoor geen tussenliggend back-upbestand gemaakt. Het is handig voor routinematig onderhoud en voor het uitvoeren van een testherstel (op voorwaarde dat er een andere back-up beschikbaar is), maar je mag het niet gebruiken voor automatische back-ups!

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

Aanbevelingen: gebruik geen eenstaps back-up/herstel in de automatische modus en controleer altijd in de handmatige modus of er een voldoende actuele kopie beschikbaar is.

4. Back-ups en de database op hetzelfde fysieke apparaat opslaan

Velen van jullie vinden het misschien grappig dat het advies dat we geven nogal kinderlijk is - het ABC van back-ups. Dat klopt, maar door de populariteit van virtuele omgevingen kunnen de database en de schijf op één gegevensopslagsysteem terechtkomen. En het zal zeker falen op het meest ongelegen moment. 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 bepaalde “merk”-servers onfeilbaar zijn, maar dat is een speciaal geval.

Aanbevelingen: bewaar back-ups en de database niet op één apparaat, hoe betrouwbaar het ook lijkt.

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

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

Een oplettende lezer die dit punt in ons artikel heeft bereikt (hoewel het nog te vroeg is om daarvoor een prijs uit te reiken) zou kunnen vragen: ‘Maar wat heeft dit met het management te maken?’ Hier is het antwoord: de beheerder configureert meestal het back-upproces, maar vindt het te saai om meldingen te controleren, vooral wanneer ze in een aparte map worden opgeslagen, dus het is nooit te veel gevraagd om aanvullende rapporten over de status van het proces te eisen. Het gaat om de vraag wie de schuldige is wanneer het lijkt alsof er back-ups zijn, maar ze er op het moment dat je ze nodig hebt niet zijn :)

! in combinatie met punt 2 hebben we noch de database, noch de back-up.

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 beheren).

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

6. Geen back-upvalidatie

Het feit dat back-ups ergens worden opgeslagen, betekent niet dat ze daar ook kunnen worden gelezen.

Daarom moet je regelmatig de back-ups die je maakt 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-ups

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

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

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

Bij 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-ups die het maakt kopieën van databasepagina’s zijn en als er een fout op recordniveau zit (als gevolg van een RAM-storing) of op logisch niveau, zal een niet-geverifieerde back-up deze net zo goed bevatten als de originele database.

Om dit te voorkomen, moet je online validatie voor de originele 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 een geverifieerde back-up uit te voeren (bijvoorbeeld één keer per week) naast de niet-geverifieerde back-up.

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

8. Geen controle over de vrije ruimte voor back-ups

Eigenlijk is het een klassieke fout: als er niet genoeg ruimte is, nemen back-ups alle vrije ruimte in beslag en eindigt het proces met een fout. Het opslaan van back-ups op dezelfde schijf als de database kan leiden tot een onderbreking van de databasewerking en het opslaan op de systeemschijf kan leiden tot een systeemstoring.

In combinatie met punt 4 is het best mogelijke resultaat dat het systeem stopt met functioneren omdat de database ook vrije ruimte nodig heeft, maar die wordt ingenomen door back-ups. Wat betreft combinaties met punten 5 en 2, blijven we opnieuw achter zonder zowel de database als de back-up.

Aanbevelingen: gebruik back-up tools die de back-upgrootte voorspellen en je waarschuwen voor mogelijk onvoldoende 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-up te maken

Het back-upproces duurde letterlijk een half jaar geleden 40 minuten en plotseling duurt het al drie uur - waarom? De database kan groter zijn geworden of een schijf kan uit je RAID-array zijn gevallen, wat resulteert in aanzienlijk lagere schrijfprestaties en al je back-ups kunnen op het punt staan om te verdwijnen. Of een goede collega van je heeft tegelijkertijd nog een back-upsysteem uitgevoerd (trouwens, Firebird staat toe dat je meerdere back-upprocessen tegelijk uitvoert, hoewel het niet helemaal duidelijk is waarom iemand dat nodig zou hebben). Als je de tijd die nodig is om een back-up 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 groot wordt.

Bovendien, als het back-upsysteem de status van back-uptaken niet bewaakt en ze alleen volgens schema uitvoert, kun je gemakkelijk “op de zaken vooruitlopen”, wat betekent dat het systeem een nieuw back-upproces start terwijl het vorige nog niet is afgerond.

Aanbevelingen: gebruik tools die de tijd van het back-upproces controleren!

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

10. Back-up van de database terwijl er updates van het besturingssysteem worden toegepast

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

Aanbevelingen: plan updates van het besturingssysteem op momenten dat ze niet interfereren met het back-upproces.

11. Back-up van de database met behulp van bestandsback-up tools of back-up tools 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 databasebestanden zelf in de willekeurige toegangsmodus zijn geopend. Daarom is het noodzakelijk om speciale back-uptypen te gebruiken in plaats van alleen bestandsback-up (inclusief het simpelweg kopiëren van databasebestanden) of de back-up van virtuele machines. Bestandsback-up tools lezen de database sequentieel en dit kan behoorlijk lang duren, vooral bij grote databases, dus het is onmogelijk om de integriteit van de gemaakte back-up 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 databaseback-upkopie te verkrijgen, omdat de back-upkopie inconsistent zal zijn in geval van actieve schrijfbewerkingen met de database op het moment van het sorteren van de verzameling 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. DBMS-services en -processen volledig afsluiten, zodat er niets in de cache staat,
2. agents en/of scripts gebruiken die de database overschakelen naar een speciale modus die het veilig maakt om het databasebestand sequentieel te kopiëren. Er is bijvoorbeeld een mechanisme genaamd VSS writer voor MSSQL-databases. Op verzoek schakelt het de database over naar de snapshot-vriendelijke modus op het moment dat een snapshot wordt gemaakt. Als u mechanismen gebruikt die zijn gebaseerd op Changed Block Tracking, moet u zelf ervoor zorgen dat de database consistent is op het moment van synchronisatie.

Als u de database niet overschakelt naar de back-upvriendelijke modus, zal de resulterende databasekopie eruitzien alsof er een harde reset (bijvoorbeeld een stroomstoring) heeft plaatsgevonden op de hostcomputer. Dit niveau van betrouwbaarheid is absoluut onvoldoende voor de meeste bedrijven. U kunt hier meer over lezen in het artikel “Eigenaardigheden van het werken met databases op virtuele machines”.

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

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

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

Aanbevelingen: gebruik geen bestands- en VM-back-uptools zonder de bijbehorende automatiseringshulpmiddelen voor databases.

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

12. Back-up vervangen door replicatie

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

Iedereen houdt van replicatie vanwege de mogelijkheid om gegevens op een andere server met minimale vertraging te synchroniseren, maar back-up heeft ook onbetwiste voordelen. Bijvoorbeeld, in geval van onbedoelde (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 kost enige moeite om zowel replicatie als back-up correct te configureren en toch blijft de mogelijkheid van fouten bestaan.

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

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

Samenvatting

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

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

Daarnaast biedt ons bedrijf volledige back-up- en onderhoudsondersteuning 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 natuurlijk, blijf uw admin-paranoia koesteren, sta bijvoorbeeld op en controleer uw back-upkopieën nu meteen :)

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