I’ve got a DEV file living on a client’s server. Tried to do a migration, and got an error from OttoFMS saying that the file was corrupt, so couldn’t do the migration.
I downloaded the DEV file locally, ran recover on it, no problems. Created a Clone (manually, using FMP Pro), and ran a recovery on that, also no problems. Used local DMT command line to do the migration, all worked fine.
So what’s the difference when OttoFMS is creating the Clones? I’ve downloaded the OttoFMS Cloned file, it does indeed have corruption, as reported by a local Recovery process.
BUT - the DEV file, up until the point OttoFMS tried to make a Clone, is completely fine, and if I download all files and run the migration locally like it’s still 2018, it all works OK. Pretty odd. Any ideas?
Well that doesn’t sound good. Lets see if we can get to the bottom off this.
Lets start with how the clones get made. OttoFMS doesn’t make clones when it does a migration. It asks FileMaker Server to make a backup using the --cloneonly option. It can also make clones using the Developer Utility Tool that is installed on FileMaker Server. In both cases it is FileMaker Server that is making the clones, not OttoFMS.
When you downloaded the file and made a clone with FileMaker Pro you were using a different “Clone making engine” then FileMaker server. It would be nice if those produced the same results every single time. But we seen quite a number of cases where there is a difference. FileMaker Server may consider a file corrupt, but FileMaker Pro will not. Or FileMaker Server on windows sees no corruption, But FileMaker Linux server does.
So we need to determine if that is what you are seeing here. Is your FileMaker Server capable of creating a clone with out corruption? If it can’t, then OttoFMS won’t be able to either.
So try removing OttoFMS from the equation and just use FileMaker Server to create a clone using a backup schedule. Is that clone corrupt?
Thanks as always for reaching out. I’ve run an FMS Based Clone backup now, and that is also corrupt. So I guess that FMS is making corrupt clones of the file, but as you say, FMP created Clones are OK. The recovery report says ‘dropped 1 invalid blocks’ …
2024-10-05 18:09:58.057 +0100 DEV_Clone.fmp12 8495 WARNING: problems were detected while recovering the database. The recovered file should NOT be used going forward; copy only the most recent work from it into a backup copy of the original file.
2024-10-05 18:09:58.057 +0100 DEV_Clone.fmp12 0 File blocks: scanned and rebuilt 9140 block(s), dropped 1 invalid data block(s)
2024-10-05 18:09:58.058 +0100 DEV_Clone.fmp12 0 blocks with invalid structure: 1
2024-10-05 18:09:58.058 +0100 DEV_Clone.fmp12 0 blocks with zeroed header: 0
2024-10-05 18:09:58.058 +0100 DEV_Clone.fmp12 0 blocks with overlapping data: 0
2024-10-05 18:09:58.058 +0100 DEV_Clone.fmp12 0 blocks with unloadable header: 0
2024-10-05 18:09:58.058 +0100 DEV_Clone.fmp12 0 Schema: scanned fields and tables; no problems found
2024-10-05 18:09:58.058 +0100 DEV_Clone.fmp12 0 Structure: scanned; 0 item(s) modified
2024-10-05 18:09:58.058 +0100 DEV_Clone.fmp12 0 File size after recovery is 37945344 bytes
2024-10-05 18:09:58.058 +0100 DEV_ Clone.fmp12 0 *** Completed recovery to 'DEV_Clone Recovered.fmp12'
Is your server running on Linux? This where we typically see this issue.
You could try running a Recover using the Developer Utility Command line tool that is on the server on your Dev file ( not the clone ). It may give you more information about what is corrupt.
You could run a recover on your file, THEN try a clone on the server and see if that is corrupt.
You could also look at backups of the Dev file and see if you get a similar result.
One other thing we have seen is if a Plugin was used in the system, and that plugin isn’t installed on the server, it may cause problems.
Ultimately the problem is that this version of FileMaker Server sees this file as corrupt, or it is producing corrupt clones, and there isn’t anything OttoFMS can do about that. Sorry
You either have to remove the corruption, with a recover, or move to a different FileMaker Server that doesn’t seem to detect the corruption.
Yup - it’s a Linux server, and yes, the file has a LOT of broken references to old plugins. The file itself is a (inherited) horror show of how not to build Filemaker solutions, but it’s too much work to re-build it, so I’ll have a go at weeding out the corruption using FMPerception etc. Thanks again.
James.
I used FMPerception to identify and remove references to Plugins that were not used. Still wouldn’t work.
In the end, by a (long) process of elimination, I found an issue with just a single TO on the relation ship graph. It was for a hardly used Table, and just removing the TO from the graph and saving the file suddenly made the file no longer appear as corrupt. Very odd.
