May 31, 2019 Blog FileMaker 17FileMaker 18FileMaker Pro AdvancedFileMaker ServerFileMaker Server ConfigurationFileMaker Server MonitoringFMSnew featuresserverStartup Restoration Log What you MUST know about the Startup Restoration Feature Update: It is recommended to turn off the startup restoration feature to avoid stability issues. Please check: https://support.claris.com/s/article/FileMaker-Server-18-Stability-Improvements?language=en_US FileMaker Server added a new feature to its existing tools to ensure the integrity of its hosted databases. After checking files at startup, and before opening any database, if inconsistencies are found due to abnormal closing of files (i.e. power failure or crash), FileMaker Server now uses the restoration log feature to restore files to their last consistent state. What you must know about the Startup Restoration Log: It is NOT a replacement to database backups and the built-in file recovery feature in FMPAIt is on by defaultYou can turn it off using (FMS restart required): CLI: fmsadmin set serverprefs StartupRestorationEnabled=false Admin API: startupRestorationEnabledYou can change its location using (FMS restart required): Windows CLI: fmsadmin set serverprefs startupRestorationLogPath=filewin:/D:/Restoration/MacOS CLI: fmsadmin set serverprefs startupRestorationLogPath=filemac:/Macintosh HD/Restoration/Admin API: startupRestorationEnabled You cannot enable or disable startup restoration for individual databasesExternal containers are not coveredActivity is logged to Event.logMake sure you’re always using drives in RAID arrays. Due to the higher amount of writes caused by the restoration log, your hard drive’s lifetime might be reduced, especially if you are using solid state drivesDo NOT use it with network storage file systemsKeep at least 16 GB of free space for the restoration logs More details: The startup restoration log is basically a copy of all the recent changes made on all the databases. In other words, in FMS 18, data is written to two locations: The database file and the restoration logThe log keeps the most recent changes; new data is written over the old dataThis feature uses a fixed log space of 8GB but it’s recommended to dedicate 16 GB to 18 GB for the restoration logs.The log files are used for all databases. That is, the 8GB are shared by all the hosted databases. Whether you have 1 or 20 databases, they all consume the shared 8GBThis feature can also restore encrypted database files when the encryption password is saved to the FileMaker ServerDefault location:Windows: [drive]:\Program Files\FileMaker\FileMaker Server\Data\RestorationMacOS: /Library/FileMaker Server/Data/Restoration Startup Restoration Log Files on Windows Performance comparison with FMS 17 (according to our tests): When the restoration log is turned OFF:In single user environments: Same performanceIn multi-user environments: FMS 18 is fasterWhen the restoration log is turned ON:In single user environments: FMS 18 is slower in intensive data writing tasksIn multi-user environments: FMS 18 is faster than FMS 17 in intensive data writing tasks You can find FileMaker’s white paper about startup restoration here. By Karl Jreijiri
2 Comments Eric Posted on 11:36 AM - December 30, 2019 I keep my FM Databases on a dedicated drive to optimize performance. Do you recommend setting the restoration destination to a dedicated drive for optimum performance as well? Karl Jreijiri Posted on 12:06 PM - December 30, 2019 Hello Eric! Having the databases on a separate drive is a great practice. If that drive is not setup in a RAID array then I recommend having the restoration log in a separate drive. The reason for that is because the restoration log might degrade the health of your drive due to the extra amount of writes that it does and the last thing you want is for the drive hosting your databases to suddenly die. That will still cause some downtime even if you have backups. You should be good if it’s on the same drive or OS drive if you don’t have many writes/per second happening on your database. We always have the restoration log on the servers that we host on a third drive as a best-practice. This is related to my point in the blog post: Make sure you’re always using drives in RAID arrays. Due to the higher amount of writes caused by the restoration log, your hard drive’s lifetime might be reduced, especially if you are using solid state drives