Every incident investigation, security audit and performance mystery on a dedicated server eventually ends up in the logs. Yet log management is usually an afterthought until /var fills up at 2 AM or an auditor asks for six months of SSH history you rotated away. An hour of deliberate configuration prevents both.

Know Where Your Logs Live

Modern Linux splits logging between journald (structured binary journal, queried with journalctl) and classic text files in /var/log written by rsyslog or applications directly. Web servers, databases and your own applications typically write their own files. The first step is an inventory: what writes where, how fast it grows, and what would you actually need after an incident.

Configure journald Deliberately

By default journald may be volatile (lost on reboot) or unbounded. In /etc/systemd/journald.conf set Storage=persistent and cap usage with SystemMaxUse=2G (size to your disk). Persistent journals mean a crash reboot no longer erases the evidence of what caused it — a surprisingly common investigative dead end.

logrotate: The Unsung Disk Saver

Text logs need rotation or they grow forever. Check that every log-producing application has a logrotate config with a sane policy: rotate daily or by size, compress old files, and keep a defined number. A busy nginx server can write gigabytes daily; without rotation it will fill any disk eventually. Test configs with logrotate -d before trusting them.

When to Centralize — and With What

One server: local logs plus good rotation is fine. From two or three servers upward, centralization pays for itself the first time you trace a request across machines. In 2026 the pragmatic choice for most teams is Grafana Loki with the Alloy or Promtail agent: it indexes labels rather than full text, so it runs happily on modest hardware next to Prometheus. The Elasticsearch/OpenSearch stack offers richer full-text search at several times the resource cost. Either way, ship logs off the server — an attacker who gains root can edit local logs, but not the copies already shipped.

Retention: A Policy, Not an Accident

  • Application debug logs — 7–14 days is usually plenty.
  • Access logs — 30–90 days for traffic analysis and abuse investigation.
  • Authentication and audit logs — 6–12 months; compliance regimes like PCI DSS require at least a year with three months immediately available.
  • Personal data in logs — mind GDPR: IP addresses count, so document why you keep them and for how long.

Frequently Asked Questions

How much disk should I budget for logs?

A dedicated partition or at least a quota. For a busy web server, 20–50 GB local plus central retention is a comfortable starting point.

Are binary journald logs a problem?

No — journalctl filtering by unit, time and priority is more powerful than grep on text files. Forward to a central store if you also want text or long retention.

What should never be logged?

Passwords, full payment card numbers, session tokens and API keys. Scrub them at the application level; logs are copied to too many places to treat as secret storage.

Need room for serious log retention? Our dedicated servers ship with generous NVMe and HDD options — or ask us to design a logging architecture.