RethinkDB allows you to take a backup of the data while the system is running without affecting any other operations. Generally, in traditional databases you need to provide a locking mechanism to perform the backup, which eventually affects the working system. RethinkDB lets you back up or restore the database with no such constraints.
RethinkDB uses a client driver to perform the backup, which provides the concurrency facility, so it doesn't lock any clients while the backup process is running.
RethinkDB provides two utilities to perform the backup and restore:
dumpperforms the backup of the cluster, database, or tablerestoreperforms the restore operation after backup
Along with learning how to take a backup of the system, it is equally and crucially important to learn how to use that backup to restore the system. We will cover restoration in the next section.
To back up the entire cluster of various RethinkDB instances, run the following command under the admin user privilege:
rethinkdb dump
This will perform the backup of the entire cluster assuming that the RethinkDB instance is running on the default port. You should receive the following response in the terminal:
This should generate a .tar.gz at the location where the command is executed. In my case, it's the desktop; extract the zip, and you should see a directory named after every database that, in turn, contains JSON files and metadata files. Have a look at the following screenshot for the backup file hierarchy:
There are several arguments associated with the dump command. By default, running it with no parameter will back up the database or cluster running on port 28015. Here is a list of the supported parameters for this command:
-cor-connect: This takes the port as the input to connect to a different port than the default.-for-file: This allows you to change the default file naming convention of the backup file.-eor-export: This allows you to specify the database or table name to limit the databases to back up.-por-password: If the admin user password is set, this specifies to perform authentication after this parameter.-password-file: This reads the admin password from a plain text file.-tls-cert: If the server is protected by TLS certification, this provides the path to the certificate to allow encrypted connections to the server..-clients: This takes a number as input and performs the backup of the table simultaneously.-temp-dir: During the backup operation, RethinkDB uses the temporary directory to store the intermediate files. This specifies the path to change the directory.
If you like to back up a database running on port 28016 or anything else with a file named backup.zip, try this command out:
rethinkdb dump -c localhost:28016 -f /Users/UnixRoot/Desktop/backup.zip
Upon running the command, a new file named backup.zip will be stored on the Desktop. You should be receiving a response similar to the following screenshot:
You can also back up a single table instead of a complete database. To do so, specify the database and table name in the dump command with -e parameter. Here is the command:
rethinkdb dump -c localhost:28016 -e company.employees -f /Users/UnixRoot/Desktop/backup.zip
This will only back up the employees table present in the company database. You can also specify a single database in the same command.
Making backups in RethinkDB is really easy!
So far we have made backups manually, which is not suitable for a production system at all. Let's learn how to set up automatic backups for RethinkDB.
To keep the backup process regular and to avoid any human dependencies, DevOps generally performs automation. The majority of servers run on Linux-based operating systems, and Linux provides an awesome utility called crontab to perform automation. For Windows users, there are utilities such as Task Scheduler and schtash.
In this section, we are going to automate our backup process using the crontab utility. To perform this, we need to do it in two steps:
- Create a script to execute at regular intervals, which in turn contains the backup commands.
- Set up
crontabto execute the script at midnight every day.
So let's do this.
The script that we are going to create is a shell script. Don't worry, it won't be very fancy; it will just have commands that we have executed in previous sections. So without any further ado, here is the shell code:
#!/bin/bash echo "($(date -u)) Starting RethinkDB daily backup" /usr/local/bin/rethinkdb-dump -f /etc/rethinkdbbackup/backup_."$(date)".zip echo "($(date -u)) Finished creating backup"
The first line is for the Linux shell interpreter to identify the shell file. In the next line, we are just printing the date and text to make the log readable.
The second line is very important, and that line is actually our command to create a new backup. In order to avoid the same filename error we encountered previously, I am just appending the date to each filename.
Okay, so we have our script ready; it's time to make it executable. Run the following command to make the shell script code self-executable:
sudo chmod +x shellfile.sh
It's time to create a new cron job. Open the crontab utility using the following command:
crontab -e
Now we will add our cron code; here it is:
00 00 * * * /Users/UnixRoot/Desktop/backup.sh >> /Users/UnixRoot/Desktop/backup.log
Save and quit the crontab utility. You should see a message indicating that a new crontab has been installed, similar to the screenshot shown here:
This simple utility will execute your script every midnight, which will in turn save the daily backup. You can tweak the backup script according to your needs; for example, we needed to limit the backup file to 5 MB due to some disk issue. We added a filter using the shell directory listing command, and it works.
Let us understand the syntax for cron before wrapping up this section. Here is a simple diagram to explain it:
As you can see, this is quite easy. You need to specify at which time a particular task should be executed using minutes, hours, days of the month, months of the year, and days of the week. We want something to be executed every midnight, so we write 00 minutes and 00 hours, which is midnight, followed by *, which means every day and month of the year.
Coming to back to backups, you can enhance the backup process more by adding third-party APIs such as Dropbox or Google Drive to upload your backup file from the disk to the online store for better availability; however, that will incur some bandwidth expenses, but you will have data surety.
There is an amazing tool written by Rob Conery called rethinkdb_nightly, which uses crontab internally and performs a backup to the Amazon S3 server. Please refer to the following link: https://github.com/robconery/rethinkdb_nightly
We have done the backup process manually and automatically; it's time to perform the restoration process.
As I have mentioned in an earlier section, RethinkDB provides a utility called restore to perform the backup restoration. This command takes the file path as the mandatory parameter along with the other optional parameter, which we are going to learn about in this section, in order to perform the restoration.
Here is the syntax of the command:
rethinkdb dump <file_name or Path>
This command will load the file from the path and restore it to your database cluster. This, by default, assumes that the RethinkDB instance is running on the default port, that is, 28015. Again, like the dump utility, this command also provides various parameters, as follows:
-cor-connect: This takes the port as the input in order to connect to a different port than the default.-por-password: If an admin user password is set, this specifies to perform the authentication after this parameter.-password-file: This reads the admin password from a plain text file.-ior--import: This allows you to restore specific databases or tables.-tls-cert: If the server is protected by TLS certification, this provides the path to the certificate for signature handling.-clients: This takes a number as an input and performs the restoration of the table simultaneously.-temp-dir: During the backup operation, RethinkDB uses the temporary directory to store the intermediate files. This specifies the path required to change the directory.--force: When used, it will import data that exists in a table.--no-secondary-indexes: It prevents the creation of a secondary index during restoration.
If your RethinkDB instance is running on a port other than the default, specify it using the -c parameter. You can also limit which database or table performs the restoration on by using the -i parameter.
The RethinkDB team has worked really hard to make admin operations like these really easy. Backing up and restoring databases is a nightmare task in database development. RethinkDB pushes the limit of it to make it as easy as it can be.
In the next section, we will learn how to perform the migration of data using the backup and restore method in RethinkDB.