nxs-backup: The Ultimate Guide For Backup Solution

Introduction to nxs-backup

In the digital landscape, data is one of the most valuable assets for businesses. Protecting this data through efficient backup management is essential to ensure business continuity.

nxs-backup is an open-source tool designed to facilitate the creation, rotation, and storage of backups for files and databases such as MySQL, PostgreSQL, and MariaDB on both local and remote storage solutions. This article will guide you through the capabilities of nxs-backup, its installation, configuration, and best practices.

Importance of Backup Management

Data loss can occur due to various reasons, including cyberattacks, hardware failures, or natural disasters. Consequently, implementing a robust backup strategy is imperative for safeguarding critical information. One effective strategy is the 3-2-1 backup rule, which states that you should keep three copies of your data on two different media, with one copy stored offsite. Properly configured backups minimize the risk of revenue loss, reputational damage, and legal liabilities.

Database management systems (DBMS) are critically important for modern businesses. DBMS supports data collection, storage, and analysis, facilitating report generation and trend identification. Additionally, they automate business processes such as order processing and inventory management, increasing efficiency and reducing labor costs. One of the most popular, reliable, and scalable DBMSs is MySQL.

In this article, we will introduce you to nxs-backup and explore its capabilities with MySQL, and the backup rotation process, examine the features of different configuration blocks, and touch on some theoretical concepts that will aid in our future work with backups.

Getting Started with nxs-backup

The option to install via Docker-compose or on-premise is also detailed in the official documentation, along with Kubernetes/OpenShift, where all the features of this tool are described. We will be installing and configuring nxs-backup for Kubernetes/OpenShift, so to install nxs-backup, follow these steps:

1. Clone the Repository:

cd nxs-backup/.deploy/kubernetes/

2. Navigate to the Kubernetes Directory:

cd nxs-backup/.deploy/kubernetes/

3. Install the nxs-universal-chart (Helm 3 Required):

helm repo add nixys https://registry.nixys.io/chartrepo/public

4. You can find example values here.

5. Prepare the Configuration File.

To configure nxs-backup for Kubernetes/OpenShift, you should prepare the nxs-universal-chart to run nxs-backup as a cron job, with the correct volume mounts and backup job configurations.

Use the provided values.yaml from our repository to set up the cron job that will run nxs-backup on a schedule.

Prepare the correct volume mounts for the cron job. The directory where backups will be stored should be mounted as a volume. When backing up files, mount the backup files as volumes (including, if necessary, physical copies of the databases).

Prepare the nxs-backup configuration with backup jobs as a ConfigMap, which the cron job will use. For more detailed information on configuring various types of backup jobs, refer to the “Usage” section.

Here is an example of the values.yaml file for the nxs-universal-chart:

secretEnvs:
  DB_HOST: "mysql"
  DB_USER: "backup"
  DB_PASS: "b@ckupUserPa$s"
  DB_PORT: "3307"

defaultImage: nixyslab/nxs-backup
defaultImageTag: alpine

configMaps:
  config:
    data:
      nxs-backup.conf: |-
        project_name: "My Project"
        server_name: backup-in-k8s
        notifications:
          mail:
            enabled: false

        jobs:
        - job_name: backup-mysql
          type: mysql
          tmp_dir: /var/nxs-backup/dump_tmp
          sources:
          - name: mysql
            connect:
              db_host: ENV:DB_HOST
              db_port: ENV:DB_PORT
              db_user: ENV:DB_USER
              db_password: ENV:DB_PASS
            target_dbs:
            - project-db
            gzip: true
            db_extra_keys: '--opt --add-drop-database --routines --comments --create-options --quote-names --order-by-primary --hex-blob --single-transaction'
          storages_options:
          - storage_name: local
            backup_path: /var/nxs-backup/databases
            retention:
              days: 7
              weeks: 3
              months: 1

cronJobs:
  nxs-backup-database:
    schedule: "0 2 * * *"
    containers:
    - name: nxs-backup
      envSecrets:
      - secret-envs
      volumeMounts:
      - name: config
        mountPath: /etc/nxs-backup
      - name: nxs-backup
        mountPath: /var/nxs-backup
    volumes:
    - type: configMap
      name: config
    - name: nxs-backup
      type: pvc

pvcs:
  nxs-backup:
    size: 200Gi

6. Deploy nxs-backup using the following command:

helm -n $NAMESPACE_SERVICE_NAME install nxs-backup nixys/nxs-universal-chart -f values.yaml

7. Create a backup job to initiate the backup process:

kubectl create job --from=cronjob/nxs-backup-database nxs-b-db-manual -n $NAMESPACE_SERVICE_NAME

Before we start talking about backup types, let's discuss rotation approaches.

In the context of rapid data growth and increasing volumes of information, effective and reliable management of backups within an organization becomes a high-priority task. This is where distributed storage and backup rotation come into play — one of the key methods of optimizing the backup process. It allows for the preservation of up-to-date data by regularly creating new copies and deleting old ones.

This approach minimizes recovery time by providing multiple recovery points suitable for different scenarios. Older copies are deleted, and new ones are created according to the parameters you need, keeping the data safe from corruption. Backup rotation allows for the efficient use of disk space while ensuring relevant data is available for recovery in case of failure or loss.

During rotation, a potential backup will follow a certain path from its creation to being moved to storage and possibly later deleted. As mentioned, you can create various types of backups: file backups (discrete and incremental backups in GNU Tar format), physical or logical backups for MySQL/MariaDB/PostgreSQL, and backups of MongoDB and Redis.

When backing up data for, say, MongoDB, we create a dump of the database in binary format using the Mongodump utility, specifying all necessary connection parameters.

job_name: mongodb
type: mongodb
tmp_dir: /var/backup/dump_tmp
safety_backup: false
deferred_copying: false
sources:
  - name: mongodb
    connect:
      db_host: localhost
      db_port: "27017"
      db_user: mongo
      db_password: mongoP@5s
    target_dbs:
      - example
    target_collections:
      - all
    exclude_dbs: []
    exclude_collections: []
    gzip: true

The exclude_dbs and exclude_connections options in the example above allow users to exclude certain collections or entire databases from the backup. This way, data that you don't need or that shouldn't be copied for security reasons will not be included in the backup.

Once we have determined what and how we want to back up, the next step is deciding where to store everything and what rotation settings to use, specifically in the storage location.

Storing a specific number of backups

The retention block by default describes the number of intervals during which backups will be stored. The example below is: 6 months, 4 weeks, and 7 days. By default, when nxs-backup runs, weekly backups are created on Sundays, and monthly backups on the 1st of each month. If it is specified to store backups for 7 days, and nxs-backup runs twice a day, the total number of backups will be 14. The mechanism works the same for weekly and monthly backups.

Additionally, you can store a specific number of backups instead of by period with the count_instead_of_period option. This will store exactly the number you specify. This is useful if, for example, you need to collect a database dump every hour in addition to regular daily backups.

All backup job configurations, except for incremental file backups, include identical storage parameters. Below is an example of the settings for storing backups in local storage.

storages_options: 
  - storage_name: local
    backup_path: /var/nxs-backup/dump
    retention:
      days: 7
      weeks: 4
      months: 6

Working with remote storage

The tool supports remote storage options such as S3, SFTP/SCP, SMB/CIFS, NFS, FTP/FTPS, and WebDAV.

The connection parameters for remote storage are located in the storage_connects block of the main configuration in a list format.

Each connection contains two required parameters: a unique name and a set of connection parameters corresponding to its type.

An example of using S3 remote storage and its storage parameters is as follows:

storage_connects:
- name: s3_aws
  s3_params:
    bucket_name: backups_bucket
    access_key_id: my_s3_ak_id
    secret_access_key: ENV:S3_SECRET_KEY
    endpoint: s3.amazonaws.com
    region: us-east-1

After establishing the connection, nxs-backup allows you to configure backup rotation flexibly. Let's explore the available options in more detail.

For quick recovery over a recent period, we can use several copies stored in local storage—two daily copies and one weekly copy. These copies will be regularly updated, without taking up much memory, while storing important and relevant information.

storages_options: 
  - storage_name: local
    backup_path: /var/nxs-backup/dump
    retention:
      days: 1
      weeks: 2
      months: 0

For storing backups over a longer period, we can copy dumps daily for six months by setting the rotation settings to 180/0/0. This way, we can select any needed day over a fairly long period, for example, in the event of a cyberattack, and restore critical data.

storages_options: 
  - storage_name: s3_aws
    backup_path: /backups/dump
    retention:
      days: 180
      weeks: 0
      months: 0

If we don't need that many recovery points, there's an option to set 30/0/6, where copies for the last 30 days and the last 6 months will be stored.

These are just examples of how you can use local and remote storage. You can set rotation parameters for any period and number of copies that suit you.

Disabling backup rotation

In some special cases, it may be necessary to disable backup rotation in the storage. For example, if a user uploads backups without deletion rights. In this case, set the enable_rotate parameter to false and configure daily/weekly/monthly backups according to your requirements. It's important to remember that after disabling rotation, you will need to delete outdated backups to avoid overfilling the storage manually.

storages_options:
  - storage_name: s3
    backup_path: /backups/databases
    enable_rotate: false
    retention:
      days: 1
      weeks: 0
      months: 1

Well, we've talked about rotation, now let's move on to types of backups.

Configuring Backup Jobs (Backup types)

With nxs-backup, you can configure different types of backup jobs according to your requirements. Here are a couple of examples:

Logical Backup Configuration

A logical backup of MySQL is a database dump. When creating backups in SQL format, you need to ensure a few things: that you have installed the mysqldump utility of the same version as your main server or newer; that there is enough space in the directory where the temporary backup is created; and that the database user connecting to the database has the appropriate privileges.

This backup job configuration defines the rules for creating backups of databases on a MySQL server running on localhost. A specific hostname will be used to connect to MySQL within Kubernetes, such as mysql.prod-db.svc.

job_name: mysql
type: mysql
tmp_dir: /var/backups/dump_tmp
safety_backup: false
deferred_copying: false

sources:
  - name: mysql
    connect:
      db_host: localhost
      db_port: "3306"
      db_user: root
      db_password: rootP@5s
    target_dbs:
      - all
    excludes:
      - mysql
      - information_schema
      - performance_schema
      - sys
      - demo
      - staging.metrics
    gzip: true
    is_slave: true
    db_extra_keys: "--opt --add-drop-database --routines --comments --create-options --quote-names --order-by-primary --hex-blob --single-transaction"
storages_options:
  - storage_name: local
    backup_path: /var/backup/dump
    retention:
      days: 7
      weeks: 4
      months: 3

Physical Backup Configuration

A physical backup of MySQL (using Xtrabackup) is essentially a standard file archive. Backups are created in binary format.

This job configuration defines the rules for creating database backups on a MySQL server that runs on localhost. When disabling rotation, be mindful of the potential for storage overflow, as in the example with MySQL logical backups.

job_name: mysql_xtrabackup
type: mysql_xtrabackup
tmp_dir: /var/backup/dump_tmp
safety_backup: false
deferred_copying: false

sources:
  - name: mysql_xtrabackup
    connect:
      db_host: localhost
      db_port: "3306"
      db_user: root
      db_password: rootP@5s
    excludes:
      - test_db.test
    gzip: true
    is_slave: true
    db_extra_keys: "--datadir=/var/lib/mysql"
    prepare_xtrabackup: true
storages_options:
  - storage_name: local
    backup_path: /var/backup/dump
    retention:
      days: 7
      weeks: 4
      months: 3

Notification Configuration

Backup creation and delivery can be unpredictable, and as the saying goes, 'trust but verify' is key to a solid process. With nxs-backup, you not only have the power to run multiple backup processes simultaneously but also to monitor them effectively through a reliable notification system. Currently, nxs-backup supports email and webhook notifications, allowing you to receive alerts on platforms like Telegram, Slack, Mattermost, or any system that accepts webhooks.

Notifications are customizable, with log events categorized by level: warning(default), error, info, and debug. You can set the minimum event level to control which alerts are sent to your channel. We recommend setting up email as the primary notification method, but you can easily configure other options, such as Telegram, Slack, or custom hooks, for seamless oversight of your backup process.

notifications:
  mail:
    enabled: true
    smtp_server: smtp.mail.com
    smtp_port: 465
    smtp_user: j.doe@mail.com
    smtp_password: some5Tr0n9P@s5worD
    recipients:
      - j.doe@mail.com
      - a.smith@mail.com

Restoring Backups

Standard tools for restoring dumps are used to restore logical backups. You can use any version of MySQL that is compatible with the version of your database server.

To generalize, the sequence for restoration will be as follows: create a database for restoration, unpack (if the backup was compressed), and restore the backup.

When restoring a copy in Kubernetes it is necessary to create a pod where the volume with backups will be mounted. Then, we connect to this pod and perform all the same actions as when restoring on the server.

The examples we give below are for a general case, without reference to where your database is located, so we continue according to the general scenario.

Log in to the MySQL server:

$ mysql -u root -p
- `-u` - user for loging to datase;
- `-p` - shell will ask you to prompt for a password before connecting to a database;

Create a database if it doesn’t exist:

mysql> CREATE DATABASE production;

Exit to OS shell and restore DB dump from it:

# syntax
    # mysql -u <username> -p <database_name> < /path/to/dump.sql
    # example
    $ gunzip < /var/nxs-backup/db/mysql/production/daily/mysql_production_2022-08-08_10-12.sql.gz | mysql -u root -p production

If you need physical restoration, use the Percona Xtrabackup version compatible with your database server to restore physical backups.

Typically, the restoration process looks like this: extract the backup to the tmp directory and then restore it using xtrabackup.

You need to unpack the backup into the tmp directory:

 $ tar -xvf 
    /var/nxs-backup/db/xtarbackup/production/daily/production_2022-07-08_02-12.tar.gz 
    -C /var/nxs-backup/tmp/recover

Prepare the backup for restoration. Skip this step if the prepare_xtrabackup option was enabled when creating the backup.

$ xtrabackup --prepare --target-dir=/var/nxs-backup/tmp/recover/

Then proceed with the restoration:

$ xtrabackup --move-back --target-dir=/var/nxs-backup/tmp/recover/

Conclusion

In summary, nxs-backup is a powerful, flexible tool for managing backups in Kubernetes, offering straightforward installation, robust configuration options, and effective data protection.

This guide provided an overview of using nxs-backup for managing backups in Kubernetes. By implementing this tool, organizations can streamline their backup processes, ensuring that vital data is safeguarded against potential threats. By following best practices for setup, monitoring, and security, teams can streamline their backup processes and ensure quick, consistent restoration in case of data loss. Whether you’re just starting with Kubernetes or managing large-scale deployments, nxs-backup can be a valuable asset in maintaining your data's integrity and accessibility.

For more detailed descriptions of settings and additional features, you can refer to the official documentation or subscribe to our newsletter, where we share information on new releases, interesting use cases, and much more.

Stay updated and join the user community, to discuss the tool's functionality and contribute to its development.