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
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.
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
Create the repository source list for Ubuntu 24.04 (code name noble).
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.
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
Log in to the JetBackup UI.
Navigate to Jobs → Add New Job.
Give the job a clear name, e.g., Daily Server Snapshot.
Set Job Type to Full Server Backup.
Under Schedule, choose Daily at a low-traffic hour (02:00 is a common choice).
In the Retention tab, set Keep 30 copies and enable Prune older backups automatically.
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
In the UI, go to Settings → Services → MySQL.
Enter the root credentials (or a user with SELECT, LOCK TABLES, and SHOW VIEW privileges).
Save the settings.
3.2 Add a database-specific job
Create a new job named Daily MySQL Backup.
Choose Job Type → MySQL Database Backup.
Select the databases you want to back up (you can choose all or a subset).
Schedule it to run after the full server snapshot, e.g., at 03:00.
Set retention to keep 14 daily copies.
Save.
3.3 Performing a selective restore
Suppose the customers database became corrupted. Restore only that database with the following steps:
Open the JetBackup UI and go to Backups → MySQL.
Find the latest backup entry for the customers database.
Click Restore, choose Overwrite Existing Database, and confirm.
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
Log in to the AWS Management Console.
Create a new bucket, e.g., atoznode-backups, in a region near your server.
Under Permissions → Bucket Policy, add a policy that allows s3:PutObject and s3:DeleteObject for the IAM user you will create.
Create an IAM user (e.g., jetbackup-s3) with Programmatic access and attach the policy.
Copy the Access Key ID and Secret Access Key – you’ll need them in JetBackup.
4.2 Configure the S3 destination in JetBackup
In the UI, go to Destinations → Add Destination.
Choose Amazon S3 as the type.
Enter the bucket name, region (e.g., ap-south-1), and the IAM credentials.
Optionally enable Server-Side Encryption (SSE-S3) for added security.
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:
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
In the UI, select a recent full backup.
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.
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.