iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Need a server to try this on? Antihost offers Linux VPS plans with NVMe storage, full root access and a 14-day free trial.
The safest Linux VPS backup uses several layers: native database dumps, versioned file backups, and provider or filesystem snapshots. Keep the backup repository encrypted, copy it outside the VPS and preferably outside the provider’s failure domain, retain multiple points in time, alert on failures, and regularly perform test restores. A snapshot alone is a rollback tool, not a complete disaster-recovery plan.
What a complete VPS backup protects
A VPS recovery plan must cover more than the files visible in your web root. Inventory the state that would be required to rebuild the service on a new machine:
Recommended Free Tools
- Application and content:
/var/www, application directories, deployment artifacts, persistent uploads, and user-generated data. - Operating-system configuration:
/etc, firewall rules, SSH configuration, service unit files, package and repository configuration, and hostname or networking settings. - Automation: root and user crontabs, systemd unit and timer definitions, deployment scripts, and maintenance jobs.
- Security and TLS: certificates, private keys, trusted-authority configuration, secret files, and the procedure for rotating credentials after a compromise.
- Databases: logical dumps, cluster-wide roles and grants, and—when the recovery-point objective requires it—base backups plus transaction logs.
Do not spend backup capacity on data that can be recreated reliably. Package caches, build directories, temporary files, and application caches can usually be excluded. Document every exclusion so that an operator does not mistake a deliberate omission for a successful backup of required data.
Use three complementary backup layers
| Layer | What it captures | Consistency and granularity | Typical recovery use | Main limitation |
|---|---|---|---|---|
| Database-native logical dump | SQL definitions and rows; global roles or grants when exported separately | Database tool provides a defined logical-consistency model; restore an individual database or object | Recover a dropped database, migrate to a clean server, or extract selected data | Restore can be slower for large datasets; options and server versions matter |
| Versioned file repository | Configuration, application files, uploads, and database dump files | Point-in-time snapshots with full-tree or selected-file restore | Recover deleted files, rebuild a host, or retrieve an earlier version | It does not make a live database directory consistent by itself |
| Provider, LVM, ZFS, or Btrfs snapshot | Block-level volume state at a moment in time | Very fast rollback; usually restores a volume or machine image | Undo a bad deployment or accidental system-wide change quickly | May share the same disk, account, region, provider, or credentials as the VPS |
Run the database export first, include the resulting files in the versioned repository, and use snapshots as an additional rapid-rollback layer. Keep at least one independent copy in another failure domain. A provider outage, deleted account, compromised credentials, or ransomware event can remove every copy that remains inside the same control plane.
#1 Best Overall
- Easily store and access 2TB to content on the go with the Seagate Portable Drive, a USB external hard drive
- Designed to work with Windows or Mac computers, this external hard drive makes backup a snap just drag and drop
- To get set up, connect the portable hard drive to a computer for automatic recognition no software required
- This USB drive provides plug and play simplicity with the included 18 inch USB 3.0 cable
- The available storage capacity may vary.
Prepare the VPS and backup destinations
Define recovery objectives
Write down the maximum acceptable data loss (the recovery-point objective) and the maximum tolerable outage (the recovery-time objective). A site that can lose one day’s orders may need a daily dump; a service that cannot lose minutes of transactions needs continuous archiving or another WAL/binlog-aware design. Fast snapshots reduce rollback time but do not replace a database recovery method.
Choose independent storage
Restic repositories can be local or remote. Its documented backends include SFTP, REST, Amazon S3-compatible storage, MinIO, Wasabi, Backblaze B2, Azure Blob Storage, OpenStack Swift, and services accessed through rclone. A practical design keeps a local repository for a fast restore and sends a second repository, or an exported copy, to storage outside the VPS and ideally outside the hosting provider.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Use a dedicated backup account or bucket, least-privilege credentials, encryption at rest, and a separate method for storing the repository password. Do not leave long-lived storage keys in a web directory or in a world-readable shell script. Restrict repository access so a compromised application account cannot erase every retention point.
Stage database exports safely
Create a directory such as /var/backups/database with ownership and permissions that allow only the backup operator and the database-dump process to read it. Remove or rotate stale dumps only after the file-backup job has completed successfully. Check that an expected dump exists and is non-empty before declaring the overall backup successful.
Back up files with Restic
Initialize an encrypted repository
Install Restic from your distribution’s trusted package source or the project’s release process, then initialize a repository on a destination that is not the VPS’s primary disk. The following example uses SFTP; the same workflow applies to other supported backends after setting that backend’s repository address and credentials.
install -m 700 -d /root/.config/restic
printf '%sn' 'use-a-long-random-password-kept-offline' > /root/.config/restic/password
chmod 600 /root/.config/restic/password
export RESTIC_PASSWORD_FILE=/root/.config/restic/password
restic -r sftp:backupuser@backup-host:/srv/restic/vps01 initStore the repository password in a password manager or offline recovery record as well as on the machine that performs backups. An encrypted repository cannot be restored without it. For unattended jobs, load credentials from root-readable files or a secrets manager rather than embedding them in command arguments.
Back up the recovery set
Start with explicit paths instead of blindly copying every mounted filesystem. This makes omissions reviewable and avoids capturing transient mounts.
Rank #2
- Easily store and access 5TB of content on the go with the Seagate portable drive, a USB external hard Drive
- Designed to work with Windows or Mac computers, this external hard drive makes backup a snap just drag and drop
- To get set up, connect the portable hard drive to a computer for automatic recognition software required
- This USB drive provides plug and play simplicity with the included 18 inch USB 3.0 cable
- The available storage capacity may vary.
restic -r sftp:backupuser@backup-host:/srv/restic/vps01 backup
/etc
/var/www
/opt/apps
/var/backups/database
/root/scripts
--exclude '/var/www/*/cache'
--exclude '/var/www/*/tmp'
--exclude '/opt/apps/*/node_modules'
--tag vps01-filesAdjust the paths and exclusions to your application. Include uploads and deployment artifacts that cannot be reconstructed. Exclude build output or caches only when you have verified that a rebuild is possible. If databases, tablespaces, or uploads are on separate mounted volumes, include those mounts explicitly and document their relationship to the VPS snapshot.
Verify, list, and prune snapshots
Restic creates versioned snapshots and can restore either a complete tree or selected files. Schedule integrity checks and inspect the snapshot list so a job that exits early is noticed.
restic -r sftp:backupuser@backup-host:/srv/restic/vps01 snapshots
restic -r sftp:backupuser@backup-host:/srv/restic/vps01 check
restic -r sftp:backupuser@backup-host:/srv/restic/vps01 restore latest
--target /restore-test
restic -r sftp:backupuser@backup-host:/srv/restic/vps01 forget
--keep-daily 7 --keep-weekly 4 --keep-monthly 6 --pruneThe retention numbers above are an example policy, not a universal requirement. Choose them from your recovery objectives, legal requirements, storage budget, and the frequency of destructive incidents. Run pruning only after a successful backup and consider retaining an immutable or otherwise deletion-protected copy for ransomware scenarios.
Free tools Windows power users keep installed
One-click scans. No signup required.
Back up PostgreSQL correctly
Why copying the data directory is risky
PostgreSQL’s documentation states: “The database server must be shut down in order to get a usable backup” when taking a direct file-system backup. A running cluster is changing data files and write-ahead-log state; copying those files without a database-aware method does not automatically produce a restorable image.
A storage snapshot can be valid while PostgreSQL is running only when the snapshot method and database procedure provide a consistent cluster image. If data, WAL, or tablespaces span volumes, the snapshots must be simultaneous or coordinated. Confirm the storage platform’s guarantees and retain the complete cluster and WAL context required by the documented restore procedure.
Routine logical exports
For routine point-in-time exports, dump each application database and separately export cluster-wide roles and other global objects:
install -m 700 -d /var/backups/database/postgresql
pg_dump -Fc -d appdb
> /var/backups/database/postgresql/appdb-$(date +%F).dump
pg_dumpall --globals-only
> /var/backups/database/postgresql/globals-$(date +%F).sql
chmod 600 /var/backups/database/postgresql/*The custom format produced by pg_dump -Fc can be restored selectively with PostgreSQL’s restore utility. Keep the exact PostgreSQL major version, extensions, connection options, and dump date with the backup. A database dump can recreate indexes rather than copying their contents, so a raw file-system backup is often larger; size and restore-time trade-offs should be measured for your workload.
Rank #3
- Easily store and access 1TB to content on the go with the Seagate Portable Drive, a USB external hard drive.Specific uses: Personal
- Designed to work with Windows or Mac computers, this external hard drive makes backup a snap just drag and drop. Reformatting may be required for Mac
- To get set up, connect the portable hard drive to a computer for automatic recognition no software required
- This USB drive provides plug and play simplicity with the included 18 inch USB 3.0 cable
- The available storage capacity may vary.
Large databases and low data-loss objectives
When losing an entire dump interval is unacceptable, use PostgreSQL continuous archiving and WAL with a documented base-backup and WAL-restore procedure. A logical dump remains useful for object-level recovery, but it is not a substitute for a tested WAL chain. Record where archived WAL resides, how retention is enforced, and how to stop recovery at a chosen time.
Back up MySQL or MariaDB
Use a logical dump for portable recovery
The MySQL documentation describes mysqldump as a logical backup that emits SQL statements capable of recreating database objects and table data. A typical InnoDB export is:
install -m 700 -d /var/backups/database/mysql
mysqldump --single-transaction --routines --events --triggers
--hex-blob --databases appdb
> /var/backups/database/mysql/appdb-$(date +%F).sql
chmod 600 /var/backups/database/mysql/*--single-transaction gives InnoDB a consistent online view without blocking ordinary reads and writes, subject to the documented DDL restrictions. It does not make MyISAM or MEMORY tables consistent. Lock, quiesce, or separately handle nontransactional tables, and record the exact server version and options used.
Restore into a clean target
Restore to a clean database or isolated server rather than overwriting production during a drill:
mysql -u root -p -e 'CREATE DATABASE appdb'
mysql appdb < /restore/appdb-2026-10-15.sqlTest more than row counts. Verify users, grants, routines, events, triggers, character sets, collations, and application connectivity. If the dump was created with --databases, it may include database-creation statements; otherwise create the target database with the intended owner and encoding first.
Use snapshots for fast rollback, not as the only backup
A provider snapshot or an LVM, ZFS, or Btrfs snapshot is useful after a bad deployment or accidental deletion because it can return an entire volume to an earlier state quickly. The snapshot may still share the VPS’s disk, account, credentials, region, or provider. It can therefore be deleted, corrupted, encrypted, or made inaccessible in the same incident as the source.
Before taking a snapshot, create a database-native dump when practical. If you must snapshot a live database, quiesce writes or follow the database and storage vendor’s consistency procedure. PostgreSQL specifically warns that snapshots across separate volumes may not be simultaneous. Treat a snapshot as one recovery point and copy its exported contents, or an equivalent backup, to independent storage. Apply a retention policy that keeps more than the latest snapshot.
Do these 3 things before closing this tab:
1Fix the driver behind crashes, sound loss and screen glitches2Repair Windows errors before they cause bigger problems3Scan for outdated or missing drivers - takes under a minuteRank #4
- High capacity in a small enclosure – The small, lightweight design offers up to 6TB* capacity, making WD Elements portable hard drives the ideal companion for consumers on the go.
- Plug-and-play expandability
- Vast capacities up to 6TB[1] to store your photos, videos, music, important documents and more
- SuperSpeed USB 3.2 Gen 1 (5Gbps)
Automate ordering, retention, and alerting
Run dumps immediately before the file backup
The order matters: database dumps must finish before Restic captures the staging directory. A wrapper script should stop on errors, verify expected files, and return a non-zero status if any step fails.
#!/bin/sh
set -eu
stamp=$(date +%F-%H%M%S)
stage=/var/backups/database
log=/var/log/vps-backup.log
mkdir -p "$stage"
pg_dump -Fc -d appdb > "$stage/postgresql-appdb-$stamp.dump"
pg_dumpall --globals-only > "$stage/postgresql-globals-$stamp.sql"
mysqldump --single-transaction --routines --events --triggers
--databases appdb > "$stage/mysql-appdb-$stamp.sql"
[ -s "$stage/postgresql-appdb-$stamp.dump" ]
[ -s "$stage/postgresql-globals-$stamp.sql" ]
[ -s "$stage/mysql-appdb-$stamp.sql" ]
restic -r sftp:backupuser@backup-host:/srv/restic/vps01 backup
/etc /var/www /opt/apps "$stage" --tag scheduled
restic -r sftp:backupuser@backup-host:/srv/restic/vps01 forget
--keep-daily 7 --keep-weekly 4 --keep-monthly 6 --pruneUse either a systemd timer or cron. A systemd service can run with a restricted environment and send failures to the system journal; cron is adequate when its environment, output, and locking behavior are managed. Do not allow overlapping runs: use a lock mechanism or a systemd unit that serializes executions.
Monitor the job, repository, and destination
- Alert on a non-zero exit status from dump, Restic, or pruning commands.
- Alert when an expected dump file is missing, empty, unusually small, or older than the required interval.
- Watch for repository-lock failures and jobs that remain running far beyond their normal duration.
- Monitor destination capacity and object-storage lifecycle limits before they cause the next backup to fail.
- Run periodic repository integrity checks, and send a success signal only after the remote copy completes.
Secure the backup against theft and ransomware
- Encrypt before upload: Restic encrypts repository data, but protect the password as a separate secret. Losing the password makes the repository unusable; exposing it allows decryption.
- Separate credentials: Use storage credentials that cannot administer the VPS, and VPS credentials that cannot delete every remote retention point.
- Keep an offline or immutable copy: A removable disk or deletion-protected object-storage policy can preserve recovery points after an attacker obtains administrative access.
- Limit permissions: Backup directories should be inaccessible to ordinary web users, and private keys should not be readable by application processes unless required.
- Record rebuild information: Keep the operating-system release, package versions, database major versions, enabled extensions, DNS steps, TLS renewal method, and secret locations with the recovery documentation—but not the secrets themselves.
Restore procedure after disk failure or compromise
1. Isolate the incident
If ransomware or credential compromise is suspected, disconnect the affected VPS from public traffic, revoke exposed keys and tokens, and avoid mounting the original filesystem read-write. Preserve logs when they are needed for investigation. Do not restore into a host that still contains the attacker’s persistence.
2. Build a clean target
Provision a replacement VPS or clean disk with a supported operating system. Apply updates, configure a firewall and SSH access, install the required runtime and database major versions, and create service accounts. Restore DNS and TLS only after the application is ready or use a temporary hostname during validation.
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →3. Recover configuration and files
restic -r sftp:backupuser@backup-host:/srv/restic/vps01 snapshots
restic -r sftp:backupuser@backup-host:/srv/restic/vps01 restore <snapshot-id>
--target /restoreCopy back only the paths you have reviewed. Recreate ownership, permissions, systemd units, firewall rules, cron entries, and environment files. Rotate secrets rather than blindly restoring credentials that may have been exposed.
4. Restore PostgreSQL
createuser --createdb --pwprompt app_owner
createdb -O app_owner appdb
pg_restore --clean --if-exists --dbname=appdb
/restore/var/backups/database/postgresql/appdb.dump
psql --dbname=postgres
--file=/restore/var/backups/database/postgresql/globals.sqlRestore globals at the appropriate point for your environment, install required extensions, and check ownership and grants. If using WAL recovery, restore the base backup and WAL according to the documented recovery configuration, then stop at the intended recovery target.
5. Restore MySQL or MariaDB
mysql -u root -p -e 'CREATE DATABASE appdb'
mysql appdb < /restore/var/backups/database/mysql/appdb.sqlRecreate accounts and grants from your secured administration records, then validate routines, events, triggers, collations, and application queries. Keep the service offline until integrity checks and credential rotation are complete.
Best Value
- Plug-and-play expandability
- SuperSpeed USB 3.2 Gen 1 (5Gbps)
6. Validate before cutover
- Confirm the expected file count, ownership, permissions, and upload visibility.
- Run database consistency checks and representative read/write transactions.
- Test background jobs, outbound mail, queues, scheduled tasks, and TLS termination.
- Verify monitoring and backup jobs on the replacement host before changing production DNS.
- Record elapsed restore time and every manual action for the next incident.
Rehearse restores instead of trusting job logs
A successful backup command proves only that data was written somewhere. At a schedule appropriate to the service, restore into an isolated scratch VPS or local test environment:
Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Scan for outdated or missing drivers - takes under a minuteDriver Scan →- Restore one individual configuration or upload file and verify its contents and permissions.
- Restore a complete application tree, install its required packages, and start the service.
- Restore one PostgreSQL database plus roles, extensions, and a representative application query.
- Restore one MySQL or MariaDB database and test users, grants, routines, events, and triggers.
- Measure time from an empty target to a working service, including DNS, certificates, package installation, and secret rotation.
- Document failures such as missing credentials, incomplete dumps, permission errors, incompatible versions, or insufficient storage; correct the runbook and repeat the test.
Keep the restore record with the operational documentation. It should identify the snapshot or repository ID used, the software versions, commands run, expected validation results, and the person responsible for approving production cutover.
Common failure modes and fixes
“The backup completed, but the database will not start.”
The job probably copied live database files without a consistent snapshot or native export. Replace that step with pg_dump, pg_dumpall --globals-only, or an appropriate MySQL/MariaDB dump. For physical PostgreSQL recovery, retain the complete cluster and WAL context and test the documented procedure.
“The snapshot exists, but the provider account is unavailable.”
The snapshot shares the provider failure domain. Maintain a Restic repository or exported backup in independent storage, and periodically confirm that it can be accessed using credentials kept outside the VPS.
“MySQL tables disagree after restore.”
--single-transaction protects transactional InnoDB tables, not MyISAM or MEMORY tables, and DDL during the dump can affect consistency. Inventory storage engines, quiesce or lock nontransactional tables, and repeat a restore test with the production options.
“Restic reports a lock or missing repository.”
Check for an overlapping job, a stale lock after an interrupted run, repository credentials, remote connectivity, and destination capacity. Remove a stale lock only after confirming that no backup process is still using the repository; then run an integrity check and a small test restore.
“The backup is too large or slow.”
Exclude reproducible caches and temporary build output, avoid duplicate database files when logical dumps are the recovery method, and separate frequent database exports from less-frequent static-file snapshots. Measure compression, network throughput, prune duration, and restore time rather than optimizing only the upload.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
