Best practice FMS backup bestanden externe containers?

[Marsau]

Beste mensen,

Ben benieuwd naar jullie visie op de ideale benadering van FMS backups met externe containers. Met name bij systemen met veel containers kan storage een issue worden, maar ook performance - als het veel tijd kost om grote hoeveelheden data weg te schrijven. 

Dan valt er wat voor te zeggen om de containers apart te houden van de standaard backup. Maar dat levert weer zorgen op over data-integriteit bij eventuele recoveries. 

Of? Graag jullie visie?

[menno]

Eigenlijk levert dit geen problemen op. Je moet je alleen wél aan de regeltjes/adviezen van Claris houden. Niemand mag aan de externe bestanden rommelen, alleen FMserver mag dat doen.

Een backup terugzetten of transporteren naar een andere server is tot nu toe geen enkel probleem gebleken. Ook hier geldt dat niemand mag rommelen met de bestanden, de eigenaar van de bestanden is en blijft FMserver (op Windows, MacOS en Linux alike)

Bij het verplaatsen naar een andere server kan je zelfs de FM-bestanden op de nieuwe al sharen terwijl je de container-bestanden nog aan bent het overzetten .... uiteraard kan een container-bestand dan pas vanuit de container worden geopend als dat bestand ook werkelijk beschikbaar is  

M.a.w. gewoon die aparte opslag gebruiken en uitsluiten van de FM-backup, dat scheelt heel veel backup-ruimte. De aparte container-opslag moet je dan uiteraard zelf met Veeam, BackupPC (of als je écht niet anders kan met TimeMachine) of een ander goed mechanisme backuppen.

[Ari]

Is er een dwingende reden om gebruik te maken van externe containers? Als je een een extern containerbestand gebruikt met een ID veld en een container veld dan kun je dat bestand eventueel met een andere frequentie backuppen dan het hoofdbestand en heb je nooit gezeur met data-integriteit.

[Marsau]

Dank, Menno. Ik geloof dat er verder weinig aan toe te voegen is. Best practice hierbij bepaald.

Op 05/02/2021 om 15:09 zei menno:

Eigenlijk levert dit geen problemen op. Je moet je alleen wél aan de regeltjes/adviezen van Claris houden. Niemand mag aan de externe bestanden rommelen, alleen FMserver mag dat doen.

Een backup terugzetten of transporteren naar een andere server is tot nu toe geen enkel probleem gebleken. Ook hier geldt dat niemand mag rommelen met de bestanden, de eigenaar van de bestanden is en blijft FMserver (op Windows, MacOS en Linux alike)

Bij het verplaatsen naar een andere server kan je zelfs de FM-bestanden op de nieuwe al sharen terwijl je de container-bestanden nog aan bent het overzetten .... uiteraard kan een container-bestand dan pas vanuit de container worden geopend als dat bestand ook werkelijk beschikbaar is  

M.a.w. gewoon die aparte opslag gebruiken en uitsluiten van de FM-backup, dat scheelt heel veel backup-ruimte. De aparte container-opslag moet je dan uiteraard zelf met Veeam, BackupPC (of als je écht niet anders kan met TimeMachine) of een ander goed mechanisme backuppen.

 

[Marsau]

Hi Ari, ik heb begrepen dat externe container opslag bij grotere volumes voor betere performance en stabiliteit zorgt. Maar inderdaad: het is geen must.

 

36 minuten geleden zei Ari:

Is er een dwingende reden om gebruik te maken van externe containers? Als je een een extern containerbestand gebruikt met een ID veld en een container veld dan kun je dat bestand eventueel met een andere frequentie backuppen dan het hoofdbestand en heb je nooit gezeur met data-integriteit.

 

[Ari]

 

2 minutes ago, Marsau said:

Hi Ari, ik heb begrepen dat externe container opslag bij grotere volumes voor betere performance en stabiliteit zorgt. Maar inderdaad: het is geen must.

Tja in theorie misschien waar maar ik blijf liever onafhankelijk van overijverige systeembeheerders. 😄

[Marsau]

Begrijpelijk, maar waarschijnlijk onvermijdelijk bij grotere bedrijfskritische systemen. 
 

Misschien is een interessante vervolgvraag waar dan het omslagpunt ligt.

Wanneer zou je - uit oogpunt van betrouwbaarheid en performance - je containers extern moeten gaan opslaan?

[Ari]

Dan eerst even een tegenvraag: op welke informatie baseer je dat extern een betere performance / betrouwbaarheid geeft? Het enige voordeel dat ik kan bedenken is dat je de bestanden dan ook via een andere weg kunt benaderen maar de vraag is of je dat wilt. 

Voor mij is het vooral belangrijk dat de boel blijft draaien en een milliseconde meer of minder vind ik niet interessant. In de praktijk heb ik nooit problemen ondervonden met opslag in de database, ook niet met hele grote bestanden en ik denk dat een containerbestand net zo (in)stabiel is als een willekeurig ander FM bestand.

[menno]

19 uur geleden zei Ari:

Het enige voordeel dat ik kan bedenken is dat je de bestanden dan ook via een andere weg kunt benaderen maar de vraag is of je dat wilt. 

Dan heb je het concept van de externe opslag door FMServer niet goed op je netvlies. FMServer is en blijft eigenaar van de bestanden en alleen FMServer mag "er mee aan de gang". Het is dus absoluut af te raden om met andere software de externe bestanden te benaderen (misschien alleen lezen dan, maar normaal heb je niet de juiste permissies).

Het voordeel van de externe opslag is dat ipv 500Gb te moeten backup-en, er slechts 10 of 20Gb moet worden veilig gesteld. 1 Gb schrijven kost op de snelste schijven/SSD's toch nog minstens 5 seconden en vaak meer. Dat lijkt weinig, maar 500Gb kost je dan 3 kwartier of meer. Als je met 100+ man tegelijk gebruik maakt van een systeem, dat 24/7 in bedrijf is, dan wil je elke mogelijke glitch voorkomen. Onze ervaring is dat de externe opslag daar zeer bij helpt.

Opstarten na een crash, die tegen wil en dank toch kan voorkomen duurt bij een systeem van 15 Gb grootte slechts een paar minuten. Bij 500 Gb duurt de autorecovery véél langer. Als je gehele systeem inclusief containers slechts 10 Gb is, dan kan je je inderdaad afvragen of je deze strategie wel zou moeten volgen, maar voor serieuze grootten is het beslist zinvol.

[Ari]

Dan is de combinatie wellicht een goede oplossing. Een extra containerbestand met alleen een ID en containerveld waarbij de bestanden extern worden opgeslagen. Dit bestand wordt dan bij een update van het hoofdbestand ongemoeid gelaten. Updaten van een bestand met externe containerbestanden gaf bij mij in het verleden nogal eens problemen. Weliswaar met de ouderwetse update methode van data-import in een nieuwe versie maar genoeg ellende om mijn vingers hier niet meer aan te branden..

[Marsau]

@Menno: dat is dus het backup- en recovery argument; daarnaast waren er ook nog overwegingen van performance en stabiliteit van de filemaker bestanden zelf. Althans, heb ik mijzelf geleerd uit diverse bronnen. Kan jij dit niet bevestigen?

https://mightydata.com/stop-embedding-documents-in-your-database/

https://support.claris.com/s/article/Best-Practice-Store-container-data-externally?language=en_US

https://community.claris.com/en/s/question/0D50H00006dshF1/external-storage-and-performance 

@Ari: ik snap de benadering, en heb ook wel eens een collega het vol trots zien toepassen, - maar je werkt dan toch met interne containers, en je hebt dus de genoemde nadelen. Ook vanuit het opzetten van een backup schema zou ik er lichtelijk nerveus van worden, omdat je dus wat de containerbestanden betreft een zekere achterstand accepteert. Afgezien van de extra rompslomp bij het definiëren van de schedules.

Dat het updaten met externe containers een probleem zou kunnen opleveren vind ik overigens een interessant gegeven. Want waar zit het punt dat je dit in principe zo robuust lijkende systeem kan corrumperen? 

 

[menno]

15 uur geleden zei Marsau:

@Menno: dat is dus het backup- en recovery argument; daarnaast waren er ook nog overwegingen van performance en stabiliteit van de filemaker bestanden zelf. Althans, heb ik mijzelf geleerd uit diverse bronnen. Kan jij dit niet bevestigen?

Containervelden worden niet geïndexeerd, dus qua zoeken, schrijven e.d. zal je weinig performanceverschil zien. Qua stabiliteit kan het wel uitmaken: bij een klant van mij konden mensen dmv knippen en plakken snel images in een rapportage zetten.

Op zich leek dat geen probleem, maar af en toe plakten mensen geen images, maar willekeurige tekst uit willekeurige bronnen. Natuurlijk deden ze dat per ongeluk, maar ze creëerden een corrupt record. Dat record stond in een portaal en zodra mensen die portaal op hun scherm kregen (ook al was de relatie NIET waar) kwam er een klokje voor het opbouwen van de portaal in beeld en de portaal-records verschenen nooit. Verder kon men de database zonder problemen gebruiken?! De backup door FMServer van het betreffende bestand mislukte en ook afsluiten van het bestand op FMServer lukte niet.

Het probleem van dat corrupte record los je natuurlijk niet op met externe containers, maar de vervolgproblemen los je wél op. De container zit niet FM, dus de backup lukt nu wél en je moet nu alleen het corrupte record zien te vinden, zonder dat je de container probeert te tonen. Als je dat lukt kan je het record simpel weggooien, soms lukt dat zelfs in de gesharede live-omgeving.

Het voorkomen van corrupte record, hebben we natuurlijk geregeld door de gebruikers niet meer te laten plakken (daar zeuren ze nu nog over, want rapportages van images voorzien kost ze nu 2x zoveel tijd).

Je wint dus stabiliteit en misschien ook wat performance omdat de backup vele malen sneller gaat en dus de duur van de pauzering op de writes wordt geminimaliseerd.

Met conversies hoef je je helemaal geen zorgen te maken, je hebt met bijvoorbeeld de FMDMT de container-bestanden helemaal niet nodig. Alleen bij het verplaatsen naar een andere server moet je goed opletten waar de containers-bestanden staan, op de oude server en waar ze komen te staan op de nieuwe. Conversies gaan bovendien veel sneller, want de containers-bestanden worden niet overgezet. De verwijzingen naar de externe containers gaan gewoon mee, dus na de conversie zijn die bestanden weer normaal beschikbaar.

[hans erik]

Ik ben het er wel mee eens dat je met je tengels van die Remote Container bestanden af moet blijven. Hoewel ik het wel een geruststellend idee vind dat je -mocht de FileMaker tabel corrupt raken (gebeurt nooit, toch?)- altijd een bestand handmatig kunt terugvinden. Tenzij je secure opslag kiest, maar dat is een ander verhaal.

Kleine containerbestanden zoals templates en logo's e.d. sla ik overigens voor het gemak altijd in de tabel zelf op. Maar externe opslag is alleen al aan te bevelen om de grootte van de .fmp12 bestanden binnen de perken te houden. De theorie geeft aan dat een bestand gigantisch groot mag worden, de praktijk leert dat je dat niet moet laten gebeuren. Een apart bestand met het Remote Container veld is daarnaast een prima oplossing. Wel even opletten hoe het dan met privilieges enzo gaat.

Small is beautiful.

[Marsau]

Dus wat jou betreft niet uit oogpunt van stabiliteit en performance, Hans Erik? 

6 minuten geleden zei hans erik:

Maar externe opslag is alleen al aan te bevelen om de grootte van de .fmp12 bestanden binnen de perken te houden.

 

[hans erik]

Zeker wel! Dat hangt samen. Hoe groter een bestand (fysiek) des te groter de kans op corruptie. Alleen al door mechanische problemen met de schijf, aardstralen zo je wilt.

 

[hans erik]

Ik begreep overigens van Matt Petrowsky dat FileMaker de MD5 niet alleen gebruikt om te verifiëren of er met een containerbestand gerommeld is (tampered) maar ook om te voorkomen dat hetzelfde bestand 2x opgeslagen wordt. Dus als je een bepaald bestand in meerdere records opslaat, wordt het door FileMaker maar 1x fysiek weggeschreven. Je ziet het in de RC-folder wel meerdere keren staan, maar het zijn hard-links naar één fysieke binary. Ik denk dat dat met secure opslag niet zo is, maar dat terzijde. 

Ik vraag me alleen wel af of dat ook voor de backups geldt. In een standaard installatie heb je 7 backups die rouleren. Op dag7 wordt de backup van een week geleden overschreven. Maar ik denk wel dat een willekeurig containerbestand dus minimaal 8x opgeslagen wordt.

[Marsau]

Ja, ik vond dat ook een hele prettige ontdekking. Heb het evenwel nooit geverifieerd; bij secure opslag is dat ook onmogelijk.

Waarom denk je dat het daar anders is?

[Infomatics]

bij secure storage wordt ook een dubbele container maar 1x opgeslagen, volgens mij worden de backup containers ook via een hardlink weggeschreven (in ieder geval op MacOS)

 

[hans erik]

Ja, ik denk dat je gelijk hebt. Even een testje gedaan op mijn FM18 server. Je slaat een bestand op in secure storage. Dan ontstaan er in mijn geval 3 bestanden, elk in een 'folderstructuur' van 5 niveaus diep. Sla ik daarna precies hetzelfde bestand op in een nieuwe record, dan verandert er niks aan die folderstructuur. Dus er wordt niks extra fysiek weggeschreven. Best efficiënt! 

Vervolgens maak ik een duplicaat in de Finder en sla die ook op in een nieuw record. Nu onstaat er weer een set van 3 folders met een vergelijkbare structuur. Dat betekent dus dat bij secure container FileMaker INTERN kijkt of een bestand al bestaat, anders zou er een nieuwe set worden aangemaakt. Idem met open storage: als alles hetzelfde blijft, wordt hetzelfde fysieke bestand op schijf gebruikt.

[Marsau]

En je mag aannemen dat bij interne container opslag hetzelfde geldt. Enkelvoudige opslag voor identieke bestanden. Zou ook iets leuks zijn voor het OS.

Zat gisteren even te zoeken naar de wijze waarop je op de server de container mappen apart zet. Een vereiste is dat je aparte ('additional' volgens FMS) database folders gebruikt. Pas dan verschijnt de optie voor separate containeropslag. Was vroeger ook al zo, maar misschien toch iets transparanter.

[hans erik]

Toch raar: ik moest een bestand overbrengen van een Filemaker 16 server naar een FileMaker 18 server. Vrij klein bestand, maar wel met een flink aantal PDF's als Remote Container, bij elkaar 640 MByte, 3500 bestanden (de PDF en JPG bestanden en folders) dus ook niet echt groot en niet echt heel veel.

Ik besloot het eens 'volgens het boekje' te doen: downloaden van de bestanden van de FM16 server via de console gevolgd door uploaden naar de FM18 server met behulp van FMPro client, optie 'Upload to Host...'. Download ging prima, zoals te verwachten. Maar uploaden naar de FMS18 duurde ruim een uur! Kennelijk heeft FileMaker grote moeite met die RC bestanden, het is duidelijk niet de aangewezen weg. Het is beter om de folder met de RC bestanden handmatig naar de server te kopiëren en dan de rechten goed te zetten (fmsadmin / fmserver etc.) in plaats van Filemaker het uploadwerk te laten doen.

 

[bigbadwolf]

Downloaden/uploaden via de Admin Console ben ik al een poosje op afgebrand.

Ik schuif ze altijd over via de FTP. Sneller en praktischer.

[hans erik]

Ik neem aan dat je dan met de hand de rechten goed zet?

 

[bigbadwolf]

Onder Windows gaat het altijd goed.

macOS is veel kritischer, dan moet ik ze echt goedzetten anders staan ze op slot.

[hans erik]

Ik selecteer in zo'n geval (MacOS) de bovenliggende map en dan Get Info, slotje , wachtwoord en vervolgens 'pas toe op alle onderliggende mappen'. Maar voor normale uploads (zonder container bestanden dus) vind ik 'File>Sharing>Upload to host...' wel zo praktisch. In de komende MeetUp van FileMaker Developers NL komen de UNIX rechten overigens ook ter sprake.