//Tutorials

JetBackup 5: Automate Disaster Recovery Snapshots & AWS S3 Backups

JetBackup 5 on Ubuntu 24.04 LTS: step‑by‑step install, automated daily snapshots, MySQL‑only restores, and secure off‑site copies to Amazon S3 for reliable data protection.

6 min read
JetBackup 5: Automate Disaster Recovery Snapshots & AWS S3 Backups

Backups are the first line of defense against data loss. JetBackup 5 is a modular backup engine that runs on Linux servers and offers a smooth experience on Ubuntu 24.04 LTS. This guide walks you through installing JetBackup 5, setting up automated server snapshots, configuring database-only restores, and pushing copies to an Amazon S3 bucket. By the end, you’ll have a hands-free recovery pipeline that protects your data without constant manual effort.

1. Installing JetBackup 5 on Ubuntu 24.04 LTS

JetBackup 5 is distributed as Debian packages. The following steps add the repository, install the core components, and verify that the service is running.

  1. Add the JetBackup repository key – this ensures that the packages are signed and trusted.
# Update the package list and install utilities
sudo apt-get update
sudo apt-get install -y gnupg2 curl

# Download the repository key, convert it to a keyring, and store it
curl -fsSL https://repo.jetbackup.com/jetbackup.gpg | \
  sudo gpg --dearmor -o /usr/share/keyrings/jetbackup-archive-keyring.gpg
  1. Create the repository source list for Ubuntu 24.04 (code name noble).
echo "deb [signed-by=/usr/share/keyrings/jetbackup-archive-keyring.gpg] \
  https://repo.jetbackup.com/ubuntu noble main" | \
  sudo tee /etc/apt/sources.list.d/jetbackup.list
  1. Update the package index and install JetBackup.
sudo apt-get update
sudo apt-get install -y jetbackup5

During installation, the jetbackup5 service is enabled and started automatically. Confirm that it is running:

systemctl status jetbackup5

If the service is active (running), the web UI is available at https://your-server-ip:8443. The first login uses the username admin and a password that is generated and stored in /etc/jetbackup5/admin.pass. Change this password immediately from Settings → Security in the UI.

2. Configuring Automated Disaster Recovery Snapshots

JetBackup 5 uses “jobs” to define what is backed up and when. A daily full-server snapshot keeps a recent copy of everything on the machine.

2.1 Create a new backup job

  1. Log in to the JetBackup UI.
  2. Navigate to Jobs → Add New Job.
  3. Give the job a clear name, e.g., Daily Server Snapshot.
  4. Set Job Type to Full Server Backup.
  5. Under Schedule, choose Daily at a low-traffic hour (02:00 is a common choice).
  6. In the Retention tab, set Keep 30 copies and enable Prune older backups automatically.
  7. Save the job.

2.2 Verify the snapshot schedule

JetBackup writes job definitions to /etc/jetbackup5/jobs and creates a cron file at /etc/cron.d/jetbackup5. To confirm the job will run at 02:00, view the cron entry:

sudo cat /etc/cron.d/jetbackup5

Look for a line similar to:

0 2 * * * root /usr/local/jetbackup5/bin/jetbackup5 run --job "Daily Server Snapshot"

This confirms the job is scheduled to execute automatically each day.

3. Selective Database Restores

JetBackup 5 can back up databases individually and restore only the ones you need. Below is a concise workflow for MySQL/MariaDB.

3.1 Enable MySQL backup support

  1. In the UI, go to Settings → Services → MySQL.
  2. Enter the root credentials (or a user with SELECT, LOCK TABLES, and SHOW VIEW privileges).
  3. Save the settings.

3.2 Add a database-specific job

  1. Create a new job named Daily MySQL Backup.
  2. Choose Job Type → MySQL Database Backup.
  3. Select the databases you want to back up (you can choose all or a subset).
  4. Schedule it to run after the full server snapshot, e.g., at 03:00.
  5. Set retention to keep 14 daily copies.
  6. Save.

3.3 Performing a selective restore

Suppose the customers database became corrupted. Restore only that database with the following steps:

  1. Open the JetBackup UI and go to Backups → MySQL.
  2. Find the latest backup entry for the customers database.
  3. Click Restore, choose Overwrite Existing Database, and confirm.
  4. JetBackup will extract the .sql.gz file, pipe it to mysql, and report success.

Command-line restoration is also possible. JetBackup stores raw backup files in /var/jetbackup5/mysql. To restore manually:

# Locate the most recent backup file
ls -lt /var/jetbackup5/mysql/customers_*.sql.gz | head -n1

# Decompress and import into the database
zcat /var/jetbackup5/mysql/customers_20240924_0300.sql.gz | \
  sudo mysql -u root -p customers

4. Off-site Backup to Amazon S3

Local backups protect against software failures but not hardware or site-wide outages. JetBackup 5 can push copies of every backup to an Amazon S3 bucket.

4.1 Prepare an S3 bucket

  1. Log in to the AWS Management Console.
  2. Create a new bucket, e.g., atoznode-backups, in a region near your server.
  3. Under Permissions → Bucket Policy, add a policy that allows s3:PutObject and s3:DeleteObject for the IAM user you will create.
  4. Create an IAM user (e.g., jetbackup-s3) with Programmatic access and attach the policy.
  5. Copy the Access Key ID and Secret Access Key – you’ll need them in JetBackup.

4.2 Configure the S3 destination in JetBackup

  1. In the UI, go to Destinations → Add Destination.
  2. Choose Amazon S3 as the type.
  3. Enter the bucket name, region (e.g., ap-south-1), and the IAM credentials.
  4. Optionally enable Server-Side Encryption (SSE-S3) for added security.
  5. Save the destination as S3-Offsite.

4.3 Attach the S3 destination to existing jobs

For each backup job (full server, MySQL, etc.), edit the job and add S3-Offsite under the Destination section. JetBackup will copy the backup file to S3 after it finishes locally.

4.4 Verify the off-site copy

After the next scheduled run, list the bucket contents to confirm the backup was uploaded:

aws s3 ls s3://atoznode-backups/ --profile jetbackup-s3

You should see objects named something like full_20240924_0200.tar.gz and mysql_customers_20240924_0300.sql.gz. If you prefer to check without the AWS CLI, inspect the JetBackup log:

sudo tail -n 20 /var/log/jetbackup5/jetbackup5.log | grep S3

5. Testing Recovery and Fine-Tuning Retention

Backups are only useful if they can be restored. Perform a test restore after the first off-site copy arrives.

5.1 Simulate a full server restore

  1. In the UI, select a recent full backup.
  2. Click Restore → To New Server. JetBackup will download the archive from S3 (if the local copy is missing) and extract it to a temporary directory.
  3. Review the extracted files to confirm critical data (e.g., /var/www, /etc, database dumps) are present.

5.2 Adjust retention policies

Retention settings balance storage costs against recovery objectives. In the UI, navigate to Settings → Retention and consider a baseline that works for most Indian-based web services:

  • Daily snapshots: keep 30 days.
  • Weekly full backups: keep 12 weeks.
  • Monthly off-site copies: keep 12 months.

Each job can have its own retention rule. Remember that each additional copy on S3 adds to storage fees, so monitor bucket size through the AWS console.

Conclusion

JetBackup 5 gives you an automated, modular backup solution for Ubuntu 24.04 LTS servers. By installing the package, scheduling daily snapshots, configuring database-only restores, and pushing encrypted copies to Amazon S3, you create a layered safety net for websites, applications, and data. Regularly test restores and fine-tune retention to keep costs predictable while ensuring you can recover quickly from any failure. With this setup, your AtoZNode VPS or dedicated server will be ready for whatever challenges arise.

jetbackupubuntu 24.04backupsdisaster recoverymysql backupamazon s3server snapshotsretention policy

Try it on your own server

Follow along on a Cloud VPS with full root access, or read the step-by-step knowledge base guides.