Backing Up an InterServer VPS (2026): No Snapshots, So a Nightly restic Job to a $3 Storage Target

1. What InterServer does and does not provide

InterServer's VPS page mentions backups four times, all as something you add: "Backup path Add off-server storage with InterServer's Cloud Remote Backup Service when the VPS needs separate backups", "Remote backup storage is available when the server needs an off-server copy of important files and databases", "After launch, add backups, increase slices, or move into managed support when the server becomes production-critical", and, under Remote backups, "Add backup storage for VPS files, databases, and custom scripts with no transfer fees on the storage service." The page's "More about backups" link goes to InterServer's storage hosting page, which is the product behind those sentences.

What the VPS page does not mention is snapshots or images. On providers that sell them, a snapshot before an upgrade is the usual safety net; on an InterServer slice there is none to take, so the nightly off-server copy is both the disaster recovery and the rollback. That changes the priority: on a $3 server the backup job belongs in the first hour, before the application. The InterServer VPS guide lists it among the four rules to plan around.

2. Choosing the target: two InterServer options and two outside

The target must be a different machine, and for the price of the VPS itself InterServer sells two that qualify.

The storage hosting plans are, in InterServer's words, "Shared large-capacity storage for backups, downloadable files, media libraries, and private file access", on "Enterprise RAID-Z2 storage", and "Shared storage does not include root access"; every plan lists "DirectAdmin, FTP/SFTP access, Rsync over SSH". For a backup target that is exactly enough, and the $3 plan's 200 GB covers most small servers many times over. Storage Cloud Compute is the same $3 with a full Linux server and a 1 TB disk (its page: "Each storage VPS slice adds 1TB SATA storage, 2GB memory, 2TB transfer, and a predictable $3 monthly cost"), which suits someone who wants root on the target or several servers backing up to one place. An outside bucket costs pennies at this size and survives an InterServer account problem; the belt-and-braces arrangement is a nightly job to InterServer storage and a weekly copy of the repository to a bucket. This guide uses the $3 storage hosting plan over SFTP; the commands are the same for any SFTP host.

3. What to back up

• The application's files. The web root (/var/www or the site's directory), uploads, and anything under /home that you created.
• Configuration you changed. /etc as a whole is small and worth taking: nginx or Apache sites, PHP settings, the firewall rules, cron entries, systemd units you wrote.
• A database dump, not the database's files (section 5).
• Secrets you would need to rebuild: Let's Encrypt certificates and account (/etc/letsencrypt), SSH host keys if you want the server's identity to survive, application .env files.
• Not the operating system. Packages reinstall in minutes from a fresh InterServer template; what takes days to recreate is the data and the configuration above. A list of installed packages (dpkg --get-selections on Debian and Ubuntu) in the backup is enough.

4. restic over SFTP, step by step

restic is a free, open-source backup program that stores encrypted, deduplicated snapshots in a repository; it is in Debian's and Ubuntu's repositories ("On Debian, there's a package called restic which can be installed from the official repos, e.g. with apt-get: apt-get install restic") and Fedora's (dnf install restic), and its documentation lists SFTP, S3, Backblaze B2 and a dozen other backends. The sequence on the VPS, as root:

1. Order the storage plan and note the SSH hostname and username InterServer issues. The DirectAdmin panel on the storage account is where SSH access and keys are managed; InterServer's knowledge base has the click-level steps and is linked in Sources.
2. Key-based SSH from the VPS to the target. restic's documentation: "In order to backup data via SFTP, you must first set up a server with SSH and let it know your public key. Passwordless login is important since automatic backups are not possible if the server prompts for credentials." Generate a key on the VPS (ssh-keygen -t ed25519 -f /root/.ssh/backup -N ""), add the public half to the storage account, and confirm sftp -i /root/.ssh/backup user@host connects without a prompt. Put the key in /root/.ssh/config as the identity for that host so restic's URL stays short.
3. Initialise the repository. From the documentation: restic -r sftp:user@host:/srv/restic-repo init; on shared storage use a relative path, which the documentation notes "is relative to the remote user's home directory", such as sftp:user@host:restic-repo. Choose a strong repository password and store it in a password manager and in /root/.restic-password (mode 600). The documentation's warning is not decorative: "Losing your password means that your data is irrecoverably lost."
4. First backup. restic -r sftp:user@host:restic-repo --password-file /root/.restic-password backup /var/www /etc /home /etc/letsencrypt. The documentation's example output shows what to expect: a scan, then "Added to the repository", then a final line naming the saved snapshot. Add --exclude for caches and logs you do not want (--exclude /var/www/*/cache), or --exclude-file with a list.
5. Check it. restic -r ... snapshots lists what is there; restic -r ... check verifies the repository's integrity. Run check monthly from the same cron file.

5. The database

A running MySQL, MariaDB or PostgreSQL writes to its files continuously; a file copy taken mid-write is not guaranteed to load. The database's own dump tool produces a consistent copy, and restic can take that copy directly from the tool's output without writing a temporary file. The documentation's example: restic -r /srv/restic-repo backup --stdin-from-command -- mysqldump --host example mydb, which "creates a new snapshot based on the standard output of mysqldump", saved by default in a file named stdin inside the snapshot; --stdin-filename mydb.sql gives it a better name. For a local MariaDB with root's credentials in /root/.my.cnf the command is restic -r sftp:user@host:restic-repo --password-file /root/.restic-password backup --stdin-from-command --stdin-filename all-databases.sql -- mysqldump --all-databases --single-transaction; PostgreSQL users substitute pg_dumpall run as the postgres user. Run this in the same nightly script as the file backup, so the dump and the files are from the same night.

6. Schedule and retention

One script, one cron entry. /root/backup.sh holds the two restic backup commands from sections 4 and 5, then the retention command; chmod 700 it; and in root's crontab, 15 3 * * * /root/backup.sh >> /var/log/backup.log 2>&1 runs it at 03:15 server time. Pick an hour when the site is quiet and the InterServer storage account is not being used for anything else.

Retention is restic's forget command with a policy. From the documentation: "All backup space is finite, so restic allows removing old snapshots", either by snapshot ID or "by using a policy that describes which snapshots to forget", and "two commands need to be called in sequence: forget to remove snapshots, and prune to remove the remaining data that was referenced only by the removed snapshots", which "can be automated with the --prune option of forget". The policy flags: --keep-daily n is documented as "for the last n days which have one or more snapshots, keep only the most recent one for each day", and --keep-weekly and --keep-monthly do the same per week and month. A reasonable line for a small server, run weekly rather than nightly because prune does real work: restic -r sftp:user@host:restic-repo --password-file /root/.restic-password forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune. Watch the log for the first month; a growing repository on a 200 GB target is the sign that an exclude is missing.

7. Restoring, and the restore test

From the documentation: "Restoring a snapshot is as easy as it sounds", with restic -r ... restore <id> --target /tmp/restore, and "Use the word latest to restore the latest snapshot", optionally filtered with --host and --path. Three situations:

• One file or directory deleted or overwritten: restore latest --target /tmp/restore --include /var/www/site/wp-config.php, then copy it into place.
• The database after a bad migration: restore the all-databases.sql file from the last good night and load it with mysql < all-databases.sql. Everything written since that night is gone, which is the cost of no snapshots and the reason the job runs nightly rather than weekly.
• The whole server after a failed upgrade or a compromise: order a fresh slice (or reinstall the OS from My.InterServer), install the packages from your list, install restic, restore /etc pieces and the web root into place, load the database, point DNS if the IP changed. The migration guide is the same procedure with a different reason.

The test is the third bullet in miniature: restore latest to /tmp/restore, open a few files, load the dump into a scratch database, and delete the directory. Do it when the job is new and once a quarter after. Until it has been done once, the backup is a hope.

8. If you run cPanel, Webuzo or Windows

• cPanel. WHM's Backup Configuration schedules account backups and sends them to an Additional Destination; SFTP and Rsync are among the destination types, and cPanel's documentation strongly recommends a remote destination. The InterServer storage account is that destination. The cPanel guide has the steps. Use the panel's tool rather than restic for the accounts; use restic only if you installed things outside cPanel.
• Webuzo. The end-user panel's backup utility schedules full, home, database and mail backups to a remote SSH, FTP, Google Drive or S3 server, with a rotation limit. Same target, same advice; the Webuzo guide covers it.
• Windows. Windows Server Backup (a feature added from Server Manager) writes scheduled backups to a network share; the InterServer storage account is reachable as SFTP rather than SMB, so the practical arrangement is a scheduled task that exports the database and copies the working folder with an SFTP client such as WinSCP's command line, or a Storage Cloud Compute slice running Samba as the share. The Windows guide has the context; the arrangement is this guide's suggestion rather than a documented product path.

9. Before a risky change: the manual snapshot you can make

A snapshot is what you take before upgrading PHP, changing a database engine or applying a large application update. Without one, take a restic snapshot by hand, which is a single command (the backup line from section 4 plus the database line from section 5, or simply /root/backup.sh), and tag it so you can find it: add --tag pre-upgrade to both backup commands. If the change goes wrong, section 7's second or third bullet gets you back to that point. It is slower than a provider snapshot and it is enough; and it is one of the things a $3 server asks you to do yourself.