How to back up your VPS yourself: the full walkthrough

Open the WeaselCloud client area and look at what you can actually do with a running VPS: change the service, or change the plan. That's the entire list. There's no "back up now" button and no snapshot section anywhere on the service page, so backing up a VPS is a task you own end to end, not something the panel does in the background. Start from this: a copy sitting in a second folder on the same disk isn't a backup. If the server dies outright, from a bad disk, a wrong command, or someone else's mistake, that second folder dies with it.

Short version. Pull files off the server with tar (a one-off archive) or rsync (a repeatable sync) to somewhere else entirely: your own machine, a second VPS, or object storage. Dump databases separately with mysqldump or pg_dump. For anything you actually want to rely on, use restic: it encrypts and deduplicates on its own, only uploads what changed, and talks to plain SFTP or S3-compatible storage without needing anything installed on the other end. Run it on a schedule with a systemd timer, keep copies following the 3-2-1 rule, and once a month actually restore from a backup onto a separate machine - otherwise you have no idea whether it works.

WeaselCloud has no built-in VPS backup or snapshot feature

The service page in my.weasel.cloud shows an overview, a "Hosting Information" tab with the server's IP and password, some read-only configuration details, and an "Actions" block with exactly two options: switch service, or change your plan. A snapshot (an instant, whole-disk state a panel captures for you with one click) isn't among them, and neither is a console or a reboot button - the panel here is thin, essentially a billing wrapper around the server rather than a full management layer.

That's not unusual for budget VPS providers: plenty leave backups entirely to the customer and sell their own snapshot tooling as a paid extra, if they sell it at all. We didn't find anything like that in the parts of the WeaselCloud panel we checked. If your account shows something resembling a backup service, confirm it with support, but don't plan around it existing by default.

Files: tar for a one-off snapshot, rsync for an ongoing VPS backup

Files call for two tools depending on the job. tar (short for tape archive, from its original job writing to tape drives) bundles files into a single archive in one pass. Fine before a risky upgrade or a migration, awkward for something you repeat daily, since it rebuilds the whole archive from scratch every time.

tar -czvf backup-$(date +%F).tar.gz /etc /var/www /home

• -c creates a new archive, -z compresses it with gzip, -v lists files as it works, -f names the output file
• $(date +%F) stamps the filename with today's date, like 2026-09-24, so archives don't overwrite each other
• list only what you'd actually need to restore, configs, site files, home directories. Archiving the entire filesystem, /proc and /sys included, is both pointless and slow

The archive still needs to leave the server, even a plain scp backup-2026-09-24.tar.gz user@backup-host:/backups/ does the job. While the file only exists on the source VPS, it's not a backup, it's just another file on the same disk.

For something you run repeatedly, rsync is the better fit, since it only uploads what actually changed instead of rebuilding everything:

rsync -aAX --delete /var/www/ user@backup-host:/backups/var-www/

• -a (archive mode) keeps permissions, modification times, symlinks, and ownership intact
• -A carries over ACLs (extended permissions, if you use them), -X carries over extended filesystem attributes
• --delete removes files on the destination that no longer exist on the source, so you end up with a mirror rather than a history of versions. Only use it when you genuinely want an exact current copy, not a record of past states

Databases: mysqldump and pg_dump, briefly

Copying the raw database files with tar while MySQL or PostgreSQL is running is a bad idea: mid-write, a file can end up in an inconsistent state. The right approach is a logical dump produced by the database engine itself.

mysqldump --single-transaction --quick mydb | gzip > mydb-$(date +%F).sql.gz

• --single-transaction takes a consistent snapshot inside one transaction, without locking InnoDB tables for the duration of the dump
• --quick streams the table row by row instead of loading it all into memory, which matters on larger databases

PostgreSQL's equivalent:

pg_dump -Fc mydb > mydb-$(date +%F).dump

• -Fc is pg_dump's own compressed format, which lets you restore individual tables later through pg_restore instead of only the whole database at once

That's a whole topic on its own, so this is only the bare minimum: the dump file sits next to your other files and rides along on the same rsync job, or the same restic run covered next.

A step up from tar and rsync: restic, not borg

tar and rsync get the job done, but neither gives you version history, encryption, or real deduplication out of the box - you either keep N full copies, or just the latest one. A tool one level up handles all three: it backs up incrementally (only storing what changed since last time, while each snapshot still restores as a complete point-in-time copy), encrypts data before it leaves the server, and deduplicates, meaning identical chunks of data are stored once even if they show up across multiple files or snapshots.

Between the two well-known options, restic and borg, restic is the one we'd point you at for a typical VPS, for a concrete reason: it speaks SFTP, S3-compatible storage, and a handful of other backends directly, needing nothing on the far end beyond SSH access. Borg usually needs the borg binary installed on the remote machine too, since it runs its own process there over SSH. If your second storage location is someone else's server or an object store you'd rather not load with extra software, restic is simply less hassle. Borg's deduplication has a longer track record, which makes it worth a separate look when both ends are fully under your control and the data volume is large.

The minimal restic setup

Install restic and set up a repository, the place where your encrypted snapshots live:

sudo apt install -y restic

export RESTIC_REPOSITORY=sftp:user@backup-host:/srv/restic-repo

export RESTIC_PASSWORD='repository-password-not-your-server-password'

restic init

• the repository password is a separate secret that encrypts every snapshot. Lose it and the whole backup becomes unreadable, so keep it somewhere other than the server itself
• the restic package in Ubuntu's default repository can trail the latest GitHub release by a version or two. If you need newer flags, grab the current binary from the releases page instead

Running a backup and listing what's there:

restic backup /etc /var/www /home

restic snapshots

The first run copies everything, every run after that copies only the differences, but each entry in restic snapshots still restores as if it were a full, independent copy taken at that moment.

Keep snapshots from piling up forever with a retention policy:

restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

• keeps one snapshot per day for the last 7 days, one per week for the last 4 weeks, and one per month for the last 6 months; everything else gets marked for removal
• --prune actually frees the space right away. Without it, forgotten snapshots just stop showing up, but the disk space they used stays locked in the repository

Automating a VPS backup: a systemd timer or cron

A command you remember to run by hand once a week eventually gets forgotten, so put the backup on a schedule. Systemd is Linux's standard service manager; besides running regular services, it can also run scheduled jobs through a pair of unit files, a timer and the service it triggers.

First, keep the repository password out of the unit file itself, in a separate file:

sudo tee /etc/restic/env >/dev/null <<'EOF'

RESTIC_REPOSITORY=sftp:user@backup-host:/srv/restic-repo

RESTIC_PASSWORD=repository-password

EOF

sudo chmod 600 /etc/restic/env

• chmod 600 restricts the file to root only. It holds the secret that unlocks every backup you've made

The service that actually runs the backup, /etc/systemd/system/backup.service:

[Unit]

Description=Daily restic backup

[Service]

Type=oneshot

EnvironmentFile=/etc/restic/env

ExecStart=/usr/bin/restic backup /etc /var/www /home

ExecStartPost=/usr/bin/restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

• Type=oneshot means the service runs the command once and exits, unlike a long-running service such as a web server
• ExecStartPost runs right after a successful backup and takes care of cleaning up old snapshots per the retention policy

And the timer that triggers it, /etc/systemd/system/backup.timer:

[Unit]

Description=Daily backup timer

[Timer]

OnCalendar=*-*-* 03:00:00

Persistent=true

RandomizedDelaySec=600

[Install]

WantedBy=timers.target

• OnCalendar sets the schedule, here every day at 3 AM, when load tends to be lower
• Persistent=true means that if the server was off at the scheduled time (say, during a plan upgrade), the job runs as soon as it's back up instead of waiting for the next scheduled slot
• RandomizedDelaySec=600 adds a random delay of up to 10 minutes, useful if you run several servers and don't want them all hitting the same backup host at once

Turn the timer on:

sudo systemctl daemon-reload

sudo systemctl enable --now backup.timer

What success looks like: systemctl list-timers backup.timer shows a line with the next scheduled run. Check a specific run's logs with journalctl -u backup.service - the service's own log output, not a live stream of restic's per-file progress.

If a systemd timer feels like overkill for one command, a plain crontab entry works too: crontab -e, then 0 3 * * * /usr/bin/restic backup /etc /var/www /home >> /var/log/restic-backup.log 2>&1. Cron is quicker to set up; a systemd timer is easier to inspect through journalctl and doesn't silently skip a run missed while the server was off.

Since the second storage location is another server or a cloud service, the VPS needs to reach it over the network: SSH on port 22 for SFTP, or 443 for S3-compatible storage. ufw doesn't block outgoing connections by default, but if you changed that policy following the basic ufw firewall guide, run sudo ufw status before debugging why restic can't reach its repository.

The 3-2-1 rule: how many copies, and where

The 3-2-1 rule isn't a vague suggestion, it's a concrete target: 3 copies of your data in total, on 2 different kinds of storage, with at least 1 copy kept somewhere physically separate from the original.

For a VPS: copy 1 is the live files on the server, which is working data, not a backup. Copy 2 is a backup on different storage, your own computer or an external service. Copy 3 is a second backup physically apart from the first: a different data center, provider, or region. The point is that no single incident, a data center fire or a provider outage, should be able to take out every copy at once.

If growing retention or sheer data volume leaves no room for even a temporary local archive before it ships off, that's a reason to size up your VPS plan rather than trim the backup schedule.

Test that your backup actually restores

A backup nobody has ever restored isn't reliable, it's a file whose contents you're simply assuming are fine. A corrupted archive, wrong permissions, a forgotten repository password all surface at restore time, not at backup time - better to find that out on your own schedule than when the server is already gone.

restic restore latest --target /tmp/restore-test

• latest picks the most recent snapshot matching the paths you backed up
• --target is where the files get unpacked. Use a scratch directory, or a separate test machine entirely, so you don't overwrite anything on the live server by accident

Set yourself a simple rule: once a month, actually restore a recent snapshot and check at least one known file against it, or restore a database dump into a throwaway copy of the engine. It takes 10-15 minutes and turns "probably works" into something you've actually verified.

FAQ

Does WeaselCloud have VPS snapshots?

Not in the parts of the client area we checked. The service page's Actions block only has options to switch service or change your plan, with nothing resembling a snapshot or backup feature. Backups are entirely the customer's responsibility to set up.

Restic or borg, which one should I use?

For a VPS backing up to a remote location you don't want to load with extra software, restic: it works over SFTP and S3-compatible storage without anything installed on the other end. Borg usually needs its own binary on the receiving side too, but its deduplication has a longer track record - worth choosing when both ends are fully under your control.

Where should I store VPS backups if I don't have a second server?

S3-compatible object storage works well. Plain SFTP access on any other machine works too, including a home computer that's always on, or a low-cost second VPS in a different region used purely as a backup target.

How do I automate a server backup?

With a systemd timer (a pair of unit files: a service that runs the actual command, and a timer that schedules it) or with plain cron. The systemd route is easier to check through journalctl and doesn't quietly skip a run missed while the server was off, thanks to Persistent=true.

Do I need to stop my site while backing it up?

For files, usually not: rsync and restic just read files as they are. For databases, you don't need downtime either, as long as you use the right dump flag: --single-transaction on mysqldump takes a consistent snapshot without locking InnoDB tables for the whole dump.

How do I know if a backup actually works?

Restore it for real, on a regular basis, at least once a month: unpack a recent snapshot with something like restic restore latest --target /some/dir into a scratch folder or a test machine, and check what comes out. Until a restore has actually been tested, a backup can't be trusted no matter how regularly it's being created.

Takeaways

• The parts of the WeaselCloud panel we checked have no snapshot feature and no backup button - backing up a VPS is entirely on the customer to set up.
• A copy sitting on the same disk as the original isn't a backup: files need to leave the server for your own machine, a second VPS, or object storage.
• Files: tar for a one-off snapshot, rsync -aAX for an ongoing sync. Databases: mysqldump --single-transaction or pg_dump -Fc.
• restic is the main tool for incremental, encrypted, deduplicated backups, working with SFTP and S3-compatible storage without installing anything on the other end; borg is the alternative when both ends are under your own control.
• Automate it with a systemd timer (scheduled runs, logs through journalctl) or cron; a remote target means the server needs outbound network access.
• The 3-2-1 rule: 3 copies, on 2 different kinds of storage, with at least 1 kept somewhere else entirely.
• A backup nobody has restored is an unverified backup - restore a recent snapshot for real once a month and check what comes out.

What's next

• Securing a fresh VPS: what to do in the first 10 minutes - worth doing before you even set up backups.
• Basic ufw firewall on a VPS - what to check in your outbound rules if the server can't reach a second storage location.
• Changing your VPS plan on WeaselCloud - if your backups and working data have outgrown the current disk.