Hi, can anyone help me find/create a script that I can call from a cron task each night to back up my gitea installation.
I know how to add cron tasks and how generally to work with cron but I haven’t found how to write two scripts, one to stop the gitea app and the other to start it again.
Can anyone help me please?
Brian
Hi.
Something like
docker stop <gitea_container_name>
docker start <gitea_container_name>
should do.
Actually, I don’t understand why you want to stop the container to back it up. Simple replication of the dataset with volumes/bind mounts should be enough. You would probably need a custom app deploy for that, though (because IIRC standard apps’ volumes dataset is hidden).
Hi @swc-phil
Thanks for your response.
I should add that I installed gitea as a catalog app from truenas Apps.
I do a “Data Protection” Cloud Sync Task backup of the dataset to an external service each night.
I see that gitea has various cron tasks running all the time and as far as I know, it would be better to stop gitea to ensure no database activity while backup is being done. SO my idea is to run a script via cron before the backup starts to stop the app and then give it some time to comlete (this is a very small scall gitea instance) and run a script to start the app again.
However, I am open to better ideas
Well, it sounds like good reasoning. However, I do believe gitea uses transactions, so the db stays consistent each moment. And zfs’s cow nature ensures that storage is consistent each moment as well. But you do you.
You can stop/start an app using the midclt command.
Unlike docker stop or docker compose stop (for custom apps), it will not just stop the container(s) that belong to the app, it will remove the deployed compose project Start will deploy the compose project.
While a stopped container would be listed by docker ps -a, container(s) that belong to a stopped app are not listed anymore.
I created a python script that makes dealing with apps easier.
Hmm, good point.
I got the idea from the immich documentation when I switched to it last year and was applying the same reasoning to gitea.
But I think it is not really important in this case (single user git repos and I control access so I can avoid the short time required for backups). I don’t think I need to worry about this.
Thanks for you help.
Brian
Are you sure it’s a good idea? It is impossible to make a consistent file backup/copy of database files while the database is running.
If you want to create backups while the db is running, you might want to create database dumps.If you want to have a consitent file backup of the databaes files, the database shouldn’t be running.
Why do you think so?
Probably because I don’t know how zfs does it’s magic.
The last 11 years I used container, what I wrote in my last post is consensus in the it industry.
But I am eager to learn if zfs doesn’t require it anymore, and like to understand why.
Perhaps we have different it industries…
Durability (from ACID) “guarantees that the effects of transactions that have been committed will survive permanently, even in cases of failures”. Sooo, even a hypervisor’s snapshot should be fine. And in our case – zfs snapshot.
Of course, stopping the database would make it safer. Because the app can have the incorrect transaction use bug. Or the rdbms itself can have a bug which breaks durability.
However, safer is not always a requirement. For example, the “safest” way to back up a workstation is to shut it down and then make a full clone of all its drives. But (I think) nobody is doing that.
Moreover, gitea uses sqlite by default. So it probably can be just copied even in a non-cow filesystem scenario.
That’s the relevant part. The sqlite file won’t be held open indefinitly. I agree this might work with sqllite.
Here are a few points that may help or not… I found most of this out recently while trying to solve a container log issue eating up a bunch of space as there is no (currently) TN way to limit log size for containers either globally or locally for TN apps.
Most of the info on Truenas and docker apps on the web and youtube is out of date due to changes made to different TN versions.
Truenas has also changed how the api works with apps several times and what worked in TN version xyz probably won’t work in TN version defg.
Truenas apps rely on a middleware database and are recreated from there. It’s why if a parameter is not in the app setup it won’t persist over a container stop/start
If you use the standard docker stop/start from cron or from the cammand line the app will be out of sync with the GUI and you will at very the least have no logs available to view though the logs are working.
Docker containers are not persistent. If you stop a app in the GUI the container disappears.
If you store your user data in a dataset in your data pool you will not have issues backing up the data to wherever you wish and you don’t need to worry about if TN is going to move or change the hidden dataset name or location where apps and app data are stored by default.
The most flexible of all the ways available for docker in TN is If you manually install (using one of several ways) a docker container app in a dataset in your data pool. Then you have full control over the app, whats in the yaml file where the data resides, how to start/stop it (using docker commands), when it is updated and by what (watchtower, etc.) who can access the dataset and if you want to snapshot the dataset. This method works well and you can if desired even have the app show up in the apps tab of Truenas while remaining independent of the TN middleware system and it’s limits.
I would give some consideration to transitioning your current gitea to a manual install method as it best aligns with what you wish to do and is easiest to accomplish without breaking anything. Use cron to run a bash script to stop the container, back up the database and then restart the container.