Relational databases are probably the most widely used data management tool in the e-commerce environment. Thanks to them, we can store information in structured tables and determine the relationships between them, facilitate optimization, ensure encryption, limit access to data, and in particular, get all data back in case something happens to the project. Only those who have already lost data can fully realize the truth of the golden rule of every development: Back up! But how?
In practice, two main methods of backup are often used – dumping and point-in-time.
Database dumping
In this case, it’s a process that creates a complete copy of the entire database and stores it on an external storage, such as a disk. Dumping is carried out in a certain time interval, the entire database is backed up at once, and the backup contains all the tables, data and database structure.
This method of backup is effective in that it usually takes up relatively less space because it’s performed only once in a while. However, precisely because of this, the data created from the moment the backup is created to the moment of the problem with the site, is irreversibly gone. Dumping the database is therefore more preferable for stable smaller projects without active development.
Point-in-time or status record
With a point-in-time, the database collects a so-called binary log – a record of all changes that are made over the database, along with a timestamp. With this method of backup, it’s possible to restore the database to a specific moment accurate to the second. The status record ensures that no data is lost and provides the possibility to recover exactly one key moment before a problem arose on the project.
Point-in-time implementation is especially useful if the project is being actively developed and there may be an unintentional introduction of incorrect or unwanted changes to the production database.
The disadvantage of this method of back-up is most often the size of the backups. Since the record is created virtually every second, it mostly results in huge files that need to be safely stored somewhere.
On our project Fuego.sk, Google Cloud, where the project runs, takes care of it. Thanks to the tools available here, we can easily turn on point-in-time backup, monitor changes in data, set the backup time frequency, and especially restore data in case of a problem.
Recovery first!
Whether you choose dumping or point-in-time, be sure to check the stored data and test the possibility of their recovery! Gigabytes of information will be useless if you can’t put them back into the production environment.
