Systems administration is an area where experience often comes right after you need it. Every senior sysadmin has “war” stories about the day they deleted the wrong database or crashed the company network.
Here are the most common mistakes that almost every beginner sysadmin makes, divided into critical categories.
1. The “Backup of Schrödinger”
The mistake isn’t forgetting to back up your data (although that happens), but rather blindly trusting that it works.
- The Mistake: Setting up backups and never testing the restore.
- The Reality: An untested backup doesn’t exist. You only discover that the .tar.gz file is corrupted or that the database dump was empty at the time of the disaster.
- The Solution: Implement the 3-2-1 strategy and schedule monthly restore tests.
2. The “Silver Bullet” of the chmod 777
When something doesn’t work because of permission, the beginner panics and “opens the doors.”
- The Error: Running
chmod -R 777 /var/www/htmlto resolve a “Permission Denied” error. - The Danger: You have just allowed any malicious user or script on the system to read, edit, and execute files.
- The Solution: Understand how owners (chown) and groups work. Grant only the minimum necessary permissions (Principle of Least Privilege).
3. The addiction to the root
It’s tempting to use the most powerful user for everything because “it works without complaining”.
- The Mistake: Logging in via SSH directly as root or using the root user for everyday tasks.
- The Danger: A wrong command (such as a misdirected
rm -rf) is catastrophic. Furthermore, there’s no audit trail of who made the change if everyone uses the same root account. - The Solution: Disable root login via SSH. Use
sudofor temporary privilege elevation.
4. “I’ll test it quickly in Production.”
Overconfidence is the mother of downtime.
- The Error: Editing configuration files (nginx.conf, my.cnf, php.ini) directly on the production server without testing beforehand, or deploying on a Friday afternoon.
- The Consequence: The service fails to restart due to a syntax error, and the website goes down during peak hours.
- The Solution: Have a staging environment. If this is not possible, always use syntax testing commands (e.g., nginx -t, apachectl configtest) before restarting the service.
5. Ignore Disk Space and Logs
Full disks are a silent cause of data corruption.
- The Error: Not monitoring the growth of log files or not configuring logrotate.
- The Danger: The disk fills up (100% usage). The database attempts to write, fails, and corrupts tables. The system crashes because it cannot write temporary files.
- The Solution: Configure monitoring (Nagios, Zabbix (configure on a separate server), or simple bash scripts) and ensure that logrotate is active and compressing old logs.
6. Disable Security because it “gets in the way”
Beginner sysadmins often view security tools as obstacles, not allies.
- The Mistake: Disabling the firewall (iptables -F / ufw disable) the first time a connection is blocked, and forgetting to re-enable it.
- The Solution: Learn how to configure the rules. There are tools like audit2allow that help create exceptions without disabling the entire SELinux protection.
7. Mental Documentation
“I’ll remember what this script does and why I changed this port.” (Narrator: He didn’t remember).
- The Mistake: Not documenting changes, custom configurations, or service passwords.
- The Consequence: Six months later, the server needs to be migrated and nobody knows how it was configured, or you go on vacation and your colleagues are left paralyzed.
- The Solution: Maintain an internal Wiki, use comments in configuration files, and ideally, start studying Infrastructure as Code (Ansible, Terraform) so that the code becomes the documentation.
Survival Summary
| Common Mistake | Correction Mantra |
| Untested backup | “If it doesn’t restore, it’s not a backup.” |
| Log in as Root | “Sudo is your friend.” |
| Edit in Production | “Friday is read-only day.” |
chmod 777 | “Minimum permission required.” |
| Ignore Logs | “The disk will eventually fill up.” |
Click here to view our Server Management plans.
FAQ
A backup only truly exists if it can be successfully restored. Many beginners schedule automated backups but never test the recovery process, only to discover during a crisis that the backup files are empty, corrupted, or completely unusable.
chmod 777 to fix permission errors? Running chmod -R 777 grants full read, write, and execute permissions to everyone on the system. This opens up massive security vulnerabilities, allowing any local user, malicious script, or attacker to modify or destroy critical system files.
Working continuously as the root user leaves zero room for error; a single misprotyped command like rm -rf can instantly wipe out the server. Additionally, using a shared root account destroys the audit trail, making it impossible to see which teammate made a specific change.
It means you should never deploy major updates, change critical configurations, or push modifications to a production server on a Friday afternoon. If something goes wrong, you risk ruining your weekend (and your team’s) dealing with emergency downtime.
When a server’s disk space hits 100% capacity due to unmanaged logs or temporary files, the database engine will try to write data and fail mid-transaction. This abrupt failure often corrupts the database tables and can crash the entire operating system.
In english:
Why Migrate Reseller Hosting to a VPS or Dedicated Server
Cheap VPS: 6 Critical Mistakes You Should Avoid When Hiring
How to Use htop, iotop, and Glances for Quick Diagnostics of Linux Servers
Veja também:
Complete Guide to DirectAdmin for Administrators: Installation, Security, and Performance
Como testar a velocidade da internet do servidor linux com speedtest-cli
Como verificar no linux a velocidade de I/O do disco
Como instalar Engintron(NGINX) cPanel/WHM