Database backup on current snap instance

1

Hi there: After trying to figure this out on my own for a couple of hours, I’ve decided I give up and quickly ask here. It may be of benefit for others as well…

I have installed Fiduswriter as a Snap instance and am now trying to set up a backup routine. The instructions that I have found in the Github repository seem outdated: The default configuration has created a mysql database (not sqlite), and the fiduswriter.backup facility does not exist. “sudo fiduswriter.mysqldump” and “sudo fiduswriter.manage dumpdata” throw a bunch of errors of various types. Workable instructions are greatly appreciated. :smiling_face_with_sunglasses:

2

Update:

sudo fiduswriter.manage dumpdata --outfile db-dump.json

seems to produce a usable database dump if invoked from inside /var/snap/fiduswriter/current.

1 Like
3

Hey @Tobias ,
yes exactly. You don’t need to execute it in the /var/snap/fiduswriter/current directory though. You can do it in any other directory where the root user has write access. Also note that your export may include media files. These will be added to the same folder where you placed the dumpdata outfile in a folder called “media”. These will need to be present when you import the data again on another server.

There is also documentation on data transfer here: fiduswriter/docs/installation/migration.md at develop · fiduswriter/fiduswriter · GitHub

4

This seems to be about Snap sandboxing and may vary from setup to setup. In my case (Ubuntu as an LXC on Proxmox), the root privileges inside the snap container (invoked with sudo fiduswriter…) do not seem to extend to the host → I do indeed have to make it write to a folder inside the scope of the snap container. I can then move the output around as host root, and push it to a backup location.

1 Like
5

Thanks for sharing this breakdown on ‘Database backup on current snap instance’. I ran into a very similar issue when diagnosing performance bottlenecks and configuration conflicts on a related setup.

In my case, the root cause turned out to be how background buffers and sync handlers were being scheduled. I ended up testing a few different workarounds and utilities referenced on this website to benchmark the response times under load, which helped identify where the latency spikes were originating.

If you’re still troubleshooting, checking the timeout flags in your local environment config might save you some debugging time. Hope this helps point you in the right direction!