Comandos de terminal Linux que todo admin deveria dominar

Você não precisa decorar mil comandos. Precisa dominar os que aparecem todo dia, e saber combiná-los. Este é o kit de quem cuida de infraestrutura — organizado pela pergunta que você está tentando responder, e não em ordem alfabética.

"O que está acontecendo agora?"

Os primeiros comandos de qualquer diagnóstico:

• htop — processos, CPU e memória em tempo real, com interface navegável. Pressione F6 para ordenar por consumo de memória, que costuma ser o que interessa;
• df -h — espaço em disco de forma legível. O primeiro suspeito quando "o sistema parou de gravar";
• du -sh * | sort -h — tamanho de cada pasta, ordenado. É assim que se encontra quem encheu o disco;
• free -h — memória. Não se assuste com pouca memória "livre": Linux usa a sobra como cache, e a coluna que importa é available;
• uptime — há quanto tempo está no ar e a carga média de 1, 5 e 15 minutos.

"Quem está usando essa porta?"

Pergunta clássica quando um serviço não sobe porque "o endereço já está em uso":

# quem está escutando na porta 443
sudo ss -tulpn | grep :443

# todas as portas abertas, com o processo dono
sudo ss -tulpn

O ss substituiu o antigo netstat e é bem mais rápido em máquinas com muitas conexões.

"O que os logs dizem?"

Metade da administração de servidores é saber ler log. Com systemd, tudo passa pelo journalctl:

# acompanhar ao vivo
journalctl -f

# últimos erros de um serviço, na última hora
journalctl -u nginx --since "1 hour ago" -p err

# tudo desde o último boot
journalctl -b

# o que aconteceu num intervalo específico
journalctl --since "2026-08-30 14:00" --until "2026-08-30 15:00"

O filtro -p err corta o ruído e mostra só o que é erro ou pior. Em um servidor movimentado, essa diferença é entre ler dez linhas e ler dez mil.

"Onde está essa informação?"

O grep é o melhor amigo de quem investiga:

# buscar em todos os logs, ignorando maiúsculas
grep -ri "erro" /var/log/

# mostrar 3 linhas antes e depois de cada ocorrência
grep -C 3 "timeout" /var/log/aplicacao.log

# contar quantas vezes aparece
grep -c "500" /var/log/nginx/access.log

Para achar arquivos, o find:

# arquivos maiores que 500 MB
find / -type f -size +500M 2>/dev/null

# modificados nas últimas 24 horas
find /etc -type f -mtime -1

Encadear comandos: onde está o ganho real

O poder do terminal não está em cada comando isolado, e sim em combiná-los com |. Cada um faz uma coisa e passa o resultado adiante:

# os 10 IPs que mais acessaram o servidor web
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -10

# processos ordenados por uso de memória
ps aux --sort=-%mem | head -10

# quantos erros 500 por hora hoje
grep " 500 " /var/log/nginx/access.log | awk '{print $4}' | cut -c2-15 | uniq -c

A primeira linha resolve, em um comando, a pergunta "quem está derrubando meu servidor?". Vale entendê-la: extrai o IP de cada linha, ordena, conta as repetições, ordena pelo número e mostra os dez maiores.

Gerenciar serviços e arquivos

# serviços
systemctl status nginx
systemctl restart nginx
systemctl list-units --failed      # o que falhou no sistema

# permissões e dono
chmod 640 config.yml
chown www-data:www-data /var/www/site

# compactar para backup
tar -czf backup-$(date +%F).tar.gz /etc/nginx/

# copiar preservando permissões, com progresso
rsync -avh --progress origem/ destino/

O systemctl list-units --failed merece destaque: é a primeira coisa a rodar em um servidor que "está estranho". Ele mostra, em uma tela, tudo que deveria estar rodando e não está.

Espaço em disco: o roteiro completo

Disco cheio é o incidente mais comum em servidores, e tem um roteiro de investigação que quase sempre funciona:

df -h                                    # qual partição encheu
du -sh /var/* 2>/dev/null | sort -h      # quem ocupa em /var
journalctl --disk-usage                  # tamanho dos logs do systemd
journalctl --vacuum-time=7d              # manter só 7 dias
sudo apt clean                           # limpar cache de pacotes

Dois hábitos que economizam horas

O primeiro é usar tmux ou screen em qualquer tarefa longa. Sem eles, uma queda de conexão SSH mata o processo no meio — atualização, cópia de banco, restauração. Com eles, você reconecta e continua de onde parou.

tmux new -s manutencao      # criar sessão
# Ctrl+B depois D            desconectar sem matar
tmux attach -t manutencao   # voltar

O segundo é testar antes de destruir. Comandos que apagam ou movem em massa merecem uma passada em modo seco:

rsync -avhn origem/ destino/     # -n simula, não copia nada
find /tmp -mtime +30 -type f     # veja a lista primeiro
find /tmp -mtime +30 -type f -delete   # só então apague

Domine esse conjunto e você resolve a esmagadora maioria das situações sem precisar procurar no navegador. O resto se aprende quando aparece — e aí o importante é saber ler a documentação com man comando.