Right. This is in place.
Yes. Done all of that.
Nevertheless, I do not get back my “old” dump.
In the never versions, I created a party with a characteristic string, which I do not find in the old dump. Whenever I play back the old dump, the new party is in place again. This is the command I used:
sudo docker exec -i ed01cfc74801 psql -U postgres -d tryton <Basis-Sikop-28.04.20.sql
There may be a couple of possibilities, here are a couple of things to check and try.
Firstly, check that you are definitely backing up and restoring to the correct postgres container. If you accidentally managed to start two postgres containers you may be backing and restoring to the wrong one. I think this is unlikely as it shouldn’t normally be possible because they are named containers, but it is worth checking.
Secondly, there may be a remaining connection to the database stopping the DROP DATABASE from working. So after stopping the tryton container try restarting the postgres container before you restore the database, e.g.:
sudo docker restart ed01cfc74801Alllright.
Using $ docker ps, I should be able to make sure that there is only one postgres container, true? - Given that, I checked it. Only one postgres in place.
I tried $ sudo docker restart ed01cfc74801 , but that does not help either.
More ideas?
Yes, when restoring you don’t need to specify the database (leave off the -d tryton part). This is stopping that database from being dropped.
So just to recap I’ve just tried a slightly simplified full process from the start:
Create your Tryton docker system:
$ sudo docker run --name tryton-postgres -e POSTGRES_PASSWORD=mysecretpassword -e POSTGRES_DB=tryton -d postgres
$ sudo docker run --link tryton-postgres:postgres -e DB_PASSWORD=mysecretpassword -it tryton/tryton trytond-admin -d tryton --all
"admin" email for "tryton": admin@example.com
"admin" password for "tryton":
"admin" password confirmation:
$ sudo docker run --name tryton -p 8000:8000 --link tryton-postgres:postgres -e DB_PASSWORD=mysecretpassword -d tryton/tryton
Connect to http://localhost:8000 in your browser, or with the desktop client, login and use Tryton.
Make a backup (you shouldn’t really need to stop and start tryton here):
$ sudo docker stop tryton
$ sudo docker exec tryton-postgres pg_dump -C -c -U postgres -O tryton >tryton-backup.sql
$ sudo docker start tryton
Connect to http://localhost:8000 in your browser, or with the desktop client, login and use Tryton. Create records, activate modules, etc…
Restore the system back to the point where the backup was made:
$ sudo docker stop tryton
$ sudo docker restart tryton-postgres
$ sudo docker exec -i tryton-postgres psql -U postgres <tryton-backup.sql
$ sudo docker start tryton
Connect to http://localhost:8000 in your browser, or with the desktop client, login and use Tryton as it was at the point of the backup.
First very brief test succeeded. You are THE man!!
And made my day.
May I - with all modesty I’m able to - suggest to GUI and to GUI-cron this process? - I think it’s extremely important, making mistakes can be deadly, and many fellows (included me) will just not do it, if it’s not very easy to carry out.
My offer is to volunteer the RFE at the bug tracker.
I do not think it’s doable. Tryton is a flexible system that can be setup with so many possibilities that will make this so complex. It’s easier to let any system administrator use it’s own proces which is tailored to the setup.
Furthemore there was an option on older version to perform database backup and restore from clients which was removed because it has some security fault: Issue 5384: Remove database management from tryton - Tryton issue tracker
I can hardly agree.
Such a plug-and-play-backup can obviously only be basic equipment for the vanilla user. The expert - of course - will switch it off and customize his one.
But see how complicated it was to find a working solution for the easiest case possible. And a database backup is not just a backup for the case of a system crash or so. It is a bare necessity in order to get tryton usable at all.
About security:
I can hardly believe, that a automated local (and possibly encrypted) backup can be less safe (accounting all possible risks) than no backup at all. And the expert always can customize a better and safer solution for his needs.
This leads back to the question I’m still not really certain about:
For whom is tryton?
People at the forum say #2 people are welcome, but tend to discuss more in a style which fits to #1 folks.
Just my observation as a typical #2 person…
I think a specific module can be developed to do a database dump. This dump can be started from the client or with trytond-cron. This means however that certain places should be configured where data lives.
Don’t base that question on how easy the installation is/was. If you want one-click-install use Microsoft Windows and use Microsoft Dynamics or something (I even doubt it’s one-click-install). Installation of software is never easy and the modularity of Tryton makes it even harder. Also @SISalp offered you a free Tryton instance which could have saved you a lot of trouble.
You should ask the same question again, but now in context with usability, how Tryton performs and how it works on a day to day bases.
I already know the answer: Tryton is for Small to Medium business and with customization it can do almost everything anybody can think of. Installation can be an issue, that’s why I prefer Python virtual environments, but that’s something I care about and not my customers. They want Tryton up-and-running. And yes I’m a typical #2 person, Tryton is a part of my business as a self-employed ©(d)raftsmen. With Tryton I ‘craft’ the best possible solution for a problem my customer have.
I think this is already implemented: the backup and restore tools of the database backend. This is what gives the better flexiblity for the system administrator.
Having said that I must admit that I will love to have a section on our documentation that explains how to setup a tryton production system using docker (and probably docker-compose) which includes a sample backup and restore script.
This should be a starting point for newcomers and users with more knowledge can use it as reference.
P.S: I think we are totally offtopic for the current thread so probably it’s time to start a new one if you want to continue the discussion.
If you prefer a GUI for managing your postgresql database, choose the one that fits your need. I know some use PgAdmin3 for example. I don’t, so I can’t help you on this.
You talk about multiple copies of data, when Pokoli was talking about “security” which means “prevent data do be accessed and modified by unauthorized people”
Unfortunatly:
We try to answer with useful information, mapping the answer on the request.
For example in this thread, you asked for details, I answered with details. Others did also.
It is not easy, and in a foreign language, but at least I try to, even when my answers are considered as “barking”.
Thank you for this hint. At the moment, hopefully I’ve got a solution, but I may come back to that idea in a certain time.
I was talking clearly about “accounting all possible risks”. All of them together.
And we all know, that backups will not exist, if they are not easy enough to aquire. Don’t ask me how many hours in my life I spent with resetting all sorts of passwords of my friends, just because they do not even write the admin password on a piece of paper and store it safely.
Your answers are highly appreciated. Sometimes - forgive me - I have to remark that they are beyond my abilities and sound a little harsh. Nevermind, I can deal with that - as long as you can deal with me coming again and again, till my deranged brain can cope.
Peace ! 