Backup Problemen via schedules in Filemaker

[odeon]

Probleem met onze filemaker server in relatie tot de filemakerbestanden.

*** Systeem:

Macintosh G4 -server met intern HD en een externe RAID met 2 schijven in mirroring.

*** Software Filemaker server 5.0

Via schedules wordt de volgende backups gemaakt:

- ieder uur een backup gemaakt naar een map van desbetreffende uur. Dus van ieder uur is er een backup. E.e.a. wordt over schreven na 1 dag.

- iedere 2 uur wordt een aparte backup gemaakt naar een map voor de netwerkbackup. Deze map wordt via het backup-programma Retrospect in een netwerkomgeving van de ene computer naar de andere computer overgehaald. met andere worden. Om de 2 uur zijn de bestanden veilig gesteld op 2 verschillende computers.

**** PROBLEEM:

- Als wij alle filemaker data, het filemakerserver programma en de backup mappen op de interne schijf hebben dan is er geen probleem met backup via schedules.

- Als wij alle filemaker data en het filemakerserver programma op interne schijf hebben en de backup mappen op de externe schijf hebben dan ontstaat er een PROBLEEM.

- Als wij alle filemaker data, het filemakerserver programma en de backup mappen op de externe schijf hebben dan ontstaat er een PROBLEEM.

 

**** Wat is het probleem:

Zodra het backup schedule loopt dan ontstaat er op een bepaald moment een error. Deze error houdt in dat de mirroring van het RAID systeem is beschadigd, met andere woorden het raid-syteem moet worden gerebuild.

 

Wat is onderzocht:

- RAID systeem is goed.

- netwerk kaart is goed.

- G4-server is goed.

- G4 server is voorzien van een schone systeeminstallatie en software, werkt goed.

- het systeem fungeert correct als er filemaker bestanden van ons van omtrent mei / juni worden gebackupped.

- het systeem fungeert correct als er filemaker bestanden van anderen worden gebackupped, via de dezelfde systematiek

 

Het probleem zit in onze bestanden moeten wij concluderen, sinds juni/juli van dit jaar.

 

Wat heb ik ook al onderzocht. Alle bestanden via herstellen nagelopen. Alle bestanden waar een "foutmelding" kwam als kloon weggeschreven en de data opnieuw geimporteerd. Ook dan blijft het probleem aanwezig met backup-schedules in FM

 

Hebben julli nog ideeen

- waar wij het moeten zoeken, waar kunnen wij het vinden

- hoe moeten wij dit kunnen oplossen

- wie zou hier iets meer van af kunnen weten.

 

Gaarne een reactie

[Dr_Flash]

Misschien iets heel simpels hoor, maar ik constateer het volgende:

 

Lokaal gaat alles goed, netwerk geeft problemen

Ieder uur wordt er gebackupt

 

Kan het niet zo zijn dat je dermate veel data over het netwerk op en neer aan het pompen bent dat de volgende backup alweer begint voordat de eerste is afgelopen? Zodat ze elkaar gaan bijten en het misgaat?

[AvD]

AFAIK zou onze dokter best eens gelijk kunnen hebben. Het backup deployment dat hier beschreven werd, lijkt een typisch voorbeeld van overkill. Probeer eens gewoon met de dagelijkse scheduled badkup om 2 of 3 uur 's morgens (oppassen voor Sherlock ! ), en dat in 6 of 7 mappen (Dag 1 Maandag, Dag 2 Dinsdag, Dag 3 Woensdag, ...). Verder hoef je alleen de data te backuppen met je grote backup-systeem. FileMaker Server heb je desgevallend zo meteen weer geïnstalleerd.

Verder nog dit: ga naar http://www.FileMaker.com en zoek daar bij de downloads de white paper Best server practices. Al wat je doet wat daar niet instaat, en omgekeerd, leidt vroeg of laat tot problemen.

 

HTH

[odeon]

Bedankt voor de reactie's, echter ik verwacht dat overkill niet de oorzaak is.

 

Het huidige systeem van back-uppen zoals omschreven draait al 2 jaar. Nooit een probleem. Het betreft in totaal 30 bestanden met een totale omvang van ca. 100 Mb. 2 bestanden daarvan ca. 35 Mb.

 

Ook bij één enkel schedule van 1x per dag treedt het probleem op.

Dus aan een overkill aan schedules kan het in mijn ogen niet liggen.

 

Zijn er ook and4ere tips[/u]

[AvD]

Het probleem zit in onze bestanden moeten wij concluderen, sinds juni/juli van dit jaar.

 

Wat heb ik ook al onderzocht. Alle bestanden via herstellen nagelopen. Alle bestanden waar een "foutmelding" kwam als kloon weggeschreven en de data opnieuw geimporteerd. Ook dan blijft het probleem aanwezig met backup-schedules in FM

Sorry dat ik deze passage bij het eerste antwoord over het hoofd had gezien. Als je vermoedt dat er bestandscorruptie is opgetreden, dan is de door jou gevolgde werkwijze om die te herstellen zeker niet de goede, maar je bent daarbij wel het slachtoffer geworden van onvolledige informatie: de gebruiker kan gerust de FileMaker recovery module gebruiken, zonder dat hij een waarschuwing krijgt in verband met de gevaren hieraan verbonden. Dit thema is hier al meermaals behandeld, nog onlangs. Ik zoek het even op.

 

Voilà! hier vind je meer:

http://www.clarify.net/viewtopic.php?t=885&highlight=recovery

 

En ook hier:

http://www.clarify.net/viewtopic.php?t=199&highlight=recovery

[Sanne]

Ook ik heb een probleem met backupschedules die met FileMaker Server 5.5v4 (!) op Mac OS X naar een remote volume worden gemaakt.

 

Is het remote volume niet beschikbaar op het moment van backup, dan schrijft FileMaker Server de backup naar een onzichtbare folder op root-level, genaamd "/Volumes/".

 

In deze onzichtbare folder wordt het gehele backuppad nagemaakt, en wordt vervolgens DAAR de backup in gezet.

 

Is op een later tijdstip de remote volume WEL beschikbaar (gemount), dan blijft FileMaker Server toch volharden in het backuppen naar de onzichtbare /Volumes/ map.

 

Balen.

[AvD]

Ik heb het niet nagetrokken, maar is er pas geen update verschenen voor Server 5.5 in combinatie met OSX? Of vergis ik me?

[Sanne]

Jep, er is een update, die brengt FileMaker Server naar versie 5.5v4.

 

Het probleem zoals ik beschreef doet zich voor, ook en nog steeds bij versie 5.5v4 (dus na de update).

 

De enige methode die ik tot nog toe verzonnen heb qua oplossing, is FileMaker Server niet meer naar een remote volume te laten backuppen, maar naar een lokale map (dat gaat altijd goed).

 

Deze map kan dan met backup-software als Retrospect (of iets dergelijks) naar een remote volume worden gekopieerd, om aldaar netjes gebackupped te worden.

[AvD]

He Sanne, dat is inderdaad de perfecte oplossing. Heel vaak verkiest FileMaker de "keep it simple"-oplossingen.

[Frank ter Braak]

Deze map kan dan met backup-software als Retrospect (of iets dergelijks) naar een remote volume worden gekopieerd, om aldaar netjes gebackupped te worden.

 

Het nadeel van deze methode is dat Filemaker Server aan al deze bestanden één en de zelfde aanmaak en wijzigings datum en tijd mee geeft. De zeer intelligente software van Retrospect kan dan alleen maar dom alles copieren terwijl het normaal alleen van dát een backup maakt dat gewijzigd is. Dat kost dus veel meer tijd en ruimte. Zeker als je zoals ik o.a. naar CDtjes wegschrijft is dat minder, want je blijft schijfjes wisselen en aanmaken terwijl je het liefste hebt dat alles vanzelf gaat.

 

Nog mooier zouden backups op record level zijn. Zou zoiets niet kunnen binnen Filemaker met export script o.i.d.? En hoe plaats je zoiets dan terug? Maar dit ter zijde.

 

Ikzelf maak dus toch maar backups van de originele bestanden. De clients staan uit maar de Server draait wel. Ik weet niet helemaal meer of dit wel is zoals het hoort maar ik vond geen methode om de Sever (5.5 OSX) automatisch te stoppen en te starten en ondervond tot op heden geen problemen met de backups.

Verstandig????

 

PS voor Sanne:

Als ik de door de Server gehoste bestanden alleen zie bij invullen af aanwijzen van het IP nummer reset ik de Hub en dan zie ik de bestanden gewoon weer onder de naam van de Server in het eerste scherm onder de knop "Host" in het open dialoog venster"

[odeon]

Mede dankzij dit forum heb ik het probleem kunnen traceren en oplossen.

 

Herstelfucntie FMP:

Prachtig voor het herstel voor data. Echter voor het herstellen van een database waardeloos.

Ik lees de functie dus nu als volgt:

De herstel functie herstelt volgens mij de data maar niet de database. De herstelde data z.s.m. exporteren naar naar een goede kloon.

 

Hoe opgelost!

Ons ‘zware’ backup schema heeft er aan bijgedragen dat wij tot op de dag hebben kunnnen traceren wanneer de database is beschadigd. Dit bleek te zijn in dezelfde periode dat één van de schijven van ons raid-systeem crashte. Tijdelijk alles op één schijf gezet, toen was er geen probleem. Pas na herstel raid-systeem door importeur, bleek er een probleem te zijn. Je denkt aan: niet goed herstelt, software probleem, etc. want je hebt geen probleem met de database op één schijf, wel op het raid-systeem.

Na het lezen van info op dit forum, toch maar monniken werk verricht. Namelijk het opnieuw bijwerken van de database ( voor de crash) tot het niveau van nu.

Hoe ? Doodgewoon twee pc naast elkaar. De ene met de ‘kapotte’ database van nu en de andere voor het opnieuw ‘ontwikkelen’ van een goede database. Alle routines, scripts, velden, layouts, etc. weer opnieuw aangemaakt. Tijd viel achteraf nog mee, je hoeft geen dingen opnieuw uit te denken of uit te zoeken. Gewoon invoeren..........................slaap, slaap ....................

Tot slot. De data vanuit de ‘kapotte’ database geexporteerd en geimporteerd in de opnieuw opgebouwde database waarvan eerst een kloon was gemaakt. Tussentijds wel de herstelde database uitgeprobeerd of het probleem niet weer terug kwam.

Een ding geleerd. Bewaar altijd een versie van database na iedere wijziging. Je kunt snel en doeltreffend herstellingen uitvoeren.

[AvD]

Herstelfucntie FMP:

Prachtig voor het herstel voor data. Echter voor het herstellen van een database waardeloos.

Ik lees de functie dus nu als volgt:

De herstel functie herstelt volgens mij de data maar niet de database. De herstelde data z.s.m. exporteren naar naar een goede kloon.

Dit is dus correct voor de volle 100 %. De recovery-functie en de inherente gevaren zijn hier al meermaals uitvoerig besproken. Doe maar eens een search op recovery, of kijk anders hier eens:

http://www.avd-ci.be/tip049.htm

Ook in de 50 en de51 wordt het onderwerp nog behandeld.

[AvD]

He Odeon

 

Hier heb je meer technische info over de recovery-functie (lees vooral de quote van Marcel de Maria):

http://www.clarify.net/viewtopic.php?t=199&highlight=recovery[/url]

[odeon]

AVD voor alle duidelijkheid.

 

*********Dit is dus correct voor de volle 100 %. De recovery-functie en de inherente gevaren zijn hier al meermaals uitvoerig besproken. Doe maar eens een search op recovery, of kijk anders hier eens:

http://www.avd-ci.be/tip049.htm

Ook in de 50 en de51 wordt het onderwerp nog behandeld.**********

 

Deze verwijzing gaat uit van kapotte niet te openen bestanden. Hiervan was bij ons geen sprake. Bestanden veroorzaakten een besturingsfoutje in e raid-software.

Systematiek van herstel is wel gelijk.

[rmw]

Een soortgelijke situatie heb ik hier ook gelezen.

De web-security databases bleken corrupt, maar konden wel gewoon worden gebruikt.

 

http://www.clarify.net/viewtopic.php?t=881

 

Doet toch een beetje eng aan.