DevOpsQuest
0 XP
Módulo 3 · Git, GitHub e Bash

Automatizar tarefas de plantão: backup de logs e cron/timers

Intermediário 40 min+25 XPBashtarcronsystemd timers

Objetivos desta aula

  • Escrever backup com retenção
  • Agendar com cron e systemd timer
  • Validar restauração

Tarefas repetitivas de plantão são as primeiras candidatas à automação: compactar logs, limpar arquivos antigos, verificar espaço em disco, checar certificados. O script precisa ser idempotente (rodar duas vezes não causa dano) e observável (log e código de saída).

Backup sem teste de restauração é ilusão de segurança. Sempre valide a integridade do arquivo gerado e, periodicamente, restaure em outro caminho para conferir. Retenção precisa ser explícita: quantos dias, onde, quem paga o armazenamento.

Para agendar, cron continua onipresente, mas systemd timers oferecem log integrado ao journal, dependências e Persistent=true para executar após reinício. Em servidores modernos, timers são a escolha melhor; em ambientes legados, cron resolve.

1. cron vs systemd timers

cron é simples e universal. systemd timers oferecem logs no journal, dependências, Persistent=true (roda o que perdeu se a máquina estava desligada) e RandomizedDelaySec para não sobrecarregar tudo ao mesmo tempo.

2. Lendo a sintaxe do cron

minuto hora dia-do-mês mês dia-da-semana. 30 2 * * * = todo dia às 02:30. Lembre: cron roda com PATH mínimo e sem seu ambiente; use caminhos absolutos.

3. Idempotência e lock

Uma tarefa agendada precisa poder rodar duas vezes sem estrago e não pode rodar em paralelo consigo mesma. flock resolve o segundo ponto.

4. Backup que vale: o restore testado

Backup sem teste de restauração é esperança. Compacte, envie para fora do servidor (S3), aplique retenção e periodicamente restaure em outro lugar.

5. Observando tarefas agendadas

Alertar quando o job não roda é tão importante quanto quando falha: use um 'dead man's switch' (ping para um serviço de monitoração ao fim de cada execução).

6. Checagem final

Você deve criar um timer systemd com lock, logs no journal e envio do backup para fora da máquina.

Na prática

Backup de logs com retenção

bash

#!/usr/bin/env bash
set -euo pipefail

SRC="/var/log/cloudshop"
DEST="/var/backups/cloudshop"
KEEP_DAYS=14
STAMP="$(date +%F-%H%M)"
FILE="$DEST/logs-$STAMP.tar.gz"

mkdir -p "$DEST"
tar -czf "$FILE" -C "$SRC" .
tar -tzf "$FILE" >/dev/null   # valida integridade

find "$DEST" -name 'logs-*.tar.gz' -mtime +"$KEEP_DAYS" -delete
echo "backup ok: $FILE ($(du -h "$FILE" | cut -f1))"

Nota de segurança: Backup de log pode conter dado pessoal: restrinja permissões (700) e considere criptografia em repouso.

Agendamento com systemd timer

ini

# /etc/systemd/system/cloudshop-backup.service
[Unit]
Description=Backup dos logs do CloudShop

[Service]
Type=oneshot
ExecStart=/usr/local/bin/backup-logs.sh

# /etc/systemd/system/cloudshop-backup.timer
[Unit]
Description=Executa backup diario 03:15

[Timer]
OnCalendar=*-*-* 03:15:00
Persistent=true

[Install]
WantedBy=timers.target

# sudo systemctl enable --now cloudshop-backup.timer
# systemctl list-timers | grep cloudshop

Timer systemd para backup de logs

ini

# /etc/systemd/system/cloudshop-backup.service
[Service]
Type=oneshot
User=cloudshop
ExecStart=/usr/bin/flock -n /tmp/cloudshop-backup.lock /opt/cloudshop/bin/backup-logs.sh

# /etc/systemd/system/cloudshop-backup.timer
[Timer]
OnCalendar=*-*-* 02:30:00
Persistent=true            # executa se a maquina estava desligada no horario
RandomizedDelaySec=5m
[Install]
WantedBy=timers.target

Ativar e acompanhar

bash

sudo systemctl daemon-reload
sudo systemctl enable --now cloudshop-backup.timer
systemctl list-timers cloudshop-backup.timer   # proxima execucao
journalctl -u cloudshop-backup.service -n 20   # logs da ultima execucao

Por que isso importa

Automatizar o repetitivo libera tempo para engenharia e reduz erro humano em madrugada de plantão.

Erro comum

Backup que roda há meses sobre um caminho que mudou — e ninguém verificou.

Dica de produção

Faça o script emitir métrica ou notificação de sucesso; silêncio não é evidência de funcionamento.

Alerta de segurança

Cron rodando como root em script gravável por outro usuário é escalonamento de privilégio.

Pergunta de entrevista

Qual vantagem de systemd timer sobre cron em um servidor moderno?

Glossário

idempotente
Operação cujo resultado é o mesmo ao ser executada mais de uma vez.
Persistent
Opção de timer que executa a tarefa perdida após o host voltar.
systemd timer
Unidade systemd que agenda a execução de um service.
flock
Utilitário que impede execuções simultâneas usando um arquivo de lock.
dead man's switch
Alerta disparado quando um sinal periódico esperado deixa de chegar.

Conexão com o CloudShop

Agendar backup diário dos logs do CloudShop com retenção de 14 dias.

Quiz da aula

  1. 1. O que valida que o backup gerado é utilizável?

  2. 2. Script funciona no terminal mas falha no cron. Causa comum?

  3. 3. O que Persistent=true faz num timer?

Minhas anotações

Salvo automaticamente neste navegador.

AnteriorPróxima