Free tools Windows power users keep installed
One-click scans. No signup required.
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
Antihost offers Linux VPS plans with full root access, unlimited traffic on a 1 Gbps port and a 14-day free trial.
The safest way to store personal Linux VPS backups is to keep more than one encrypted copy in different failure domains: prepare consistent application exports, create encrypted deduplicated snapshots with restic or Borg, retain a fast repository for routine restores, replicate it off-site, and rotate an encrypted external drive when the data justifies one. Keep passwords and key exports away from the VPS, define retention before storage fills, and regularly perform test restores.
What a dependable VPS backup archive contains
A backup archive is useful only if it can recreate the services and data you actually need. Treat the VPS as several kinds of data rather than one directory tree:
- Application data: uploaded files, media, documents, mail stores, and user-generated content.
- Databases: PostgreSQL, MySQL/MariaDB, SQLite, and other data stores that may be inconsistent if copied while a transaction is in progress.
- Configuration: web-server virtual hosts, service units, environment files, firewall rules, cron jobs, deployment scripts, and certificates.
- System and identity information: package lists, account and group definitions, SSH configuration, and access-control settings.
- Recovery documentation: the VPS provider, operating-system release, DNS details, repository locations, tool versions, passwords, key exports, and restoration commands.
Do not assume that a provider’s VM snapshot is the same as an application-consistent archive. A snapshot can be valuable for quickly cloning a machine, while a file-and-database archive gives you selective recovery and a second storage location. Use both when the service is important enough to warrant rapid rollback and independent recovery.
Use a layered storage design
A practical personal design has several layers. Each layer solves a different failure mode, so no single copy has to do everything.
#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 exports on the VPS. Dump databases and pause, flush, or otherwise quiesce applications where necessary. Write the exports to a protected staging directory.
- Create an encrypted repository. Run restic or Borg on the VPS. Both deduplicate unchanged content so later snapshots do not copy every byte again.
- Keep a fast recovery copy. Use a separate attached volume or another local repository for quick restores. A repository on the same disk as the VPS is not an independent backup.
- Replicate away from the host. Copy or write snapshots to a geographically separate server or object-storage destination. This protects against host deletion, provider outages, and incidents at the VPS site.
- Rotate an offline copy when warranted. An encrypted external hard drive or SSD disconnected after each rotation limits the damage a compromised VPS or storage credential can do.
- Separate recovery secrets. Keep repository passwords, key exports, and restoration notes in a password manager or other independent location, not only in the VPS filesystem.
- Verify and rehearse. List snapshots, run repository checks, and restore representative files and databases on a separate directory or replacement host.
Canonical’s Ubuntu Server backup guidance recommends storing important backup media off-site for disaster protection. The principle applies even when your primary archive is a modern encrypted repository.
Choose between restic and Borg
Restic and Borg both run client-side encryption and content-defined deduplication. They differ mainly in repository layout, transport conventions, and restore workflow. Select one, standardize its version, and document it rather than maintaining several half-configured systems.
| Decision point | Restic | Borg |
|---|---|---|
| Repository model | A repository directory containing encrypted data, metadata, and keys; it can be local or remote. | A self-contained repository of encrypted objects and archives; local paths and SSH repositories are common. |
| Space efficiency | Content-defined chunking and deduplication; later snapshots reuse existing chunks. | Content-defined chunking and deduplication; unchanged chunks are reused. |
| Encryption and integrity | Client-side encryption with authenticated repository contents. | Client-side encryption with authenticated integrity; export and protect the key. |
| Compression | Supported in current documentation; choose settings according to CPU and transfer limits. | Offers compression choices, including fast and higher-ratio modes such as zstd. |
| Restore style | List snapshots and restore selected paths; supported workflows can mount a repository. | Extract an archive or mount it as a user-space filesystem. |
| Important operational risk | Encryption does not prevent an attacker who can reach the storage location from deleting repository data. | Encryption does not prevent a remote-server attacker from deleting archives or making them unavailable. |
When restic is a good fit
Restic is convenient when you want one command-line client that can target a local directory, an SSH-accessible location, or an object-storage endpoint. Its repository is portable as a directory, and the snapshot-oriented commands are easy to automate. Account for CPU use and transfer limits when selecting compression and scheduling large first backups.
When Borg is a good fit
Borg is attractive when SSH-controlled storage and archive-oriented operations match your environment. Its documentation describes the division clearly: the server performs low-level repository operations while the client handles deduplication, encryption, compression, archives, backups, and restores. A Borg archive is the result of one borg create operation, so each archive represents a recoverable point in time.
Do not confuse encryption with deletion protection
Both tools protect confidentiality and authenticate stored content, but neither promises that an administrator or stolen storage credential cannot erase the repository. Restrict the destination account, use append-only or equivalent write restrictions where supported, and retain an independent copy. A repository that is encrypted but writable and erasable by the same compromised host is not ransomware-resistant by itself.
Prepare application-consistent data before archiving
Filesystem snapshots taken while a database is changing may contain files that do not agree with one another. Export databases first, then include the resulting dump in the restic or Borg run.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →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.
PostgreSQL
Run a logical export with the database’s supported client tools, for example:
install -d -m 700 /var/backups/vps/staging
pg_dump --format=custom --file=/var/backups/vps/staging/app-$(date +%F).dump appdbUse a role with the required privileges, protect the dump directory, and retain enough space for both the dump and the repository’s temporary work. A custom-format dump is restored with PostgreSQL’s restore tool; record the server and client versions used in your runbook.
MySQL or MariaDB
install -d -m 700 /var/backups/vps/staging
mysqldump --single-transaction --routines --events --all-databases > /var/backups/vps/staging/mysql-$(date +%F).sqlThe transaction option is appropriate for transactional tables, but it does not make every engine or non-transactional table consistent. Confirm the dump completed successfully before archiving it and test an import into a disposable instance.
SQLite and file-based applications
Use the application’s own backup or dump mechanism when one exists. Otherwise, stop writes briefly or use the database’s online-backup facility. Copying a live SQLite file without a consistency plan can produce an archive that exists but cannot be opened reliably.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Fix the driver behind crashes, sound loss and screen glitches3Repair Windows errors before they cause bigger problemsApplication quiescing checklist
- Pause background workers and scheduled jobs that write during the export.
- Flush queued uploads and confirm no deployment is changing the same files.
- Record the export’s timestamp and database schema version.
- Check exit codes and file sizes before invoking the repository tool.
- Delete staging dumps only after the encrypted snapshot is confirmed and policy permits it.
Build a restic repository on the VPS
The following is a representative local-repository workflow. Adjust paths, ownership, and service accounts to your distribution. Install restic from a trusted package source, pin or record the version, and never place the repository password directly in a shell history entry.
- Create protected storage. Mount a separate volume at a path such as
/srv/restic-repo. Set ownership and permissions so only the backup account can read it. - Provide the password out of band. For example, create a root-readable password file outside the web tree and set
RESTIC_PASSWORD_FILEin the service environment. - Initialize once.
restic -r /srv/restic-repo initSave the generated repository information and a key export in your independent recovery store.
- Back up the staged data and required paths.
restic -r /srv/restic-repo backup /etc /home /var/www /var/backups/vps/stagingExclude caches, temporary build trees, and other reproducible data deliberately rather than excluding broad directories by habit.
- Inspect snapshots.
restic -r /srv/restic-repo snapshotsConfirm the expected host, paths, timestamp, and snapshot identifier.
- Apply retention only after deciding recovery needs. Use restic’s retention command with explicit daily, weekly, monthly, or tag-based rules that match your written policy. Preview the result before deleting anything.
- Check repository integrity.
restic -r /srv/restic-repo checkSchedule checks separately from backups so a successful upload is not mistaken for proof of recoverability.
For an SSH destination, use the repository syntax supported by your installed restic version, such as an SFTP-style location, and restrict the remote account to the repository directory. For object storage, create a dedicated bucket or equivalent destination and credentials that cannot administer unrelated data.
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.
Build a Borg repository on the VPS
Borg calls each point-in-time backup an archive inside a repository. The commands below illustrate the sequence; verify option names against the Borg version installed on both sides.
- Prepare a separate repository filesystem. Ensure the destination and Borg’s local cache have free space for indexes, temporary files, and compaction.
- Initialize with authenticated encryption.
borg init --encryption=repokey-blake2 /srv/borg-repoExport the repository key and store it away from the VPS. Losing the key or password can make otherwise intact encrypted data unusable.
- Create an archive.
borg create --stats /srv/borg-repo::'{hostname}-{now}' /etc /home /var/www /var/backups/vps/stagingReview warnings and the exit status. Exclude caches and transient paths with carefully tested patterns.
- List available recovery points.
borg list /srv/borg-repoUse the archive name and timestamp to select a restore point.
- Prune according to policy. Define explicit keep rules for recent, weekly, monthly, and milestone archives. Run a dry run first, then compact when needed and when adequate free space is available.
- Verify the repository.
borg check /srv/borg-repoSchedule checks and monitor their exit status.
With a remote SSH repository, the client performs the high-level backup work while the server handles low-level repository operations. Give the remote account only the access it needs, and apply append-only restrictions if your deployment supports them.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Place copies in different failure domains
Fast local or attached storage
A separate volume on the VPS host usually gives the fastest restore and avoids repeated network transfer. It does not protect against provider account deletion, a damaged host, a stolen disk, or an attacker who can write to both the VPS and its attached volume. Treat it as a recovery cache, not your only archive.
Off-site repository or object storage
Replicate encrypted snapshots to a different site or provider. Keep credentials narrow: a backup process should not be able to delete every bucket, account, or server you own. Where possible, use an append-only repository endpoint, retention lock, or a separate replication identity. Encryption occurs before data leaves the VPS, but availability still depends on destination permissions and service continuity.
Rotated external hard drive or SSD
An external drive is useful when you can disconnect it after a backup rotation. Encrypt it, label it with the date and repository type, store it in a safe location, and maintain at least one copy away from the VPS. Test the drive periodically; an offline disk that has silently failed is not a usable backup. Rotate drives so one can remain offline while another is updated.
Keep copies independent
Do not mount an offline drive permanently or expose its credentials to the VPS. If ransomware reaches the running server, it should not have a path to erase every historical copy. Keep repository passwords, key exports, and recovery notes in a separate account or physical location with a documented access procedure.
Rank #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)
Design retention around recovery objectives
Retention should answer how far back you may need to go and how much data loss each application can tolerate. More snapshots consume storage, but deleting aggressively can remove the only point before an unnoticed corruption or intrusion.
| Recovery need | Illustrative policy pattern | What to decide |
|---|---|---|
| Recent operational mistakes | Frequent snapshots kept for a short window. | Maximum acceptable gap between snapshots and the time needed to notice an error. |
| Weekly service recovery | One or more snapshots per week retained longer than the recent window. | How many weeks of history are required for ordinary troubleshooting. |
| Long-term rollback | Monthly or milestone snapshots retained for the period required by the project or records policy. | Whether old application versions, schemas, and keys remain restorable. |
| Incident investigation | Protected copies that an administrator on the VPS cannot rewrite or delete. | Who can release or expire them and how that action is audited. |
The exact counts depend on archive size, change rate, storage cost, and the cost of losing a particular period. Measure repository growth after several normal runs, then leave headroom for indexes, temporary files, compaction, and a full restore.
Automate without hiding failures
Run the backup from a dedicated service account or system timer. A reliable job should:
Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Repair Windows errors before they cause bigger problemsFix Now →- create or refresh database dumps;
- verify that exports completed and are not unexpectedly empty;
- run restic or Borg with a timeout appropriate to the dataset;
- record logs and exit codes;
- apply retention only after a successful backup;
- replicate to the off-site destination;
- send an alert when any stage fails; and
- periodically execute repository checks and a restore drill.
Prevent overlapping runs with a lock. Avoid putting passwords in unit files readable by unrelated users, process arguments, or chat notifications. Test the timer after installation by triggering one run manually and examining its journal output.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Verify that an archive can actually be restored
Repository listing proves that metadata is readable; it does not prove that an application will start. Schedule a recovery exercise on a separate directory, disposable VM, or replacement VPS.
- Confirm prerequisites. Record the operating-system release, restic or Borg version, database clients, service packages, and required credentials.
- Retrieve secrets. Obtain the repository password and key export from their independent storage. Confirm that the procedure does not depend on the failed VPS.
- List snapshots or archives. Select a known date and record its identifier.
- Restore representative files. Restore configuration, a user upload, a certificate or key only into a protected test location, and a recent application directory.
- Restore a database dump. Import it into a disposable database instance, run schema and row-count checks, and exercise a read-only application workflow.
- Test service startup. Validate file ownership, permissions, environment variables, network bindings, and scheduled jobs.
- Record elapsed time and gaps. Note what was missing, which versions were needed, and every command required. Update the runbook while the details are fresh.
For a planned host replacement, perform the same drill with a clean operating system. Recovery time includes downloading the archive, rebuilding packages, restoring data, changing DNS, and validating the application—not just the repository command.
Best Value
- Plug-and-play expandability
- SuperSpeed USB 3.2 Gen 1 (5Gbps)
Troubleshoot common failure modes
The repository fills unexpectedly
- Check whether database dumps, logs, caches, or build artifacts are being archived repeatedly.
- Inspect retention results and repository growth over time.
- Leave space for indexes, temporary files, and compaction; do not run a cleanup that removes the only recent recovery point.
- Move large, reproducible artifacts to a deliberate exclusion or separate retention policy.
A backup succeeds but the off-site copy is missing
- Check the replication job’s exit status and destination authentication separately from the local backup.
- Confirm that the remote path or bucket is the one documented, not a newly created empty location.
- List snapshots from the destination using an independent session.
- Alert on transfer failures instead of relying on local job success.
The password or key is unavailable
Encrypted repositories cannot be recovered by guessing a missing secret. Store the password and key export in at least one independent, access-controlled location and include retrieval instructions in the recovery plan. Perform a test retrieval before an emergency.
Integrity checks report errors
Stop pruning and investigate. Preserve another copy, inspect the destination filesystem and hardware, rerun checks as documented by the tool, and restore from an independent repository if corruption is confirmed. Do not overwrite the only known-good copy while troubleshooting.
Restored files have the wrong owner or permissions
Restore into a controlled directory first, then reapply service users, groups, modes, ACLs, and security contexts appropriate to the replacement host. A byte-for-byte restore is not automatically a correctly configured service.
The VPS is compromised
Assume credentials present on the host may be exposed. Isolate the machine, revoke or rotate destination credentials, preserve an offline or append-only copy, and restore onto a clean host. Do not trust a running compromised system to certify its own backups.
Document the recovery runbook
Keep a short, printable runbook outside the VPS. It should identify:
Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteWindows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstall- provider and region, hostname, DNS provider, and replacement-host procedure;
- operating-system release and package repositories;
- restic or Borg version and repository type;
- local and off-site repository locations;
- password-manager record and key-export location;
- database dump and restore commands;
- retention and rotation schedule;
- contacts authorized to access encrypted media; and
- the date and result of the last successful restore test.
Keep sensitive values out of the document itself when possible; reference a protected secret location and verify that an authorized person can reach it during an outage.
Quick Recap
A practical decision checklist
- Can you recreate each database from an export, not just copy its live files?
- Does at least one repository live outside the VPS provider’s failure domain?
- Can the compromised VPS delete every destination copy?
- Are repository passwords and key exports available without the VPS?
- Is there enough free space for normal repository maintenance?
- Do alerts distinguish a successful local snapshot from a failed replication?
- Have you restored a file and a database recently on a separate environment?
- Is an encrypted, disconnected external drive appropriate for the value and change rate of the data?
