While recently working on my grad school application essay in OnlyOffice, I suffered a catastrophic file loss. Here’s what happened (and more importantly, how I recovered).
There is another option that may help those of you who don’t have the option of being able to fall back to a versioned backup. You could be lucky and all you need to do is flush the Document Server so that it pushes/commits your edits to file. Try this first:
- The above applies to a native/local install, where occ shoul be recognized as a command. If you’re in a Docker container, you may need to use a command like this instead:
I had the problem again this weekend and the above worked for me. (See reply to this post for root cause investigation and how you can prevent this problem going forward in the future). If this doesn’t work for you, you may have to proceed to Plan B below.
NOTE: The only way I was able to recover is because I have a robust backup system in place on my server that automatically gives me versioned backups. You will need a versioned backup to restore from.
- I renamed my document in Nextcloud.
- Tried to open the newly renamed document, OnlyOffice attempted to open the document, and errors out, telling me that I should download a copy and then open the file.
OnlyOffice Nextcloud Error: “An error occurred during the work with the document. Use the ‘Download as…’ option to save the file backup copy to your computer hard drive.”
- I download a copy of the file and open it in Word and…the document is empty!
- Thankfully, I run Crashplan and keep versioned backups of my documents.
- I download yesterday’s backup and attempt to open it in Word and…this file too is empty!
- The reason this document is blank, even the backup, is because the file is truly blank!
- How is this possible? I’ve been editing the document across multiple browser sessions over several days. It was there just an hour ago.
- Conclusion: OnlyOffice hasn’t been committing the changes to the document itself.
Researching the issue, it seems this is well-known issue. Mind boggling that NextCloud/OnlyOffice would allow such a dangerous issue to stand, but apparently they do:
Heck, you can even see it in the Document Server review:
Okay, so if OnlyOffice isn’t committing the changes to document file itself, where does it store them? Well, I recall in setting this up that there was a document server in use. Going off of that, I happened to stumble upon this clue which I will copy here just in case it is ever lost:
Edits are saved in the MySQL/MariaDB Table oc_documentserver_changes
I was very afraid that OnlyOffice stored everything in the browser’s cache, but thankful that this did not appear to be the case.
Recovering with “The Fix”
Armed with this new piece of information, I did the following:
Reverted the name of the renamed file back to its original name.
In Crashplan, I opened up the MariaDB Docker container’s bind mount on my where my Nextcloud databases are stored.
I changed the date in Crashplan to the day before (my last guaranteed known-good date) and selected all files beginning with oc_documentserver_* and oc_onlyoffice_* for restoration.
- Note that this was likely overkill and restoring just oc_documentserver_changes would’ve been sufficient, but this was a critical situation and I was under a time crunch, so I didn’t have the luxury of time to play around.
I restarted the Nextcloud container.
I went back to the file in question in Nextcloud and attempted to open it. It still gave me the same error, but this time, when I selected the “Download as…” option, the document actually downloaded and wasn’t empty.
Hope this helps someone out,