After again having messed up my bookings with nasty mistakes, I had to notice that my backups are too much outdated to be used for “repair”. So I’m now looking for a solution to launch my backup script at quit of the client.
How could that be achieved?
Thanks in advance, Wolf
Supposing that you’re using docker…
A method could be, but I do not have knowledge about it, would be to somehow listen for the kill signal inside the container when the docker is stopping, then execute a command. If the data is persistent you would not need to copy outside of the docker.
Another method that we use in some instances, from outside the docker, is instead of launching
docker-compose pull
docker-compose up -d
manually, we append those lines in a update.sh script that previously have a backup command.
update.sh
#!/bin/sh
bash backup.sh
docker-compose pull
docker-compose up -d 2>&1 | grep "is up to date" >&2
backup.sh
#!/bin/bash
backup_path=/backups/
db_name='tryton'
current_datetime=$(date +%H%M%S%d%m%y)
if [ ! -d "$backup_path" ]; then
mkdir ${backup_path}
fi
docker exec --user postgres <postgresdb-docker> pg_dump ${db_name} > ${backup_path}/<some prefix if needed>-${current_datetime}.sql
cd ${backup_path}
# Delete all except 4 newests
ls -tp | grep -v '/$' | awk 'NR>4' | xargs --no-run-if-empty rm
When you quit the client, you will logout from the Tryton server. So you would do something on ‘logout’ in Tryton to start a backup. If you are connecting with one client that won’t be a big problem, but with many clients it will. Maybe you can look if there are no sessions left and then start the backup.
Maybe a better solution will be to have a scheduled task (cron task, not inside Tryton) who does a backup of the database and run it more often.
The first one means developing your own module which will poke into the logout / session system to execute the backup-script. The second one is just changing your cron task to backup more often.
If the size of the backup is an issue using an incremental backup could be a solution.
Thank you very much for your thoughts. As I’m not at all familiar with docker, I cannot go for that.
As a quick hack, I’ll integrate my backup script into ubuntu’s startup apps, maybe I’ll be even fit enough to md5 the new with the recent version in case nothing changed since last system boot, and delete one of both. And then there is much room for a smart preservation-and-deletion scheme.
If I got you folks right, there is not an easy “check-if-another-client-is-present==if-not-do-something” feature in tryton. Maybe it should be, as an automated backup after any quit is really what we should have. My hope was that with more experience in booking, I would stop to make really hazardous mistakes - but that didnt prove true.
No the server should not be run on the same machine as the client in most of the use case. And thus it can not know if there is a running client.
More over backup timing should not rely on the user behavior. They should be periodical no matter what happens because jobs may run etc. but also data corruption can happen on a perfectly steady system.
In the past there was the ability to manually backup a database from the client but it’s been removed because of security issues. And I totally agree with that.
The server can know because sessions are logged into the database. Also when a client do a logout the server is called right? So at that moment a backup can be started. Problem is when you have multiple clients who logout all al once. This is all server side, no client is involved only when the user calls the logout function.
This is about PEBKAC … @herrdeh messes up his Tryton database by creating wrong moves etc, and closes the client. After some good nights sleep, he realizes that he did something badly wrong and wants to revert his actions by restoring an older version of the database. But looking through his database files he only find a database from six weeks ago. So he lost six weeks of work.
And yes, the same can happen when you backup after closing the client and only realize some weeks later that you did something wrong.
So reading the above, create backups on regular intervals with a cron task. It’s the easiest way to do and no interaction with the client is needed. You can have multiple copies of the database and using a backup solution like Borg backup will keep your backup secure and small because of deduplication.
Oh and even you didn’t mess up your database, test your backup regularly to prevent backup air instead of data. So you when things happens nothing blows away.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.