VPS server: backup and monitoring

What you'll achieve

• know which server backups exist and how to request a restore;
• make your own database backups, which can be restored separately;
• check in two minutes whether the server is healthy.

The backups you can have

The automatic backup and the snapshot restore the whole server at once, to the time of the backup: anything that changed afterwards is lost. Your own backups let you restore just one database or just one folder.

You choose the automatic backup when you order; the price, by plan, is on the VPS servers page. If you didn't select it and want it now, contact us and we'll tell you how to add it.

The steps

A. Request a snapshot before a major change

1. Before a major update, an application reinstall or a data migration, email us or message us on WhatsApp: “Snapshot for the server with IP …, before …”.
2. Wait for our confirmation before you start the change.
3. How many snapshots can exist at the same time depends on the plan: 1 on VPS 1, 2 on VPS 2, 3 from VPS 3 up. When the limit is reached, an old one has to be deleted.

B. Make daily database backups

4. Create a folder for the backups:

   sudo mkdir -p /var/backups/baze && sudo chmod 700 /var/backups/baze

5. Open root's scheduled tasks: sudo crontab -e. Add one line, depending on the database you use:

   • MySQL or MariaDB, every night at 03:15, keeping 14 days:

     15 3 * * * mysqldump --single-transaction --all-databases | gzip > /var/backups/baze/mysql-$(date +\%F).sql.gz && find /var/backups/baze -name 'mysql-*.sql.gz' -mtime +14 -delete

   • PostgreSQL:

     15 3 * * * sudo -u postgres pg_dumpall | gzip > /var/backups/baze/pg-$(date +\%F).sql.gz && find /var/backups/baze -name 'pg-*.sql.gz' -mtime +14 -delete

   The time is the server's time (timedatectl shows it). In crontab, the % sign is written as \%.

6. The next day, check: ls -lh /var/backups/baze. A file of just a few bytes means the backup failed.
7. A backup on the same server won't protect you if the server fails. Copy your backups somewhere else from time to time: to your computer (scp ana@203.0.113.7:/var/backups/baze/* .) or to object storage, the add-on you can choose when you order, which is separate from the server.
8. Test a restore every few months, on a test database. A backup that has never been tested is not a reliable backup.

If your application runs in Docker, the databases are in containers: you run the commands with docker exec in the database container. The application's documentation usually tells you how to make the backup.

C. Check the server's health

9. Log in over SSH and run, one at a time:

   uptime            # how long it has been running and the load average
   df -h             # disk space, per partition
   free -h           # memory and swap
   systemctl --failed           # services stopped with an error
   sudo journalctl -p err -b    # errors since the last boot

10. Warning signs:
    • a disk over 85–90% full (df -h): at 100%, databases and applications stop;
    • memory almost full and heavy swap use (free -h);
    • services listed in systemctl --failed.
11. To see what is using resources, run top (or htop, after sudo apt install htop / sudo dnf install htop). To see what is taking up the disk: sudo du -xh / --max-depth=2 | sort -h | tail -20.

D. Find out on your own when a website goes down

12. Uptime monitoring (an add-on, priced by plan) checks each address every 5 minutes from our server and emails you (and alerts your phone, if you turn on alerts) when it stops responding and when it comes back. You add the addresses yourself in your NBT Account (see How to add a tool or an add-on). An address is accepted only if its domain points to your server's IP.
13. Uptime monitoring only sees web addresses. It doesn't see a stopped database, a disk that is filling up or a service without a web address; for those, the checks in step C remain.

If something doesn't work

• You deleted something by mistake. If it's a database and you have the backups from step B, restore it yourself from the file for the day you want. For the whole server, tell us which day you want from the backup or the snapshot.
• The disk is full. Delete old logs (sudo journalctl --vacuum-time=14d), unused Docker images (docker system prune, after you check what it deletes) and old local backups. If you need more space, contact us about the “Double disk space” add-on (+200 GB) or a larger plan.
• The nightly backup is missing. Check the cron log: sudo journalctl -u cron (Ubuntu, Debian) or sudo journalctl -u crond (AlmaLinux, Rocky). Run the command from the crontab by hand and read the error.
• You get a downtime alert, but the website works for you. The firewall may be blocking external checks, or the domain goes through a proxy. See VPS server: updates and the firewall.