Tarefas agendadas: cron ou systemd timer
Uma cópia de segurança à noite, uma limpeza ao domingo, um relatório às segundas. Há duas formas de agendar isto num servidor Linux, e a escolha tem menos a ver com gosto do que parece.
1. Cron: cinco campos e está feito
crontab -e# minuto hora dia mês dia-da-semana
0 3 * * * /opt/scripts/backup.sh # todos os dias às 03:00
*/15 * * * * /opt/scripts/verificar.sh # de 15 em 15 minutos
0 4 * * 0 /opt/scripts/limpeza.sh # domingos às 04:00Simples, está em todo o lado, e tem três armadilhas conhecidas:
O ambiente é mínimo. O
PATHnão é o seu, e um script que funciona no terminal falha aqui com "command not found". Use caminhos absolutos.A saída perde-se. O que o script escrever vai para um email local que ninguém lê. Redirecione para um ficheiro.
Máquina desligada, tarefa perdida. O cron não recupera o que não correu.
0 3 * * * /opt/scripts/backup.sh >> /var/log/backup.log 2>&12. Systemd timers: mais escrita, mais controlo
# /etc/systemd/system/backup.service
[Service]
Type=oneshot
ExecStart=/opt/scripts/backup.sh# /etc/systemd/system/backup.timer
[Timer]
OnCalendar=daily
# Se a máquina estiver desligada à hora, corre no arranque seguinte
Persistent=true
[Install]
WantedBy=timers.targetsudo systemctl enable --now backup.timer
systemctl list-timers # o que está agendado, e para quando
journalctl -u backup.service # o que aconteceu, com datasSão dois ficheiros em vez de uma linha. Em troca: os registos ficam no journal com o resto do sistema, o Persistent recupera execuções perdidas, e há limites de recursos e dependências entre serviços.
3. Qual escolher
Cron para o que é simples e não faz mal falhar uma vez. Systemd timer quando interessa saber se correu — e uma cópia de segurança é exatamente isso.
4. A regra que evita o desastre
Uma tarefa agendada que falha em silêncio é pior do que não existir, porque dá a ilusão de estar tratada. Faça o script gritar quando falha:
set -euo pipefail # para no primeiro erro, em vez de continuar às cegas