Data, backups and security
Where the data lives
Section titled “Where the data lives”Everything in an installation lives in two Docker volumes, on the server:
| Volume | Contents |
|---|---|
<cliente>-pgdata |
The full database: roles, assignments, messages, cron jobs, audit, users. |
<cliente>-archivos |
Uploaded documents, the ones the roles produce and the browser profiles. |
The volumes survive restarts, updates and image rebuilds. Deleting a volume means deleting the data: there is no copy inside the application.
Backups
Section titled “Backups”Backups are not made by the application: the server’s backup system makes them, every night, over the volume contents. That is why a client can restore the previous day without the installation having to be running.
This has a practical consequence: if the server is not backing up, there is no backup. The application cannot detect that for you.
Who can see what
Section titled “Who can see what”- Each installation is isolated: its containers, its database and its files are its own. There is no common database with several companies.
- Inside the installation, users are named individuals and passwords are personal. The session
is stored in a cookie that cannot be read from the browser (
HttpOnly) and that only travels over HTTPS. - Roles can see what they have been given: their documents and the authorised folders. They do not see the rest of the server.
Encryption
Section titled “Encryption”- In transit: all public traffic goes over HTTPS with the domain certificate.
- At rest: data lives in the server’s volumes, protected by access to the server itself. There is no field-level encryption inside the database.
Log of what happens
Section titled “Log of what happens”The application records actions: who signs in, who requests, who approves, which role does what and how much it costs. The log is kept with the installation and can be queried.
What to do if access is lost
Section titled “What to do if access is lost”- If the owner’s password has been lost, a new one can be set from the installation’s operations console (server access).
- If the application does not start, the first place to look is the api container log; the second, that the database is healthy.
- If data has been lost, the volume is restored from the server backup: the installation is stopped, the volume is put back and it is started again.
None of this is done from the browser: these are server administration operations.