1. Home
  2. Docs
  3. Backup Ninja
  4. How-To
  5. Adding Custom Backup Command Parameters

Adding Custom Backup Command Parameters

Adding Custom Backup Command Parameters

Since the release of Backup Ninja 1.14.4, we introduced a feature for which you can add your custom command parameters that suits your backup preference. For example, the special case for MongoDB which previously does not have a way to back up with the following parameters to be passed such as --readPreference: secondary, or flags --forceTableScan, --otherFlagcan be achieved now.

For other database vendors such as MySQL, MariaDB, Percona Server, and PostgreSQL, it applies as well with the same approach as the intention of the feature that has been introduced since the Backup Ninja 1.14.4.

How To Apply It?

A prerequisite for this to work requires that you have already created your scheduled backup. Refer to our Scheduling a Backup page to learn how to schedule your backup.

Note

Backup Ninja creates a directory called /var/lib/backup-agent/ for which you can see a sub-directory called /var/lib/backup-agent/jobs. This path /var/lib/backup-agent/jobs contains the list of YAML files which also contains your backup configuration and its backup schedule.

In your target server where the backup agent (bartender) is running, a list of scheduled backup file names in YAML format are stored in the path /var/lib/backup-agent/jobs. The files located here are the list of backup schedules on that target node. Either you have only one scheduled backup, then it shall be stored in this path. Now, let’s proceed with the steps on how to apply custom backup command parameters.

1) Create a .extra.yaml file with its file name based on your scheduled backup name under the path /var/lib/backup-agent/jobs/. Supposedly, the name of your scheduled backup is, then the file name to be created shall be mariabackup_extra_args_sched.extra.yaml. See my example below:

List of Scheduled Backup

Now, in my target server called testnode1, I have the following in /var/lib/backup-agent/jobs as follows,

$ sudo ls -alth /var/lib/backup-agent/jobs
total 8.0K
drwxr-xr-x. 2 root root 94  Mar 8 18:19 .
drwxr-xr-x. 3 root root 28  Mar 8 18:15 ..
-rw-r-----. 1 root root 308 Mar 8 18:00 mariabackup_extra_args_sched.yaml
-rw-r-----. 1 root root 51  Mar 8 17:00 mariabackup_extra_args_sched.extra.yaml

As you might have noticed, here we have two files that contain the based name of the schedule suffix with .yaml as the file format. Whereas, the created .extra file is called mariabackup_extra_args_sched.extra.yaml.

2) In your .extra.yaml file, it shall only contain the following format:

params:
flags:

wherein, params is for options or parameters that take values or key-value format. Whereas the flags, are only options or literally flags that do not take values. For example, in our mariabackup_extra_args_sched.extra.yaml file, the contents are the following:

$ cat mariabackup_extra_args_sched.extra.yaml
params:
  --safe-slave-backup-timeout: 500
flags: [--slave-info, --safe-slave-backup]

3) Restart the bartender agent as follows,

service bartender restart

or

systemctl restart bartender.service

How To Determine If My Parameters Are Applied?

After you have restarted the bartender agent, you can test if your parameters are applied by manually triggering the backup schedule to run it now or immediately. Just go to Schedules → <Choose Your Backup> → More → Backup Now. See the screenshot below,

Backup Ninja: Backup Now Option

Now, view the /var/logs/bartender.log to see if the backup has been triggered. For example, the following logs are being written while triggering the Backup Now option.

$ sudo tail -5f /var/log/mysql/mysqld.log
2021-03-08T18:40:26.277Z info Job "c136v5las7mqrljd5rn0":
2021-03-08T18:40:27.700Z info Job "c136v5las7mqrljd5rn0": mariabackup_extra_args_sched: Backup creation started.
2021-03-08T18:40:27.702Z info Job "c136v5las7mqrljd5rn0": Backup up mysql (vendor: unknown, version: unknown) using mariabackup
2021-03-08T18:40:27.722Z info Job "c136v5las7mqrljd5rn0": Running /usr/bin/mariabackup --backup --stream=xbstream --no-timestamp --host=127.0.0.1 --port=3306 --user=s9s --password=xxxxx --safe-slave-backup-timeout=500 --slave-info --safe-slave-backup
2021-03-08T18:40:27.744Z warn Job "c136v5las7mqrljd5rn0": [00] 2021-03-08 18:40:27 Connecting to MySQL server host: 127.0.0.1, user: s9s, password: set, port: 3306, socket: /var/lib/mysql/mysql.sock
2021-03-08T18:40:27.749Z warn Job "c136v5las7mqrljd5rn0": [00] 2021-03-08 18:40:27 Using server version 10.4.10-MariaDB-log
2021-03-08T18:40:27.751Z warn Job "c136v5las7mqrljd5rn0": mariabackup based on MariaDB server 10.4.10-MariaDB Linux (x86_64)
[00] 2021-03-08 18:40:27 uses posix_fadvise().
[00] 2021-03-08 18:40:27 cd to /var/lib/mysql
...
...
.......

As you noticed, the parameters that we have set in our file /var/lib/backup-agent/jobs/mariabackup_extra_args_sched.extra.yaml, is now set with the following --safe-slave-backup-timeout=500 --slave-info --safe-slave-backup.

Was this article helpful to you? Yes No