SLA
Service Uptime
Service uptime is related to the service provided by us and hosted in our infrastructure, we try our best to guarantee at least 99.4% of service availability.
A set of backups is performed in each customer instance (see backup policy for details) to guarantee a full recovery in case of disasters with a RPO=0.
For the uptime metric is not considered:
• Programmed downtimes for updates (update customized code, server maintenance).
• Suspension for delayed payment to the third party providers in case the customer have the infrastructure with another provider (Amazon, Ovh, GCloud, etc).
• Customer internet service disruption.
• Downtime as consequence of moving the instance to the customer servers.
Every customer instance is executed in an isolated environment, also no one (besides our infrastructure personal) have access to the backups.
The platform reliability depends on the provider, since we are able to deploy to any platform that have linux installed (we provision it for you) and also handle the maintenance at software level (security and updates).
What do we backup?
There are three (3) main elements that we need to restore the instance in case of a disaster: database, filestore and python files.
Because of their nature each element have a different mechanism to backup and restore.
Database
The database contains all the transactions (invoices, messages, contacts, products and so). Odoo uses PostgreSQL so two (2) of the mains mechanisms are used to backup this information: Replication and dump.
The database is replicated to our backup server using postgres native support for replication this ensures a RPO=0 or at least very close (the last non committed transaction is not replicated)
Two times a day the database is dumped and compressed, uploaded to the test and backup server, after that is stored according to our retention policy.
Filestore
The filestore also have two (2) backup methods, every 10 minutes is synced to the backup server and 2 times a day is compressed along with the database dump and copied to the database (also subjected to our retention policy)
Python files (the instance code)
The code is basically stored in github or gitlab (all personalizations are versioned) and after the build process the images are stored in a private repository in quay.io.
The images are built and deployed using docker.