How to Back Up a Linux VPS Before Major System Changes

How to back up a Linux VPS before major system changes is an important step in protecting your data, applications, and server configurations. A package upgrade may break a service, a configuration change may prevent an application from starting, or a kernel update may cause boot issues.

Having a reliable backup before making these changes can help you recover your files, configurations, and applications if something goes wrong.

In this guide, we will explain how to back up a Linux VPS before major system changes, including creating backup archives, saving important configurations, transferring backups to another server, and verifying that your backup is usable.

 

Why Should You Back Up a Linux VPS Before Major Changes?

A backup gives you a recovery option when a system update or configuration change causes problems.

Consider creating a backup before:

• Upgrading the Linux operating system.
• Updating the kernel or critical system packages.
• Changing firewall rules or SSH configuration.
• Migrating applications to a different server.
• Reconfiguring Nginx, Apache, PHP, or a database.
• Installing software that changes system-level configurations.
• Making major changes to a production environment.

The type of backup you need depends on what you are changing. A file archive may be sufficient for a small configuration change, while a full-server backup or provider-supported snapshot may be more appropriate before an operating system upgrade.

1. Check Your Available Disk Space

Before creating a backup, check how much storage is available on your VPS.

Run:

df -h

This displays filesystem usage in a human-readable format.

Next, identify which directories are using the most space:

sudo du -xhd1 / 2>/dev/null | sort -h

This command summarizes directory sizes on the root filesystem without crossing into other mounted filesystems.

Remember that a backup stored on the same VPS consumes additional disk space. If the server is already nearly full, creating a large archive may cause problems.

For important production systems, consider storing the backup on a separate server or external storage location.

2. Identify the Files You Need to Back Up

Before running backup commands, identify the data and configurations required to restore your applications.

Common items include:

Data type	Common location or example
Website files	/var/www/ or application-specific directories
Nginx configuration	/etc/nginx/
Apache configuration	/etc/apache2/ or /etc/httpd/
SSH configuration	/etc/ssh/
Application configuration	Application-specific .env and config files
Scheduled tasks	User crontabs and /etc/cron*
Database contents	Logical database exports
Custom scripts	Your own application and deployment directories

Your actual paths may differ depending on the Linux distribution and software installed.

Do not blindly copy every directory on the system. Some files are temporary, virtual filesystems, runtime data, or mounted storage that should be handled separately.

Also, make sure you have the information required to restore the application, such as software versions, package lists, service configuration, and relevant deployment instructions.

3. Create a Backup Archive of Important Files

For a simple file-level backup, you can use tar to create a compressed archive.

For example, to back up the Nginx configuration directory:

sudo tar -czpf /root/nginx-config-backup.tar.gz /etc/nginx

To back up a website directory:

sudo tar -czpf /root/website-backup.tar.gz /var/www

These commands create compressed archives while preserving file permissions and other supported metadata.

The -p option requests preservation of permissions when creating the archive. Restoring ownership, permissions, and special file attributes may require additional care.

Check that the archive exists:

sudo ls -lh /root/nginx-config-backup.tar.gz

You can also test whether the archive can be read:

sudo tar -tzf /root/nginx-config-backup.tar.gz

Important: These examples back up only the specified directories. They do not create a complete, bootable VPS backup.

For application directories containing frequently changing files, consider stopping the relevant application briefly or using a filesystem snapshot to obtain a consistent copy.

4. Back Up Your Database Separately

If your VPS runs MySQL or MariaDB, back up your databases before making significant system changes.

For a MySQL or MariaDB installation that supports the mysqldump utility, you can create a logical backup using:

mysqldump --user=YOUR_DB_USER -p --single-transaction --all-databases > /root/mysql-backup.sql

Replace YOUR_DB_USER with a database account that has the required privileges. The command prompts for the password rather than placing it directly in the command line.

The --single-transaction option is useful for transactional tables such as InnoDB. It does not guarantee a consistent backup of nontransactional tables or every type of database object under all workloads.

Check the generated file:

sudo ls -lh /root/mysql-backup.sql

For PostgreSQL, a database backup can be created using pg_dump or pg_dumpall, depending on whether you need a single database or a broader logical export.

Database backups can contain sensitive information. Restrict access to backup files and encrypt them before transferring them to storage that you do not fully control.

5. Save Important System Information

Backing up application files alone may not be enough to rebuild your VPS. Saving system information can make recovery easier.

Record your Linux distribution and version:

cat /etc/os-release

Check the current kernel:

uname -r

On Debian or Ubuntu, save a list of installed packages:

dpkg --get-selections > /root/installed-packages.txt

On RHEL-based distributions that use DNF, you can save the installed package list with:

rpm -qa > /root/installed-packages.txt

You may also want to record:

• Active services and their status.
• Network and firewall configuration.
• Application versions.
• Custom systemd service files.
• Scheduled tasks.
• DNS settings and external dependencies.
• The current SSH port and access method.

Store this information alongside your backup, but do not include private keys, passwords, or secrets in an unprotected file.

6. Transfer the Backup to Another Server

A backup kept only on the VPS may be lost if the VPS becomes inaccessible or its storage fails.

One option is to transfer your archive to another Linux server using scp.

Run the following command from the machine that will receive the backup, or from a location where the source archive is accessible:

scp user@SOURCE_VPS_IP:/root/nginx-config-backup.tar.gz /path/to/backup/

Replace the example username, source IP address, and destination path with your actual values. The receiving account must have permission to read the source archive; files under /root typically require an appropriate privileged transfer method.

Alternatively, from the source VPS, you can transfer a readable backup archive to another server:

scp /path/to/backup.tar.gz backupuser@BACKUP_SERVER_IP:/path/to/backup/

Use SSH keys or another secure authentication method, and ensure the destination directory is writable by the receiving account.

For recurring backups, consider a dedicated backup solution or encrypted remote storage. Keep credentials separate from the data being backed up.

7. Consider a VPS Snapshot Before Major Updates

If your VPS provider supports snapshots, a snapshot can be useful before major operating system upgrades, kernel updates, or other changes that affect the whole server.

A snapshot may capture the VPS disk state at a particular point in time, depending on the provider’s implementation.

Before relying on one, check:

• Whether the snapshot includes all relevant disks.
• Whether the snapshot captures memory state or only disk state.
• Whether the application and database data will be consistent.
• How to restore the snapshot if the VPS fails to boot.
• Whether snapshots are retained independently of the original VPS.

A snapshot is not automatically a substitute for an independent backup. If the original server or its underlying storage becomes unavailable, a backup stored separately may provide an additional recovery option.

If your provider offers a snapshot feature, review its documentation before making system-level changes.

8. Verify Your Backup Before Proceeding

A backup is useful only if you can recover the required data from it.

After creating your backup, verify that the files exist and can be read.

For a compressed archive:

tar -tzf /path/to/backup.tar.gz

For a database dump, check that the file is nonempty and inspect its beginning:

head -n 20 /root/mysql-backup.sql

For critical systems, the stronger test is to restore the backup into an isolated test environment and confirm that the application starts and the data is usable.

You should also verify that remote backups were transferred completely and that encryption keys or recovery credentials are available when needed.

Do not proceed with a high-risk system change if your only backup is incomplete, inaccessible, or untested.

Final Thoughts

Backing up a Linux VPS before major system changes is a practical way to reduce the risk of data loss and extended downtime. A good preparation process includes identifying important data, exporting databases, saving configuration files, storing backups independently, and verifying that recovery is possible.

For small configuration changes, a targeted backup may be sufficient. For major operating system upgrades or changes that affect the entire server, consider an appropriate full-server backup or provider-supported snapshot in addition to independent copies of important data.

Explore VPS Solutions from ServerNext

If you are planning to deploy applications or manage server workloads, explore the VPS options available from ServerNext:

• USA VPS Server
• BDIX VPS Server
• Singapore VPS Server
• Germany NVMe VPS Server
• Offshore VPS Server

Visit ServerNext to explore available server solutions for your requirements.