Delete invoice, table of accounts etc

Sorry, my mistake, if you followed the docker install instructions then it should be -U postgres and not -U tryton.

Another thing, you also might want to specify -c or --clean as one of the options when running pg_dump as well.

I seem to make a mistake. That’s what I tried:

From a running tryton, I logged out.

$ sudo docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
18ccc2fcd7db tryton/tryton “/entrypoint.sh uwsg…” 4 hours ago Up 41 seconds 0.0.0.0:8000->8000/tcp tryton
ed01cfc74801 postgres “docker-entrypoint.s…” 4 hours ago Up 7 minutes 5432/tcp tryton-postgres
$ sudo docker stop tryton
$ sudo docker exec ed01cfc74801 pg_dump -U postgres -O postgres >Sikop28.04.20.sql
$ sudo docker start tryton

log into tryton, changed a bit: created a bogus article
logged out tryton

$ sudo docker stop tryton
$ sudo docker exec ed01cfc74801 psql -U postgres -d tryton <Sikop28.04.20.sql
$ sudo docker start tryton

logged into tryton, expected my bogus article inexistant - but it was not.

What’s my mistake?

This line:

sudo docker exec ed01cfc74801 pg_dump -U postgres -O postgres >Sikop28.04.20.sql

Needs the -c flag mentioned above (plus the -C flag to be safe), and the correct database name, so should be this (I think):

sudo docker exec ed01cfc74801 pg_dump -C -c -U postgres -O tryton >Sikop28.04.20.sql

And this line:

sudo docker exec ed01cfc74801 psql -U postgres -d tryton <Sikop28.04.20.sql

Needs an additional -i flag that I missed (sorry!):

sudo docker exec -i ed01cfc74801 psql -U postgres -d tryton <Sikop28.04.20.sql

No reason to be sorry - good to see that experts make mistakes as well…

When playing back a backup, I get a heep of error messages:
https://www.dropbox.com/s/z2dsjuabjc80qso/restore.txt?dl=0

The database seems to be the same as before.
My fault?

These are not error messages, they are just a list of all the things that are getting restored to the database.

If you have a look in the backup file, there should be a line near the top that says something like DROP DATABASE tryton;. If the backup file contains this (which it should do if you ran the pg_dump command with the -C flag) then you can be pretty sure that any changes that you made to the database will have been removed.

So, make sure the tryton server is restarted (which it will be if you do the commands you listed before), and the client as it may be caching some of the data. To restart the web client use the reload button in the toolbar of your browser.

Good morning.
Sorry, still in trouble… ):

Today, I did an entry to “parties” and tried to save the database:

$ sudo docker stop tryton
$ sudo docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
ed01cfc74801 postgres “docker-entrypoint.s…” 19 hours ago Up 25 minutes 5432/tcp tryton-postgres
$ sudo docker exec ed01cfc74801 pg_dump -U postgres -O postgres >29.4.20.sql

And I got a tiny database dump, hardly containing anything:
https://www.dropbox.com/s/701tgmvdir3j9v0/29.4.20.sql?dl=0

Seems to be a bit away from the final goal…

Seems you miss to add dbname “tryton” ?
… pg_dump -d tryton …

I tried again with this line:

and it worked, I could find my input changes in the dump. Probabely my copy/paste error.

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 ed01cfc74801

Alllright.
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:

  1. 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
    
  2. Connect to http://localhost:8000 in your browser, or with the desktop client, login and use Tryton.

  3. 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
    
  4. Connect to http://localhost:8000 in your browser, or with the desktop client, login and use Tryton. Create records, activate modules, etc…

  5. 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
    
  6. 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: Remove database management from tryton (#5384) · Issues · Tryton / Tryton · GitLab

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?

  1. Professional admins and business data processing specialists - or
  2. as well entrepreneurs, company founders, shop owners, self-employed craftsmen etc. with slightly advanced computer knowledge ?

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 (c)(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:

  • data backup and restore skills are mandatory for operating any information system by your own.
  • protect data from unauthorized access is mandatory by the law, at least in Europe.
    Not just for an ERP.

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 ! :+1:t3: