Progressive backups

[hans erik]

Net bij een klant de Progressive Backup aangezet (FMS13 eigenlijk, maar dat maakt niet zo heel veel uit). Nu zegt FMI terecht dat je Progressive Backup altijd moet gebruiken NAAST een normaal backup schema, omdat een Progressive Backup alleen nut heeft als je vóór het verstrijken van het backup interval de server stopt om de backup terug te zetten. Anders is je backup immers ook vernaggeld, het is geen 'time machine voor FileMaker Server'.

 

Maar nu probeer ik dus een optimaal bachupschema in te stellen en vraag ik me af: die Progressive Backup werkt dan toch heel anders dan een normale backup, toch?

- Bij een normale backup loopt FMS langs de bestanden die in het backupschema staan (niet atijd alles dus) en als er een wijziging is, ook al is het maar één byte, dan kopieert FMI het hele bestand naar de backup folder.

- Bij een Progressive Backup worden alleen de veranderingen weggeschreven en toegevoegd aan de backup (of eruit verwijderd).

 

Maar hoe kijkt FMI dan naar de bestanden? Doet ie dat record-voor-record of byte-voor-byte? Ik vermoed het laatste, maar dat is een gok.

 

NB met record-voor-record bedoel ik eigenlijk: object-voor-object, want een database bestaat natuurlijk ook uit allerlei andere zaken dan records.

 

Punt is alleen dat FileMaker op enig moment het hele bestand (alle bestanden?) even moet locken om de snapshot te nemen, omdat het anders een doel blijft dat continu aan verandering onderhevig is.

 

Iemand een idee?

[menno]

Ik gebruik de progressive backups voornamelijk bij het ontwikkelen en om snel in te grijpen nadat er per ongeluk iets is gewist of gewijzigd. Zoals ik het heb begrepen houdt FMS de wijzigingen bij tov de gesharede bestanden in bestandsnaam.fxl bestanden, schrijft het resultaat van de som van het gesharede bestand en het .fxl bestand in de progressive backup en doet dat deels fysiek en deels met hardlinks. Dit is ook meteen de reden dat de PB-bestanden altijd moet kopiëren ipv verplaatsen als je ze wilt gebruiken.

 

Mijn ervaring is dat de PB goed werkt, maar er zijn wel een paar aandachtspunten. De PB houdt geen rekening met de client-caches en kijkt ook niet naar welke transacties nog lopen tijdens het maken van de backup. Je hebt geen gereedschap om te controleren wat de stand van zaken is, je merkt vanzelf een keer dat er iets mist. Best vervelend soms, maar het betekent dat je soms gewoon de client even moet sluiten (dan moet de cache namelijk worden geleegd), vervolgens wachten op de PB en daarna de nieuwste versie van de PB moet kopiëren.

 

Het is helaas niet zo dat je daarmee alles hebt opgevangen, want andere gebruikers kunnen ook gegevens aan het wijzigen zijn en dan kan soms de situatie optreden dat in de database wél de child-records zijn opgeslagen, maar de mother-records niet. Je kan dus wees-records hebben, met een mother-id die je nergens kan terugvinden. Simpelweg omdat de mother nog in de cache van een computer staat, waar de children (of ook slecht een deel daarvan) wél zijn weggeschreven.

 

Zolang je die backup niet pakt is er niks aan de hand, want met de volgende PB-interval, worden die data wel weggeschreven. Denk niet dat dit theoretisch is, want ik heb het gezien in mijn praktijk. Het heeft voor mij geen problemen opgeleverd, omdat ik niets aan de data wijzig en alleen lay-outs, scripts en schema bewerk. Gaat het je echter om de gegevens, dan heb je iets om rekening mee te houden.

 

De nieuwe feature backup-server van FMS leunt echter helemaal op deze PB en daar maak ik me dus wel een beetje zorgen over. Het wegschrijven van de PB gaat razendsnel omdat de een snapshot van huidige database samen met de cache van FMS (niet van de clients) wordt gebruikt om de bestanden te maken. Als de clients dus hun cache nog maar half hebben geleegd naar de server, krijg je dus incomplete records in die PB.

 

Je kan je dus afvragen of en hoe betrouwbaar backup-server dus zal zijn als je het een keer nodig mocht hebben. Hoeveel data moet je controleren? Kloppen de timestamps in de records? Wat heb je in je bestand staan? Wat mis je? Moet je de ontbrekende gegevens corrigeren of komt dat wel goed door andere controles en slimmigheden die je hebt ingebouwd. Of gaan de gebruikers dat zélf controleren?

 

Oh ja, FM schrijft altijd hele records weg, dus óf alle wijzigingen aan een record zijn op de schijf opgeslagen (sinds de laatste commit) óf niet.

[hans erik]

Ja, het is natuurlijk geen time-machine en FMI beveelt ook aan om de Progressive Backup altijd in combinatie met een normale incrementele backup te gebruiken:

 

a. als je per abuis een tabel leegmaakt moet je er snel bij zijn, anders is het ook uit de PB verdwenen

b. je hebt helaas niet zoveel controle over de gebruikerscache. Eigenlijk zou dat wel moeten, in de vorm van een extra checkbox bij de commit-opdracht: update cache.

 

Want ook bij een Perform Script on Server kun je voor rare verrassingen komen te staan als de records onder je handen weggetrokken worden. En zelfs dan weet je het nog niet: de PSoS zou misschien een soort 'notify active users' optie moeten hebben die de aangelogde werkstations een duwtje geeft.

 

Wat ik me nog wel afvraag is, wanneer de Progressive Backup stopt. Het is natuurlijk een apart proces dat op de server draait, maar bij een probleem heb je niet zo gauw door hoe ernstig het is. Hangt FMS? Of de hele machine? OF is 1 gebruiker met iets bezig dat de boel ophangt of ernstige schade aanricht. Je zou zeggen dat een backup interval van 5 minuten mooi is, maar ik vraag me af of dat niet gewoon veel te kort is in de meeste gevallen. Die tijd heb je echt wel nodig en dan loop je het risico dat de schade doorgegeven wordt aan de backup.

[menno]

Daar heb ik helaas ook al ervaring mee: als bijvoorbeeld de interval te kort is om de backup weg te schrijven, dan stopt de backup en blijft niet hangen, maar wordt ook niet automatisch weer opgepakt.

 

Wanneer is de interval te kort? Dat is koffiedik kijken, maar als je een media-database hebt van pakweg 5 GB en je bent daarin flink aan het muteren én je HD is een enkele niet al te snelle HDD, dan wordt het krap en mislukt de PGB en deze wordt niet meer gemaakt, totdat je FMS opnieuw start. FMS zelf draait intussen probleemloos verder, dat dan gelukkig wel.

[hans erik]

Ik bedoel het eigenlijk andersom: ik zou eigenlijk willen kunnen instellen dat FMS onder bepaalde omstandigheden juist stopt met de progressive backup. Om de redenen die ik eerder aangaf, nl. als er iets niet goed gaat moet je de PB kunnen terugzetten, maar ben je er 'te laat bij' dan is je PB ook naar de filistijnen.

 

Het lastige is dat een FMS schijnbaar kan 'hangen', maar in werkelijkheid gewoon even ergens lang mee bezig is. Ik zou daar dus ook iets meer controle over willen. Ideaal zou zijn een soort console of een functie of scriptstap waarmee je de actieve processen op de server kunt uitvragen, met hun gebruik van processor en geheugen.