Cron ou systemd timer? Repensando o agendamento de tarefas no Linux

O cron está aí desde os anos 70 e continua funcionando. Mas existe uma alternativa nativa em quase toda distribuição moderna que resolve problemas que o cron simplesmente ignora.

Fala pessoal, tudo bem?

No post "Backup simples com rsync", agendamos o script com o cron, às 2h da manhã. Funciona. Mas pense em algumas perguntas:

• E se o servidor estava desligado às 2h? O backup daquele dia simplesmente não acontece.
• O backup falhou? Você só descobre lendo o log, se lembrar de ler.
• Ele ainda estava rodando quando o próximo começou? O cron nem quer saber.

É aqui que entram os systemd timers.

Cron x systemd timer

	cron	systemd timer
Máquina desligada no horário	Execução perdida	Roda ao ligar (Persistent=true)
Logs	Por sua conta	Automático no journalctl
Execuções sobrepostas	Podem acontecer	Não sobrepõe o mesmo serviço
Próxima execução	Você calcula de cabeça	systemctl list-timers mostra
Limitar CPU/memória	Não	Sim, direto no service
Simplicidade	Uma linha 🏆	Dois arquivos

Como funciona: dois arquivos

backup.timer QUANDO rodar backup.service O QUE rodar backup.sh o seu script de sempre O script não muda. Muda só quem chama e quando.

Exemplo: migrando o backup do rsync

Primeiro o service, em /etc/systemd/system/backup.service:

[Unit]
Description=Backup diario com rsync

[Service]
Type=oneshot
User=usuario
ExecStart=/home/usuario/backup.sh
# não deixar o backup derrubar o resto do servidor
CPUQuota=50%
MemoryMax=512M
Nice=10

Depois o timer, em /etc/systemd/system/backup.timer:

[Unit]
Description=Agenda o backup diario

[Timer]
OnCalendar=*-*-* 02:00:00
# se estava desligado às 2h, roda assim que ligar
Persistent=true
# espalha em até 15 min (útil com muitos servidores)
RandomizedDelaySec=15min

[Install]
WantedBy=timers.target

Ativando e conferindo:

$ sudo systemctl daemon-reload
$ sudo systemctl enable --now backup.timer

# quando roda a próxima vez
$ systemctl list-timers backup.timer

# rodar agora, para testar
$ sudo systemctl start backup.service

# o que aconteceu na última execução
$ journalctl -u backup.service -n 50

💡 Não sabe escrever o OnCalendar? O próprio systemd valida e mostra as próximas execuções:
systemd-analyze calendar "Mon..Fri *-*-* 08:30:00" --iterations=3

⚠️ Lembrete do post do rsync: o service roda sem você logado, assim como o cron. A chave SSH do backup continua precisando funcionar sem passphrase e sem ssh-agent.

Então o cron morreu?

Não. Para uma tarefa simples, num servidor só, uma linha no crontab continua sendo ótima. O timer começa a valer a pena quando a tarefa é importante: quando falhar em silêncio custa caro, quando ela pode demorar, quando precisa de limite de recurso.

E de bônus: quem entende timers e services entende o systemd, que é quem de fato gerencia o seu servidor Linux.

Considerações Finais

A pergunta não é "cron ou systemd". É: se essa tarefa não rodar hoje, eu vou ficar sabendo? Se a resposta for não, vale trocar.

Abs e até a próxima!!!

:wq!