Restore test, iemand?

[hans erik]

Vraagje uit nieuwsgierigheid: Ik neem aan dat de meeste serieuze FileMaker ontwikkelaars op dit forum met FileMaker Server werken.

 

En dan is bij de klanten ook vast de backup goed geregeld.

 

Maar: wie heeft er wel eens een volledige restore van een database gedaan?

 

Dus inclusief de RC_folder, met alle filmpjes, foto's, PDF's etc. En dan niet op dezelfde machine, maar op een andere server die een ander Admin-key heeft, een andere naam van de harddisk en een ander netwerkadres.

 

Want dat is natuurlijk het 'worst case' scenario.

 

En hoe gaat dat als je je database bij een hosting bedrijf onderbrengt? Want mijn ervaring is dat je met MacOSX als serverplatform wel even de filepermissions goed moet zetten. Gaat dat externe hosting bedrijf dat voor je doen?

[Felix]

.

Edited October 4, 2015 by Guest

[hans erik]

Dat hangt ervan af waar je de restore doet.

 

Als je een bestand via de upload-button installeert op FIleMaker Server, zorgt de beheerapplicatie ervoor dat de rechten op het bestand goed komen te staan.

 

Maar als je een database vanuit de FMS backup restored, dan moet je een kopie maken van de backup folder naar de database folder. Dat gaat (denk ik) goed als de backupfolder op de normale plaats op de servermachine staat, omdat dan de File Permissions niet veranderen.

 

Maar restore je een dergelijke backup op een andere machine, dan kloppen de permissions niet meer. Je kunt de database dan wel openen, maar je krijgt een foutmelding dat de database 'read only' is.

Ik heb bijvoorbeeld een database waarvan ik de backup elke nacht comprimeer en kopieer naar een NAS. Als er brand uitbreekt of een dief gaat er met de server vandoor, zul je de backup moeten restoren op een andere FileMaker Server machine. En dan zijn je file permissions foetsie.

[edit] Je kunt wel een complete restore doen op je eigen Mac, daar het pad naar de Remote Container folder aanpassen en als je dat goed uitgevoerd hebt kun je met de Admin tool ook de Remote Container uploaden (waarbij de file permissions uiteraard goed gezet worden).

Maar het is nog niet zo simpel, vandaar mijn post: wie heeft dit wel eens gedaan?

[Felix]

Ik denk dat het ook wanneer je een backup 'terugezet' de bedoeling is dat je dat via de upload procedure van de admin console doet. Juist om privilegeproblemen etc. te voorkomen. De RC map is met lezen en schrijven toegankelijk voor iedereen. Die kun je dan ook zonder problemen zo overkopiëren.

[hans erik]

Daar heb je gelijk in, en zeker als je van een hosting service gebruik maakt is dat de enige manier van werken.

 

Overigens: die upload procedure doet dus niks meer en niks minder dan kopiëren en instellen van de privileges.

Als je een bestand via de admin tool sluit, kun je de naam gewoon handmatig aanpassen en het vervolgens met de admin tool weer openen. Mits je toepassing zoiets natuurlijk toelaat met verwijzingen enzo.

 

Ik zou overigens niet weten hoe je met een Windows Server zelf de permissions zou moeten corrigeren.

[hans erik]

De RC map is met lezen en schrijven toegankelijk voor iedereen. Die kun je dan ook zonder problemen zo overkopiëren.

Dat is overigens niet waar: de RC map moet

a. het goede pad hebben (met FileMaker Pro client met een lokale RC map is dat anders dan met FileMaker Server).

b. dezelfde privileges hebben als de 'enclosing folder', dus zeg maar de map FileMaker Server/Database Server/Data/.

 

En als je een RC-map hebt gearchiveerd, verandert de eigenaar van de map en alles wat erin zit!

[menno]

Op windows luistert het backuppen én het restoren iets minder nauw dan in MacOSX en in het geval van windows is volgens mij de opmerking van Felix wél waar. Je kan daar ook meestal de backup gewoon terugzetten in de database-map en dan werkt het allemaal prima. Op windows ben je meestal administrator of je hebt gewoon als user die rechten (eventueel alleen voor het bereik van fmserver).

 

Met macOSX werkt dat een beetje anders en daar is het niet verstandig om gewoon bestanden te kopiëren en te plakken (mbt tot bestanden van fmserver), want bij gewoon kopiëren en plakken worden de permissies standaard aangepast: (eigenaar, groep en eventueel rechten). Bij het backuppen is het het handigste om iets te gebruiken dat werkt als "rsync -a" en bij het restoren iets dat werkt als "cp -a". Ik zeg niet dat je deze commando's zou moeten gebruiken, maar iets dat zo werkt. Ik heb tot nu toe nog niets met "Time Machine" hoeven terugzetten, maar ik denk dat TM in de achtergrond wel van deze commando's gebruik maakt. Bij beide commando's geldt dat de optie "-a" er (onder andere) voor zorgt dat wordt alle originele permissies worden meegekopiëerd ... je zal dit daarom waarschijnlijk ook met sudo of als root moeten uitvoeren.

 

Mijn uitleg is denk ik wat rommelig, maar waar het op neerkomt is dat je dus niet in de finder van MacOSX kan "slepen en laten vallen", omdat daarmee de permissies worden gewijzigd.

[hans erik]

Op windows luistert het backuppen én het restoren iets minder nauw dan in MacOSX en in het geval van windows is volgens mij de opmerking van Felix wél waar. Je kan daar ook meestal de backup gewoon terugzetten in de database-map en dan werkt het allemaal prima. Op windows ben je meestal administrator of je hebt gewoon als user die rechten (eventueel alleen voor het bereik van fmserver).

 

Of is het zo dat onder windows een map de ownership overneemt van de map waarin je hem plaatst, en onder OSX niet?

 

Ik denk dat voor veel FM ontwikkelaars die permissions onbekend terrein zijn. Je bent immers database specialist en geen systeembeheerder. Toch kan het geen kwaad om je hierin een beetje te verdiepen.

 

FileMaker Server maakt bij installatie op een MacOSX platform een user aan (fmserver) en een group (fmsadmin). Deze hebben standaard read/write permissions voor folders van de database server, en die permissions is ook dat wat de FIleMaker Admin console controleert als je op 'validate path' klikt.

 

Toch snap ik iets niet.

Ik heb op mijn testserver een incremental backup (elke 10 minuten) opgezet, en daarvoor een folder 'Incremental' gemaakt op een externe USB3 schijf. Om te beginnen heb ik voor de folder 'Incremental' aan de user 'fmserver' read/write permissions gegeven (deze 'fmserver' hoeft geen eigenaar te zijn maar moet wel read/write permissions hebben).

Dan klik ik in de Admin console op 'Validate path' en dat geeft OK aan.

 

Vervolgens gaat Filemaker Server aan de slag en maakt keurig een incremental backup van de hele database in de map 'Incremental'.

10 minuten later maakt FileMaker Server de tweede backup, helemaal volgens het boekje, de backups spelen 'haasje over' als het ware.

 

Maar als ik de permissions controleer van de mappen die FileMaker Server in de backup aanmaakt, staan die allemaal op default, d.w.z. ik (de Administrator van de server) ben owner, NIET fmserver!

 

Dus kennelijk:

- checkt FileMaker Server bij 'Validate path' alleen of de map waar de backup moet komen Read/Write permissions heeft voor 'fmserver'

- maakt FileMaker Server een incremental backup aan die bij terugzetten in geval van de spreekwoordelijke ramp niet zomaar bruikbaar is, want de permissions van de bestanden en mappen staan verkeerd!

 

Wees gewaarschuwd.

 

HE

[Felix]

.

Edited October 4, 2015 by Guest

[hans erik]

Dat laatste is inderdaad zo, alleen ik zou verwachten dat FileMaker bij het maken van de backup de rechten aanpast naar fmserver, maar dat doet ie dus niet.

 

Toch zou ik iets meer informatie hierover van de kant van FileMaker Inc. wel op prijs stellen.

 

[edit] Misschien nog een nuttige ervaring: als je een restore doet van een database met Remote Container folders en de Remote Container bestanden zijn feitelijk OK, hoef je alleen de database terug te zetten. De links tussen de database en de bestanden blijven dan geldig.

 

Bijvoorbeeld: je hebt een database van 300 MByte en van Remote Container folder van 3 GByte en 30.000 PDF's. Op een zeker moment valt de stroom uit en ook de UPS doet het niet. FileMaker was net iets aan het updaten en de database blijkt corrupt. Dan kun je dus volstaan met het terugkopiëren van de datafile uit de backup in combinatie met het corrigeren van de permissions.