Backup en Recovery, of Recovery en Backup ?
Een nieuw hightech tape-backup systeem met een groot aantal tapes wordt geïntroduceerd bij een bedrijf. Een procedure wordt ingericht om elke avond een backup te maken. Enkele maanden later vindt er een systeem crash plaats, en is alle data verloren. Enige oplossing is een backup terugplaatsen. De laatste tape-backup wordt van stal gehaald en de restore procedure wordt gestart. De tape blijkt leeg. De tape van de vorige dag wordt geprobeerd, ook deze blijkt leeg. Alle tapes worden gecontroleerd en blijken allemaal leeg te zijn.
De backup en recovery procedures waren goed getest, hoe kan het nu dat de tapes leeg waren ?
Achteraf blijkt de persoon die de tapes naar de externe locatie moet brengen, ook steeds even een broodjeswinkel binnen gaat om een broodje te halen. Bij de ingang in deze winkel staan detectie poortjes die er kennelijk voor zorgen dat de tapes 'gewist' worden.
Stel je voor dat bovenstaand verhaal in jouw organisatie gebeurd, wat zijn de gevolgen ? Is het zo ernstig dat het bedrijf haar deuren kan sluiten, of staat jouw baan op de tocht omdat er zoveel verlies is geleden ?
Indien er over backup gesproken wordt, dient er niet alleen naar het ‘veiligstellen’ van de gegevens gekeken te worden. Er moet ook zeker aandacht te zijn voor de restore procedure.
Onze stelling is dan ook: “een backup is geen backup totdat je een goede, volledige test recovery hebt uitgevoerd”
Beveiligingsplan opstellen
Om een goed ‘beveiligingsplan’ voor je gegevens op te stellen zijn er twee vragen die beantwoord moeten worden:
Wat ? Wat zijn de zogenaamde “Recovery Time Objectives (RTO)”, “Recovery Point Objectives (RPO), en backup retentie policies
Hoe ? Hoe ga je de eisen gesteld aan de eerdere wat vraag nu in de praktijk brengen ?
De RTO wordt bepaalde door antwoord op de vraag: Hoe lang mag de downtime van het systeem duren ?
Om de RPO te bepalen moet je denken aan vragen zoals: Mag er data verloren gaan, en zoja, hoe veel (moeten we terug kunnen tot 5 minuten voor de crash, een dag of een week ?). Is het nodig om de gegevens te herstellen naar de status zoals deze een half jaar geleden was ?
Kortom, de business zal betrokken moeten worden bij de Wat vraag.
Hoe gaan we de business eisen nu implementeren, en welke kosten zijn hiermee gemoeid ?
Wat gaat het het business kosten als de databases niet beschikbaar zijn of de gegevens corrupt raken ‘versus’ wat zijn de kosten voor hardware en software om de downtime en corruptie van gegevens te minimaliseren.
Implementatie
Momenteel biedt Oracle al vele features biedt om je gegevens te beschermen. Denk hierbij aan de Flash Recovery Area, Data Guard etc. Toch is er nog steeds behoefte aan een backup. Er zijn zeer veel verschillende methoden om je backup/recovery uit te voeren. De meeste bekende zijn wel de cold en hot-backup. Bij een offline backup (cold) wordt de database down gebracht en worden de benodigde bestanden veiliggesteld zodat er een consistente backupset ontstaat. Bij een onlinebackup (hot) zal de database 'up and running' blijven tijdens de backup procedure.
De "online backup en recovery feature" is geïntroduceerd in Oracle Version 6 (1988). In Oracle Version 7 (1992) werd de Enterprise Backup Utility (EBU) meegeleverd, dit was eigenlijk de voorloper van de huidige RMAN utility.
RMAN
De meest gebruikte backup methode die Oracle nu kent is RMAN. RMAN is een utility waarmee het mogelijk is om backup, restore en recover operaties uit te voeren. RMAN wordt meegeleverd bij de Oracle rdbms installatie ($ORACLE_HOME/bin/rman) en vereist dus geen losse installatie. In feite is RMAN een Pro*c applicatie die de commando’s vertaald naar een PL/SQL interface. De PL/SQL calls zijn statisch gelinked in de oracle kernel en het dus niet nodig dat de database geopend is (mapping in $ORACLE_HOME/rdbms/admin/recover.bsq)
M.b.v. RMAN kunnen offline en online backups worden gemaakt, er kan niet rechstreeks naar tape worden geschreven, maar het is wel mogelijk om andere tools (zoals Veritas, Omniback, Tivoli) te integreren met RMAN.
RMAN kan van via de Enterprise Manager bediend worden, of via de command line.
RMAN commandline parameters in Oracle 11g:
RMAN maakt tevens gebruik van een repository om daarin metadata op te slaan. In deze metadata wordt bijgehouden uit welke datafiles, archivelogs, redologs een database bestaat. Deze metadata wordt altijd opgeslagen in de controlfile van de database. Omdat de controlfile beperkte is qua ruimte kan een aparte recovery catalog database worden gebruikt. In deze database kan een veel meer historie worden bijgehouden van de backup en restore acties.
