There are 3 steps to setting up a Backup Parachute. Selecting your storage location, running the one-line
install command on your server and confirming the auto-detected settings for the database credentials and
backup jobs to be created. The whole process can be as simple as 4 clicks and one CLI command.
When creating backups, sensible defaults are used to save time on configuration. If you'd like to change the settings or schedule of any backups created, you can edit them individually to your liking.
The installation script automatically installs your SSH Key, software dependencies, detects your user,
IP address, SSH port and home directory, then verifies the SSH connection from our servers. The script can
even create a database user allowing for 1-click confirmation in the web UI. By default you are prompted at
each step so your aware of what's going on. Advanced users may opt to add their DB name as an additional CLI parameter
which will fully automate the script with no prompting.
Of course if you prefer to manually specify your server information and not use the script, we support that workflow as well.
When you need to recover a Backup Parachute the process is fast and easy, just hit the big red button on the backup parachute you want to restore. Sensible defaults are predefined, but you can also select the backup you want to restore, then the server and database name you'd like to restore to. You can even restore to a different server on your account or to a database that doesn't currently exist. This makes it super simple to test previous backups, or to migrate production data from one server to another.
If you need to backup a large database, or a database for a very high traffic website, it may be unacceptable to have a read-lock on tables while the backup is processed. In these situations Ottomatik’s mysqldump zero-downtime options can help. With this feature you can enable a "quick" option for large tables, skip locking and do the entire operation in a single transaction to ensure the backup’s consistency.
Depending on how your applications use the database, backing up your structure and data may not be enough. Ottomatik’s mysqldump job configuration allows you to include database functions, triggers and stored procedures (1) in your backup as well. You can even include relevant data from the MySQL Event Scheduler (2) if your application and database is using it.
If you are making backups of the MySQL Binlogs (and you should be), you will typically want to flush, or start a new binlog after each mysqldump operation. This will give you a complete "Logical Backup" of your database in the mysqldump file, and a transactional log of all changes that occurred after that via the new binlog. This configuration is a simple checkbox when setting up a mysqldump backup on Ottomatik.
Sometimes once you have a mysqldump backup file, it can be a pain to get that file physically on a server and perform the correct restore sequence via the command line. Using the point-and-click restore feature you can easily restore any backup in 3 clicks. You can even restore to a different server and provide alternative connection credentials if you like.