The most common mistakes on a Linux VPS fall into three categories: neglected security, ignored resource management, and backups that are never tested. The good news is that all of them are predictable and fixable before they cause a real incident.
This guide covers the ten mistakes that recur most often on new or poorly configured servers, along with a concrete fix for each one.
Security Mistakes That Open the Door to Attackers
1. Leaving SSH on port 22 with root password access
Port 22 is the first port brute-force bots scan, and root login with a password is the most dangerous combination. Within minutes of launching an unprotected VPS, logs already show thousands of failed attempts.
Fix:
- Move SSH to a non-standard port (e.g., 2222 or 49022).
- Disable direct root login: set
PermitRootLogin noin/etc/ssh/sshd_config. - Use public key authentication and disable passwords:
PasswordAuthentication no. - Install
fail2banto block IPs after N failed attempts.
2. Not updating the operating system or packages
A VPS frozen in the state the provider delivered it accumulates published vulnerabilities. Critical CVEs in the kernel or OpenSSL can be exploited within hours of disclosure.
Fix: run apt update && apt upgrade -y (Debian/Ubuntu) or dnf update -y (RHEL/AlmaLinux) at least once a week, or configure automatic security updates with unattended-upgrades.
3. No firewall or default-allow rules
Many VPS instances are delivered with the firewall disabled. If you haven't defined explicit rules, every port is open to the world.
Fix: enable ufw (Ubuntu) or firewalld (AlmaLinux/Rocky) as soon as you take the server. The default policy must be DROP on inbound, ACCEPT on outbound. Open only the ports you use: 80, 443, and your custom SSH port.
4. Weak database passwords or MySQL not bound to localhost
MySQL and MariaDB listen on 0.0.0.0:3306 by default in some configurations, exposing the database to the internet. Combined with a weak password or a passwordless root account, the result is catastrophic.
Fix: in /etc/mysql/my.cnf (or /etc/my.cnf.d/) make sure you have bind-address = 127.0.0.1. Run mysql_secure_installation after the initial install and assign long, unique passwords to each database user.
Resource Management Mistakes
5. Not monitoring RAM, CPU, and disk usage
The most common symptom of an unmonitored VPS is that the site "goes down suddenly." In reality it has been degrading for hours: RAM is at its limit, swap is exhausted, and the server starts killing processes.
Fix: install a monitoring tool on day one. Free, lightweight options:
- Netdata: real-time web dashboard, low overhead, email or Telegram alerts.
- Prometheus + Grafana: more powerful, ideal for managing multiple servers.
- At minimum, a cron job that alerts you when disk usage exceeds 80 %:
df -h | awk '$5+0 > 80'.
6. Running all processes under a single system user
When PHP-FPM, Nginx, MariaDB, and all websites run under the same system user, a compromised plugin or script on one site can read files from all the others.
Fix: create one system user per website and configure a separate PHP-FPM pool for each. The RAM cost is minimal; the isolation you gain is enormous.
7. Ignoring a full disk until the server crashes
Apache, Nginx, and MySQL logs grow indefinitely without log rotation. A 100 % full disk halts database writes, prevents MariaDB from starting, and corrupts session files.
Fix: verify that logrotate is active and configured to rotate and compress logs for your services. Set a retention policy: 7 days for access logs, 30 days for error logs.
In the VPS servers section you'll find additional guides on disk optimization and Linux server performance.
Backup and Recovery Mistakes
8. Confusing the provider's snapshot with a real backup
Cloud snapshots save disk state at a point in time, but many providers store them on the same infrastructure as the server. If the datacenter suffers a storage failure, you lose both the server and the snapshot.
Fix: snapshots are convenient for quick rollbacks, not disaster recovery. Complement with external backups: export databases with mysqldump and sync files with rsync to another provider or an object storage bucket (Backblaze B2, Wasabi).
9. Never testing backups
The most silent mistake of all: the backup runs, the cron reports success, but the .sql.gz file is empty or corrupt. You find out the day you need to restore.
Fix: schedule a monthly test restore. Spin up a test VPS (or use Docker), restore the most recent backup, and verify the application works. If the backup fails, the alert should reach you before the incident does.
10. Deploying changes to production without a staging environment
Updating a plugin, changing a PHP configuration, or modifying an Nginx config file directly in production is the fastest way to take down a site. Without a test environment, every change is a gamble.
Fix: on the same VPS you can create staging subdomains (staging.yourdomain.com) with an independent virtual host. Apply changes in staging, verify everything works, and only then deploy to production. The extra cost is only the disk space for a copy of the site.
If you want to avoid these mistakes from the start with a correctly configured VPS and specialized support, elenlace.com offers managed plans where your server arrives ready, secure, and monitored from day one.
Key Takeaways
- Change the SSH port, disable root password login, and enable public key authentication before doing anything else.
- Configure the firewall the same day you take the server; the default policy is to deny everything not explicitly allowed.
- Bind MySQL/MariaDB to
127.0.0.1and runmysql_secure_installationon initial setup. - Monitor RAM, CPU, and disk from day one — don't wait for the server to fail to find out it was at its limit.
- Snapshots don't replace external backups; and backups that aren't tested don't really exist.
- A staging environment on the same VPS costs only disk space and saves hours of production crises.
FAQ
What is the most serious mistake someone can make managing a Linux VPS?
Leaving SSH exposed on port 22 with root password access is the most dangerous combination. Brute-force bots constantly scan that port, and if the password is weak, the server can be compromised in minutes. Change the port, disable root login, and enable public key authentication on day one.
How often should I update system packages on my VPS?
Security updates should be applied at least once a week. On Debian/Ubuntu you can automate this with unattended-upgrades, which applies only security patches without touching major updates that could break dependencies.
What monitoring tool do you recommend for a budget VPS?
Netdata is the most balanced option: it installs in a single command, uses very little RAM (50–80 MB), provides a real-time web dashboard, and can send alerts via email or webhook. For portfolios of multiple servers, the Prometheus + Grafana combination scales better, though it requires more initial configuration.
Is the provider's snapshot enough as a backup strategy?
No. Snapshots are useful for quick rollbacks after a failed change, but they don't replace an offsite backup. If the datacenter suffers a storage failure or the provider has an incident, the snapshot can be lost along with the server. Always complement with backups stored at a separate external location.
Prefer it done for you? El Enlace handles hosting and professional web development.
Further reading
Other providers and guides worth comparing:
