I have set up a deployment following the steps to create a “Dev Refresh”. 1st attempt I ran out disk space, which I have now resolved. On 2nd attempt I get the attached error. The only file I can see is this zip file that I cannot seem to delete and I cannot see any options that allow to me set any overwrite to true.
Can anyone shed any light on what is happening here?
thanks
Simon
Hey @SiChandler ,
If it is failing to delete there is probably a weird lock on the build. I’d recommend restarting OttoFMS on your source server and manually deleting the build (either via the file explorer or in the OttoFMS File Browser.
-Kyle
Thanks Kyle, thats fixed the deletion problem, I will run the deployment again tonight to see if it now works.
Simon
Hi,
It still failed, and there should be plenty of disk space so I am not sure whay thi sfailed?
g Build server error: failed - backup failed: LABEL_ORDERS.fmp12. Error: fmsadmin command BACKUP LABEL_ORDERS.fmp12 -d filewin:/E:/Program Files/FileMaker/FileMaker Server/Data/Backups/OttoFMS_Temp_Backups/LABEL_ORDERS/ timed out after 600 seconds, you may need to restart your FileMaker Server
Simon
Hey Simon,
That’s a timeout on you source server. I’d recommend toggling on the “Close files during build” option since it is a copy. That should let it copy significantly faster and avoid the timeout. Usually copies don’t take that long, you may also want to try restarting FileMaker Server on the source server.
-Kyle
Hi,
This is now the 5th attempt at doing a Dev refresh of data from our production data and I am beginning to lose faith in whether otto can deliver!
It failed again last night and unfortunatley our LIVE production database was Closed this morning when all users came in, so no one was able to work.
Attached is the screen shot of the log. I could really do with some help in getting this work.
Hey @SiChandler ,
Can you grab the Deployment debug information and send it to me? That will let me get a better look at what is going on. Something in your build on your production server is timing out. Did you toggle on the close files during build option?
If you go to your production server ottofms what is in the build log for that build?
-Kyle
Hi @kduval ,
Thanks for getting back to me. Yes I did turn on the Close file option, as unfortunately no users were able to log onto my live system when they came in in the morning, surely this is a bug? As an aside if something fails and rolls back surely it should re-open the file it closes?
I have attached the debug info, and also below is the build info from the live server. It says “crashed”.
| level | phase | message | timeElapsed | file |
|---|---|---|---|---|
| error | unknown phase | Build crashed | 2475991 |
debug-logs-23.zip (4.2 KB)
BTW the file size is approx 28GB + there is a lot of RCData files which is over 80GB. I have turned off the Transfer Container data for next time.
here is the detail of the crash in json…
{
“id”: 9,
“build_id”: “jit_build_80b6eec92236b36ad615cede”,
“created_at”: “2025-10-14T01:30:17.000Z”,
“updated_at”: “2025-10-14T02:11:33.000Z”,
“started_at”: “2025-10-14T01:30:17.000Z”,
“status”: “crashed”,
“zip_archive”: “jit_build_80b6eec92236b36ad615cede.build.zip”,
“zip_size”: null,
“completed_files”: null,
“message”: “Build was not completed”,
“log”: [
{
“level”: “error”,
“phase”: “unknown phase”,
“message”: “Build crashed”,
“timeElapsed”: 2475991
}
],
“files”: [
{
“fileName”: “LABEL_ORDERS.fmp12”,
“clone”: false,
“size”: 28685078528
}
],
“chained_action_results”: null,
“existsInOutbox”: false,
“schedule_id”: null
}
Hey @SiChandler ,
I suspect your issue was the container data. It looks like from your log it started zipping the container data and the file, with lots of container data that will take a very long time which is why you hit a timeout. If I were you I would make a build before I start the deployment. This will let you run it for longer than the default timeout and also troubleshoot errors somewhat easier. If you need to include the container data then I would, but if you don’t need it definitely don’t include it.
-Kyle
Hi @kduval ,
Still no joy I am fraid. I did a straight forward Build and it still fails.
| level | phase | message |
|---|---|---|
| info | starting | starting build Label Orders 2025-10-19 with 1 files |
| info | starting | files are in valid statuses |
| info | pre-build script | no pre build script to run |
| info | backing up | creating copy of LABEL_ORDERS.fmp12 |
| error | backing up | backup failed: LABEL_ORDERS.fmp12. Error: fmsadmin command BACKUP LABEL_ORDERS.fmp12 -d filewin:/E:/Program Files/FileMaker/FileMaker Server/Data/Backups/OttoFMS_Temp_Backups/LABEL_ORDERS/ timed out after 600 seconds, you may need to restart your FileMaker Server |
| error | backing up | backup failed: LABEL_ORDERS.fmp12. Error: fmsadmin command BACKUP LABEL_ORDERS.fmp12 -d filewin:/E:/Program Files/FileMaker/FileMaker Server/Data/Backups/OttoFMS_Temp_Backups/LABEL_ORDERS/ timed out after 600 seconds, you may need to restart your FileMaker Server |
| error | done | Build Label Orders 2025-10-19 failed |
It is likely taking so long as it is making a full copy of your large file and all of its 80 GB of container data. The only way to prevent backup of the container data is to put all the container data into an additional container data folder and toggle off the backup option for that folder in the Admin Console. Otherwise closing the file and copying it directly (which is what OttoFMS does when it makes copies of closed files) is the only way to prevent duplicating all of that Container data.
If you’re able to close the files I would run this with the files closed. If you cannot close the files and you can’t turn off the backup of the container data, you can increase that timeout time with the Backup Timeout Environment Variable. This will let you override the 10 minute timeout with a longer timeout.
-Kyle
