Verzekerd zijn van een bruikbare back-up - Q

Verzekerd zijn van een bruikbare back-up
Een back-up kan op meerdere wijzen als “BRUIKBARE” worden aangeduid.
Belangrijk is om te onderkennen welk niveau van integriteit uw huidige back-up
systeem biedt en welk niveau u werkelijk nodig heeft voor uw bedrijfsvoering. De
kosten, maar ook de beperkingen, zijn hierbij rechtstreeks gerelateerd aan het
gewenste niveau. Om een juiste strategie te kunnen kiezen is het dus belangrijk
om de juiste afwegingen te kunnen maken.
Media Integriteit: Dit verwijst naar het probleem van back-uppen naar een falend
apparaat dat niet op de juiste wijze fouten rapporteert. Op dat moment geeft de backup software aan dat alles prima verlopen is, maar geen van de tapes bevat bruikbare
informatie.
Bedenk dat u back-ups niet maakt omdat dat zo hoort. U maakt back-ups om te
kunnen herstellen van een systeemfout. Ieder back-up schema zou periodiek de
tapes moeten testen en daarbij tevens een willekeurig bestand vanaf de back-up
moeten terugzetten en vergelijken met het origineel.
Back-up Integriteit: Vaak is back-up software in staat om bestanden te benaderen
ondanks dat deze geopend zijn door een andere applicatie, inclusief het
besturingssysteem zelf. Op het moment dat de back-up software een “volledig backup” meldt zonder fouten heeft u een volledige kopie van al uw gegevens.
Helaas is er geen garantie dat deze kopie ook bruikbaar is. Elk onderdeel in de backup is namelijk een opname van het moment dat de back-up software het origineel
tegenkwam. Bedenk dat database bestanden zeer snel kunnen wijzigen en vooral
ook op meerdere plaatsen. Uiteindelijk heeft u dan wel het volledige bestand gebackupt, maar is het mogelijk geen correcte momentopname.
Een zeer groot probleem ontstaat wanneer in het bestand, aan het eind van de backup, gegevens zijn opgenomen op een lokatie die voorheen als niet toegewezen vrije
ruimte was gemarkeerd. Terugplaatsen van een dergelijk bestand zal zonder meer
leiden tot verlies van data of andere database fouten.
Bestandsintegriteit: Dit geeft aan dat elk bestand in de back-up een exacte
momentopname is van het origineel. Sommige back-up programma’s vangen
bestandswijzigingen af door het deel waarin de wijziging plaatsvond in het interne
geheugen op te slaan (data caching).
Deze oplossing werkt op zich prima, maar als er op te veel verschillende lokaties
wijzigingen plaatsvinden, waardoor het interne geheugen ontoereikend wordt, wordt
meestal toch teruggegrepen op een normale back-up. In die zin biedt deze oplossing
dus geen extra veiligheid.
Database Integriteit: Is gedefinieerd als een volledige momentopname van alle
bestanden in een database gezamenlijk. Dit kan worden bereikt met een meer
geavanceerd pakket dat data caching kan toepassen waarbij een groep bestanden
als een eenheid wordt behandeld. Uiteraard is het risico van ontoereikend intern
geheugen hierbij beduidend groter.
Pervasive databases bieden een eigen, gegarandeerde methode om database
integriteit te waarborgen. (Zie artikel “Database integriteit voor Pervasive databases”)
Naast de hogere mate van betrouwbaarheid die deze methode biedt, stelt deze ook
beduidend lagere eisen aan uw systeem en back-up applicatie.
Applicatie Integriteit: Dit is het moeilijkst te ondervangen. Veel database applicaties
maken geen gebruik van de mogelijkheid om gerelateerde wijzigingen (transacties)
te bundelen in een enkele “alles-of-niets” actie.
Gelukkig is dit ook het eenvoudigst te herstellen, aangezien er geen daadwerkelijke
beschadiging is van de tabellen afzonderlijk. Meestal hebben applicaties die op deze
manier werken ook een herstel mogelijkheid voor onvolledige transacties. De
mogelijkheid bestaat daarentegen wel dat u dit probleem pas in een veel later
stadium ontdekt.
Database integriteit voor Pervasive databases
Om goed te kunnen herstellen van een ramp is een bruikbare back-up essentieel.
In het eerste deel van dit document hebben we de verschillende gradaties
aangehaald waarmee een back-up als bruikbaar kan worden geïdentificeerd. In dit
onderdeel zullen we ons concentreren op de methode die Pervasive databases zelf
bieden om Database Integriteit te waarborgen: “Continuous Operations”. Zoals de
naam al aangeeft is Continuous Operations ontworpen om uw database zonder
onderbrekingen toegankelijk te houden. Toch zit hier een addertje onder het gras.
Om te beginnen geven we hier de randvoorwaarden:
• Om database integriteit te bereiken door middel van Continuous Operations
dienen alle bestanden van uw database zich op een enkele server te bevinden.
• Het is noodzaak dat u alle bestanden van uw database die open zouden kunnen
zijn in één keer in Continuous Operations plaatst.
• De basisnaam van uw bestanden binnen een bepaalde map dient uniek te zijn.
Het voldoen aan voorwaarde 2. lijkt lastig. Immers, het impliceert dat u kennis moet
hebben van de opbouw van uw database.
Toch is de oplossing verbluffend simpel wanneer u gebruik maakt van Pervasive
Backup Agent.
Voorwaarde 3. heeft te maken met de wijze waarop Pervasive wijzigingen bijhoudt in
bestanden die in Continuous Operations zijn geplaatst. Tijdens Continuous
Operations worden wijzigingen weggeschreven in een bestand dat dezelfde
basisnaam voert als het originele bestand maar daarbij als bestandstype ^^^ (drie
“dakjes”) heeft. De werkwijze staat niet toe dat een enkel ^^^ bestand wordt gedeeld
door meerdere originelen.
Belangrijk is om te beseffen dat bestanden pas in Continuous Operations kunnen
worden geplaatst indien er geen open transacties op die bestanden zijn. Hier wringt
dus ook de schoen, want het betekent dat er dus toch een moment van inactiviteit
nodig is wanneer Continuous Operations wordt gestart.
Pervasive Backup Agent: Indien u gebruik wilt maken van Continuous Operations
verdient het altijd aanbeveling om gebruik te maken van Pervasive Backup Agent.
Pervasive Backup Agent elimineert de noodzaak van specifieke kennis omtrent uw
database(s) en is bovenal ook adaptief. Dat laatste betekent dat u zich dus ook geen
zorgen hoeft te maken wanneer de structuur van uw database wijzigt of wanneer u
nieuwe administraties toevoegt.
Merk op dat het verwerken van de informatie in de ^^^ bestanden een verstoring
oplevert voor de momentopname die u heeft gecreëerd met het starten van
Continuous Operations. U mag deze bestanden dus nooit terugzetten vanuit een
backup. Beter is het zelfs nog om deze bestanden door uw back-up software te laten
uitsluiten.