O agendamento necessário para viver com um estado persistente do Docker
O autor queria cópias semanais dos dados da aplicação para um conjunto RAID 1 e uma segunda cópia desse conjunto para um disco USB continuamente ligado. O crontab do sistema e uma aplicação de agendamento da comunidade não mantinham as tarefas de forma fiável após um reinício, por isso transferiu o agendamento para uma stack Ofelia gerida pelo Portainer, armazenada nos dados persistentes do ZimaOS.
O design resultante separou três camadas: scripts de shell no armazenamento RAID, um contentor Ofelia que fornecia o agendamento e contentores rsync de curta duração que executavam cada cópia.
Armazenar scripts e registos no armazenamento persistente
O exemplo colocava os scripts num caminho como /media/RAID1/scripts. Esse diretório era montado com acesso de leitura e escrita no agendador como /scripts. Os registos eram escritos junto aos scripts, para poderem ser consultados através de Ficheiros ou de uma partilha de rede após a conclusão da tarefa.
Cada caminho do exemplo é específico da instalação. Copiar o nome do RAID do autor sem verificar o caminho de montagem real pode enviar uma cópia de segurança para o local errado ou fazer com que a tarefa falhe silenciosamente.
A Ofelia fornecia um agendamento persistente após reinícios
A stack do Portainer utilizava a imagem Ofelia, definia restart: always, montava o diretório dos scripts e armazenava as etiquetas de agendamento no contentor. O exemplo agendava os dados da aplicação para as 23:30 de todos os domingos e os dados gerais do NAS para as 23:45.
ofelia.job-local.appdata.schedule: "0 30 23 * * 0"
ofelia.job-local.appdata.command: "/bin/sh /scripts/backup_appdata.sh"
ofelia.job-local.nas_home.schedule: "0 45 23 * * 0"
ofelia.job-local.nas_home.command: "/bin/sh /scripts/backup_nas_home.sh"O autor relatou que o agendador e as respetivas tarefas voltavam a estar disponíveis cerca de um minuto após o reinício, sem ser necessária outra sessão SSH.
O script dos dados da aplicação parava o Plex antes da cópia
Para reduzir a possibilidade de copiar uma base de dados do Plex que estivesse a ser alterada, o script parava o Plex, executava o rsync a partir de uma montagem de origem dos dados da aplicação apenas para leitura e reiniciava o Plex depois. O contentor do agendador instalava um cliente Docker quando necessário e controlava contentores vizinhos através do socket do Docker.
A montagem de /var/run/docker.sock dá ao agendador um controlo abrangente sobre o anfitrião Docker. Executá-lo como root e com privilégios elevados aumenta ainda mais essa autoridade. O tópico apresenta isto como o design funcional do autor, não como um modelo de segurança baseado no princípio do menor privilégio.
rsync --delete cria um espelho exato, não um histórico versionado
O exemplo utilizava rsync -avH --delete. A opção --delete remove os ficheiros de destino que já não existem na origem. Isto produz um espelho exato, mas também pode replicar uma eliminação ou corrupção acidental.
Comece por testar sem a eliminação, confirme as montagens de origem e destino e consulte o registo antes de ativar um agendamento não supervisionado. Um espelho num disco USB sempre ligado também não equivale a uma cópia de segurança offline ou imutável.
A persistência após reinícios não resolveu a reconexão do USB
O autor pediu separadamente que um disco USB ligado deixasse de aparecer como um disco novo após o reinício. A Ofelia preserva a configuração da tarefa, mas uma montagem alterada ou indisponível pode continuar a interromper o destino da cópia de segurança. A identificação estável do armazenamento e a verificação das montagens antes de executar o rsync continuam a ser requisitos distintos.
FAQ
Porque é que este agendamento sobreviveu ao reinício?
As definições das tarefas estavam numa stack do Portainer configurada para reiniciar, e os scripts estavam armazenados num local persistente, em vez de ficarem num crontab efémero do sistema.
Isto cria versões históricas das cópias de segurança?
Não. O comando rsync documentado cria um espelho e utiliza --delete. A retenção de versões requer um design diferente.
Porque é que o Plex era parado antes de copiar os dados da aplicação?
O autor fazia isso para reduzir o risco de copiar a respetiva base de dados enquanto estava a ser modificada.
