Contêineres e NAS

Para cada projeto do Docker Compose (ou contêiner avulso) escolhido no plano, o backup leva:

• Os arquivos do compose e os .env da pasta do projeto, com o mesmo nome;
• A configuração de cada contêiner, como o Docker a descreve (portas, variáveis, montagens, rede), que permite recriar um contêiner avulso;
• A imagem exata, pelo digest, para restaurar a mesma versão e não a latest do dia;
• O dump de cada banco, gerado dentro do contêiner do banco por uma receita fixa do agente: PostgreSQL e derivados (PostGIS, pgvector, TimescaleDB, o Postgres do Immich), MySQL e MariaDB, MongoDB e Redis;
• Os volumes e as pastas montadas dos serviços, como arquivos (pode desligar por projeto);
• Um manifesto do projeto: serviços, imagens, montagens e o resultado de cada dump.

A pasta de dados do banco que já tem dump fica de fora por padrão: o dump basta para restaurar, e a pasta copiada com o banco rodando não é confiável. Quem quiser as duas marca levar também a pasta de dados do banco no plano.

No painel, o detalhe de cada backup mostra, por projeto, os dumps feitos (motor, tamanho, deu certo ou não), quantos arquivos de configuração foram e o projeto escolhido que não foi encontrado no servidor.

A receita pede o agente Arkame 0.6.0 ou mais novo. Ele mesmo diz ao painel que sabe fazer isto; com um agente mais antigo, a receita aparece no plano com o aviso da versão que falta.

Num servidor Linux comum, o comando de instalação em Docker do painel não muda: ele já monta o disco do servidor em /host (-v /:/host), e é por ali que o agente alcança o socket do Docker do servidor. Num NAS, escolha no painel NAS ou sistema de apps: o comando passa a guardar a configuração no disco de dados (veja Instalar num NAS, abaixo). O agente instalado direto no sistema (nativo) também serve.

No plano, na etapa O que copiar, aba Aplicativos e comandos, escolha Contêineres. O painel mostra o que o agente encontrou no servidor: os projetos, os serviços de cada um, as montagens e os bancos que terão dump automático. Escolha todos os projetos (os que aparecerem depois entram sozinhos) ou marque os que quer, e tire os serviços que não interessam.

O plano pode ser só de contêineres, sem pastas, ou ter pastas a mais. O dump dos bancos em contêiner é automático pela receita, também com o agente em Docker; só os comandos de antes e depois do plano não rodam no Docker.

A lista se atualiza sozinha: o agente manda o que encontrou ao iniciar e quando algo muda no servidor.

No TrueNAS SCALE, no Unraid e no ZimaOS o sistema é trocado nas atualizações ou roda da memória, e só o disco de dados sobrevive. Por isso, num NAS, o agente guarda a chave do bucket, a identidade do servidor e o estado numa pasta do disco de dados, que aqui chamamos de PASTA, e a pasta de trabalho dos dumps fica dentro dela, em PASTA/conteineres, sem encher o disco de boot.

No painel, em Servidores → Novo servidor, escolha Docker e depois NAS ou sistema de apps, e a plataforma: o painel sugere a pasta e monta o comando. O formato é este, com PASTA no lugar da pasta e um código de exemplo:

sudo docker run \  --pull always \  --rm \  -it \  --user 0 \  --security-opt label=disable \  --hostname "$(hostname)" \  -v PASTA:/etc/arkame \  -e ARKAME_STATE_DIR=/hostPASTA/estado \  ghcr.io/arkame-app/arkame-agent:latest install \  --token=atk_... \  --panel-url=https://save.arkame.app \  --install-service=false &&{  sudo docker stop -t 150 arkame-agent >/dev/null 2>&1; \  sudo docker rm arkame-agent >/dev/null 2>&1; \  sudo docker run \    -d \    --name arkame-agent \    --restart always \    --stop-timeout 150 \    --user 0 \    --security-opt label=disable \    --hostname "$(hostname)" \    -v /:/host \    -v PASTA:/etc/arkame \    -e ARKAME_STATE_DIR=/hostPASTA/estado \    ghcr.io/arkame-app/arkame-agent:latest; \}

Copie o comando do painel, que já vem com o seu código de instalação (válido por 24 horas). Ele tem duas partes: a primeira pergunta a chave de acesso e a senha do bucket, testa no bucket e espera a aprovação; só se ela terminar bem a segunda sobe o agente.

O contêiner criado pelo terminal não aparece na lista de Apps do TrueNAS nem em Apps do Unraid, e continua rodando: ele reinicia com o Docker, também depois de reiniciar o NAS.

Ao escolher as pastas do plano, deixe a PASTA de fora: ela guarda a chave do bucket.

O que foi conferido: Docker e Compose em Linux e o CasaOS, de ponta a ponta; o ZimaOS, pelo sistema de arquivos oficial da versão 1.8.0. TrueNAS, Unraid, Synology e QNAP estão em validação: os caminhos e os passos abaixo vêm da documentação oficial ou de fóruns.

Conferido. É o caso de referência: projetos do docker compose com a pasta do projeto no próprio servidor, e contêineres avulsos criados com docker run.

O agente procura o socket em /var/run/docker.sock e /run/docker.sock (ou no DOCKER_HOST, se houver).

1. Antes: o Docker instalado no servidor (o painel mostra o comando do script oficial da Docker, se faltar).
2. Abra o terminal do servidor (ou SSH) com um usuário que use sudo. No painel, escolha Servidor Linux: a configuração fica em /etc/arkame.
3. Cole o comando. O daqui é um exemplo com a pasta /etc/arkame e o código atk_...: copie o do painel, que já vem com o seu código.

   sudo docker run \  --pull always \  --rm \  -it \  --user 0 \  --security-opt label=disable \  --hostname "$(hostname)" \  -v /etc/arkame:/etc/arkame \  ghcr.io/arkame-app/arkame-agent:latest install \  --token=atk_... \  --panel-url=https://save.arkame.app \  --install-service=false &&{  sudo docker stop -t 150 arkame-agent >/dev/null 2>&1; \  sudo docker rm arkame-agent >/dev/null 2>&1; \  sudo docker run \    -d \    --name arkame-agent \    --restart always \    --stop-timeout 150 \    --user 0 \    --security-opt label=disable \    --hostname "$(hostname)" \    -v /:/host \    -v /etc/arkame:/etc/arkame \    ghcr.io/arkame-app/arkame-agent:latest; \}

4. No painel, confira a máquina e a impressão da chave e aprove o servidor. O agente passa a rodar em segundo plano.
5. Crie o plano: na etapa O que copiar, aba Aplicativos e comandos, escolha Contêineres e marque os projetos (ou todos).
6. Se o plano também tiver pastas, deixe /etc/arkame de fora: ela guarda a chave do bucket.
7. Confira: sudo docker logs --tail 50 arkame-agent mostra o agente rodando, e no plano a árvore da receita mostra os projetos do servidor.

Conferido. Num CasaOS de verdade, sobre Debian 12, com o aplicativo instalado pela loja (a API do próprio CasaOS): os aplicativos são projetos compose em /var/lib/casaos/apps/nome-do-app, com os rótulos do compose que o agente lê, e os dados ficam em /DATA/AppData.

ZimaOS: conferido pelo sistema de arquivos oficial da versão 1.8.0 (caminhos e rótulos), mas o agente ainda não rodou num ZimaOS. No ZimaOS o agente roda em contêiner (recomendado): o sistema é só de leitura e as atualizações trocam tudo fora de /DATA; a instalação persistente do programa nativo ainda está em estudo.

1. Antes: o CasaOS instalado (Debian ou Ubuntu) ou o ZimaOS. No painel, escolha a plataforma CasaOS ou ZimaOS: a pasta sugerida é /DATA/AppData/arkame, onde ficam os dados dos apps e, no ZimaOS, a única parte que as atualizações não trocam.
2. Abra um terminal por SSH com o seu usuário. O comando vai com sudo.
3. Cole o comando. O daqui é um exemplo com a pasta /DATA/AppData/arkame e o código atk_...: copie o do painel, que já vem com o seu código.

   sudo docker run \  --pull always \  --rm \  -it \  --user 0 \  --security-opt label=disable \  --hostname "$(hostname)" \  -v /DATA/AppData/arkame:/etc/arkame \  -e ARKAME_STATE_DIR=/host/DATA/AppData/arkame/estado \  ghcr.io/arkame-app/arkame-agent:latest install \  --token=atk_... \  --panel-url=https://save.arkame.app \  --install-service=false &&{  sudo docker stop -t 150 arkame-agent >/dev/null 2>&1; \  sudo docker rm arkame-agent >/dev/null 2>&1; \  sudo docker run \    -d \    --name arkame-agent \    --restart always \    --stop-timeout 150 \    --user 0 \    --security-opt label=disable \    --hostname "$(hostname)" \    -v /:/host \    -v /DATA/AppData/arkame:/etc/arkame \    -e ARKAME_STATE_DIR=/host/DATA/AppData/arkame/estado \    ghcr.io/arkame-app/arkame-agent:latest; \}

4. No painel, confira a máquina e a impressão da chave e aprove o servidor. O agente passa a rodar em segundo plano.
5. Crie o plano: na etapa O que copiar, aba Aplicativos e comandos, escolha Contêineres e marque os projetos (ou todos).
6. Se o plano também tiver pastas, deixe /DATA/AppData/arkame de fora: ela guarda a chave do bucket.
7. Confira: sudo docker logs --tail 50 arkame-agent mostra o agente rodando, e no plano a árvore da receita mostra os projetos do servidor.

Em validação. No TrueNAS SCALE 24.10 ou mais novo, cada aplicativo vira um projeto compose de nome ix- seguido do nome do aplicativo, com o compose gerado em /mnt/.ix-apps/app_configs e os dados em /mnt/.ix-apps/app_mounts ou nos datasets que você escolheu.

O agente roda num contêiner criado pelo terminal, com a configuração num dataset do pool: as atualizações do TrueNAS trocam a raiz do sistema.

A receita Contêineres exige o 24.10 ou mais novo, quando os apps passaram a rodar em Docker. No 24.04 (Dragonfish) e anteriores os apps rodam em Kubernetes (k3s) e não há Docker no sistema: o agente não enxerga os apps. Nesses, atualize para o 24.10 ou o 25.04, que migram os apps sozinhos; antes, faça um backup da configuração (System → General → Manage Configuration → Download File) e um snapshot dos datasets. Só o backup de arquivos dos datasets no 24.04, com o agente sem a receita, ainda está em validação: o instalador do Linux não serve ali, porque o apt vem desligado e o sistema é trocado nas atualizações.

1. Antes: TrueNAS SCALE 24.10 (Electric Eel) ou mais novo, com Apps configurado num pool (Apps → Configuration → Choose Pool). Crie o dataset arkame nesse pool (Datasets → Add Dataset): com o pool tank, a pasta é /mnt/tank/arkame. No painel, troque tank pelo nome do seu pool.
2. Abra o terminal em System → Shell, ou por SSH com o usuário administrador. O comando vai com sudo.
3. Cole o comando. O daqui é um exemplo com a pasta /mnt/tank/arkame e o código atk_...: copie o do painel, que já vem com o seu código.

   sudo docker run \  --pull always \  --rm \  -it \  --user 0 \  --security-opt label=disable \  --hostname "$(hostname)" \  -v /mnt/tank/arkame:/etc/arkame \  -e ARKAME_STATE_DIR=/host/mnt/tank/arkame/estado \  ghcr.io/arkame-app/arkame-agent:latest install \  --token=atk_... \  --panel-url=https://save.arkame.app \  --install-service=false &&{  sudo docker stop -t 150 arkame-agent >/dev/null 2>&1; \  sudo docker rm arkame-agent >/dev/null 2>&1; \  sudo docker run \    -d \    --name arkame-agent \    --restart always \    --stop-timeout 150 \    --user 0 \    --security-opt label=disable \    --hostname "$(hostname)" \    -v /:/host \    -v /mnt/tank/arkame:/etc/arkame \    -e ARKAME_STATE_DIR=/host/mnt/tank/arkame/estado \    ghcr.io/arkame-app/arkame-agent:latest; \}

4. No painel, confira a máquina e a impressão da chave e aprove o servidor. O agente passa a rodar em segundo plano.
5. Crie o plano: na etapa O que copiar, aba Aplicativos e comandos, escolha Contêineres e marque os projetos (ou todos).
6. Se o plano também tiver pastas, deixe /mnt/tank/arkame de fora: ela guarda a chave do bucket.
7. Confira: sudo docker logs --tail 50 arkame-agent mostra o agente rodando, e no plano a árvore da receita mostra os projetos do servidor. No TrueNAS, cada app aparece no plano como um projeto de nome ix- seguido do nome do app.

Em validação. O Unraid não usa compose: cada contêiner nasce de um modelo XML em /boot/config/plugins/dockerMan/templates-user, que o agente leva junto com a configuração do contêiner. Os dados costumam ficar em /mnt/user/appdata.

O sistema roda da memória, então o agente vai em contêiner, com a configuração em /mnt/user/appdata, no array. O caminho do socket ainda será conferido no aparelho.

1. Antes: o array iniciado e o Docker ligado (Settings → Docker). No Unraid o Docker só sobe com o array iniciado: com o array parado, o agente também fica parado.
2. Abra o terminal pelo ícone de terminal no topo da interface. Ele já é o root: o comando vai sem sudo. Use o comando de uma linha: o Unraid não traz o docker compose.
3. Cole o comando. O daqui é um exemplo com a pasta /mnt/user/appdata/arkame e o código atk_...: copie o do painel, que já vem com o seu código.

   docker run \  --pull always \  --rm \  -it \  --user 0 \  --security-opt label=disable \  --hostname "$(hostname)" \  -v /mnt/user/appdata/arkame:/etc/arkame \  -e ARKAME_STATE_DIR=/host/mnt/user/appdata/arkame/estado \  ghcr.io/arkame-app/arkame-agent:latest install \  --token=atk_... \  --panel-url=https://save.arkame.app \  --install-service=false &&{  docker stop -t 150 arkame-agent >/dev/null 2>&1; \  docker rm arkame-agent >/dev/null 2>&1; \  docker run \    -d \    --name arkame-agent \    --restart always \    --stop-timeout 150 \    --user 0 \    --security-opt label=disable \    --hostname "$(hostname)" \    -v /:/host \    -v /mnt/user/appdata/arkame:/etc/arkame \    -e ARKAME_STATE_DIR=/host/mnt/user/appdata/arkame/estado \    ghcr.io/arkame-app/arkame-agent:latest; \}

4. No painel, confira a máquina e a impressão da chave e aprove o servidor. O agente passa a rodar em segundo plano.
5. Crie o plano: na etapa O que copiar, aba Aplicativos e comandos, escolha Contêineres e marque os projetos (ou todos).
6. Se o plano também tiver pastas, deixe /mnt/user/appdata/arkame de fora: ela guarda a chave do bucket.
7. Confira: docker logs --tail 50 arkame-agent mostra o agente rodando, e no plano a árvore da receita mostra os projetos do servidor.

Em validação. No DSM 7.2, o Container Manager guarda os projetos em pastas como /volume1/docker/nome-do-projeto, e o Docker em /volume1/@docker. Os dois caminhos ainda dependem de conferência num aparelho real, porque não há máquina virtual oficial do DSM.

O agente roda em contêiner, criado pelo terminal, com o Container Manager instalado.

1. Antes: DSM 7.2 com o Container Manager instalado, que cria a pasta compartilhada docker. Crie nela a pasta arkame (File Station) e ligue o SSH em Painel de Controle → Terminal e SNMP. Se o seu volume não for o volume1, troque no painel.
2. Abra um terminal por SSH com o usuário administrador. O comando vai com sudo.
3. Cole o comando. O daqui é um exemplo com a pasta /volume1/docker/arkame e o código atk_...: copie o do painel, que já vem com o seu código.

   sudo docker run \  --pull always \  --rm \  -it \  --user 0 \  --security-opt label=disable \  --hostname "$(hostname)" \  -v /volume1/docker/arkame:/etc/arkame \  -e ARKAME_STATE_DIR=/host/volume1/docker/arkame/estado \  ghcr.io/arkame-app/arkame-agent:latest install \  --token=atk_... \  --panel-url=https://save.arkame.app \  --install-service=false &&{  sudo docker stop -t 150 arkame-agent >/dev/null 2>&1; \  sudo docker rm arkame-agent >/dev/null 2>&1; \  sudo docker run \    -d \    --name arkame-agent \    --restart always \    --stop-timeout 150 \    --user 0 \    --security-opt label=disable \    --hostname "$(hostname)" \    -v /:/host \    -v /volume1/docker/arkame:/etc/arkame \    -e ARKAME_STATE_DIR=/host/volume1/docker/arkame/estado \    ghcr.io/arkame-app/arkame-agent:latest; \}

4. No painel, confira a máquina e a impressão da chave e aprove o servidor. O agente passa a rodar em segundo plano.
5. Crie o plano: na etapa O que copiar, aba Aplicativos e comandos, escolha Contêineres e marque os projetos (ou todos).
6. Se o plano também tiver pastas, deixe /volume1/docker/arkame de fora: ela guarda a chave do bucket.
7. Confira: sudo docker logs --tail 50 arkame-agent mostra o agente rodando, e no plano a árvore da receita mostra os projetos do servidor.

Em validação. No Container Station, os aplicativos ficam em /share/nome-do-volume/Container/container-station-data/application, caminho que ainda vamos confirmar em aparelho.

O agente nunca usa o system-docker.sock: ele é do próprio sistema da QNAP, não dos seus contêineres.

1. Antes: o Container Station instalado, que cria a pasta compartilhada Container. Crie nela a pasta arkame (File Station) e ligue o SSH em Painel de Controle → Telnet/SSH.
2. Abra um terminal por SSH com o usuário admin, que já é o root: o comando vai sem sudo.
3. Cole o comando. O daqui é um exemplo com a pasta /share/Container/arkame e o código atk_...: copie o do painel, que já vem com o seu código.

   docker run \  --pull always \  --rm \  -it \  --user 0 \  --security-opt label=disable \  --hostname "$(hostname)" \  -v /share/Container/arkame:/etc/arkame \  -e ARKAME_STATE_DIR=/host/share/Container/arkame/estado \  ghcr.io/arkame-app/arkame-agent:latest install \  --token=atk_... \  --panel-url=https://save.arkame.app \  --install-service=false &&{  docker stop -t 150 arkame-agent >/dev/null 2>&1; \  docker rm arkame-agent >/dev/null 2>&1; \  docker run \    -d \    --name arkame-agent \    --restart always \    --stop-timeout 150 \    --user 0 \    --security-opt label=disable \    --hostname "$(hostname)" \    -v /:/host \    -v /share/Container/arkame:/etc/arkame \    -e ARKAME_STATE_DIR=/host/share/Container/arkame/estado \    ghcr.io/arkame-app/arkame-agent:latest; \}

4. No painel, confira a máquina e a impressão da chave e aprove o servidor. O agente passa a rodar em segundo plano.
5. Crie o plano: na etapa O que copiar, aba Aplicativos e comandos, escolha Contêineres e marque os projetos (ou todos).
6. Se o plano também tiver pastas, deixe /share/Container/arkame de fora: ela guarda a chave do bucket.
7. Confira: docker logs --tail 50 arkame-agent mostra o agente rodando, e no plano a árvore da receita mostra os projetos do servidor.

Em validação. As stacks criadas pelo Portainer guardam o compose dentro do contêiner dele, em /data/compose/número. O agente reconhece esse caso e acha o arquivo pela montagem de /data do Portainer, em geral o volume portainer_data. Quando não consegue, o detalhe do backup diz qual arquivo não foi encontrado; o resto do projeto vai normalmente.

Em validação. O suporte existe, mas ainda não foi conferido num Podman real. O agente fala com o socket do Podman: /run/podman/podman.sock como root, que vem desligado por padrão (ligue com systemctl enable --now podman.socket); o agente nativo sem root procura $XDG_RUNTIME_DIR/podman/podman.sock. Os quadlets ficam para uma próxima versão.

Aparelhos sem Docker, como os Iomega antigos, não rodam o agente. O caminho é instalar o agente num computador ou servidor da rede e fazer backup do compartilhamento montado nele. Montar o compartilhamento pelo próprio agente está nos planos.

• O painel nunca manda comando para rodar num contêiner. Ele manda só a escolha: quais projetos, quais serviços, copiar ou não os volumes. O comando de cada dump é fixo no agente, escolhido pela imagem do banco.
• O agente só faz, na API do Docker, as chamadas de uma lista fechada: listar, ler a configuração e rodar o dump dentro do contêiner do banco. Criar, apagar, parar ou baixar imagem é recusado antes de sair do agente.
• O painel nunca recebe as variáveis de ambiente nem as senhas: só nomes e caminhos. O .env e a configuração dos contêineres (o inspect, que traz as variáveis) vão ao seu bucket como estão no servidor, como qualquer arquivo do backup: o agente não cifra os arquivos. Mantenha o bucket privado e ligue a cifra do provedor. O dump é feito com a senha que o contêiner do banco já tem, sem passar pelo painel.
• Acesso ao socket do Docker equivale a ser administrador (root) do servidor. É o mesmo acesso que o agente já tem para ler os arquivos, e é por isso que as chamadas são limitadas no próprio agente.

• Sem pausa nem parada do contêiner. O dump é consistente; os volumes são copiados com o aplicativo rodando, e um arquivo gravado no meio da cópia pode sair pela metade.
• A restauração do projeto inteiro ainda não existe. Pelo painel você restaura os arquivos (compose, .env, volumes) e o dump; carregar o dump no banco e subir o projeto com docker compose up é com você.
• Dump que falha deixa o backup parcial, com o motivo no detalhe e no aviso por e-mail: imagem sem o cliente do banco ou sem sh, senha errada. Banco parado não tem dump: com copiar os volumes ligado, a pasta de dados dele vai inteira, porque parada ela é consistente; sem essa opção, o banco parado fica sem cópia. O que subiu continua restaurável. Docker indisponível num plano só de contêineres faz o backup falhar com o motivo.