Containers and NAS

For each Docker Compose project (or standalone container) chosen in the plan, the backup takes:

• The compose files and the .env files in the project folder, under the same names;
• Each container's configuration, as Docker describes it (ports, variables, mounts, network), enough to recreate a standalone container;
• The exact image, by digest, to restore the same version instead of that day's latest;
• A dump of each database, made inside the database container by a fixed recipe in the agent: PostgreSQL and derivatives (PostGIS, pgvector, TimescaleDB, Immich's Postgres), MySQL and MariaDB, MongoDB and Redis;
• The volumes and mounted folders of the services, as files (can be turned off per project);
• A manifest of the project: services, images, mounts and the result of each dump.

A database data folder that already has a dump is left out by default: the dump is enough to restore, and the folder copied while the database runs is not reliable. If you want both, tick also take the database data folder in the plan.

In the panel, each backup's details show, per project, the dumps made (engine, size, success or not), how many configuration files went and any chosen project that was not found on the server.

The recipe needs Arkame agent 0.6.0 or newer. The agent itself tells the panel it can do this; with an older agent, the recipe shows in the plan with the version that is missing.

On a regular Linux server, the panel’s Docker install command doesn’t change: it already mounts the server’s disk at /host (-v /:/host), and that’s how the agent reaches the server’s Docker socket. On a NAS, choose NAS or app system in the panel: the command then keeps the configuration on the data disk (see Installing on a NAS, below). The agent installed directly on the system (native) works too.

In the plan, at the What to copy step, Apps and commands tab, choose Containers. The panel shows what the agent found on the server: the projects, the services in each, the mounts and the databases that get an automatic dump. Choose all projects (new ones join on their own) or tick the ones you want, and drop the services you do not need.

The plan can be containers only, with no folders, or have extra folders. Dumps of databases in containers are automatic with the recipe, also with the agent in Docker; only the plan’s before and after commands don’t run in Docker.

The list updates itself: the agent reports what it found when it starts and whenever something changes on the server.

On TrueNAS SCALE, Unraid and ZimaOS the system is replaced on updates or runs from memory, and only the data disk survives. That’s why, on a NAS, the agent keeps the bucket key, the server identity and its state in a folder on the data disk, which we call PASTA here, and the dumps’ working folder goes inside it, at PASTA/conteineres, without filling the boot disk.

In the panel, under Servers → New server, choose Docker, then NAS or app system, and the platform: the panel suggests the folder and builds the command. This is its format, with PASTA in place of the folder and a sample code:

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; \}

Copy the command from the panel, which already carries your install code (valid for 24 hours). It has two parts: the first asks for the bucket’s access key and secret key, tests them against the bucket and waits for approval; only if it finishes well does the second start the agent.

The container created from the terminal doesn’t show up in the TrueNAS Apps list or in Unraid’s Apps, and it keeps running: it restarts with Docker, also after the NAS restarts.

When choosing the plan’s folders, leave PASTA out: it holds the bucket key.

What has been checked: Docker and Compose on Linux and CasaOS, end to end; ZimaOS, through the official file system of version 1.8.0. TrueNAS, Unraid, Synology and QNAP are being validated: the paths and steps below come from the official documentation or from forums.

Verified. This is the reference case: docker compose projects with the project folder on the server itself, and standalone containers created with docker run.

The agent looks for the socket at /var/run/docker.sock and /run/docker.sock (or in DOCKER_HOST, if set).

1. Before: Docker installed on the server (the panel shows the command for Docker’s official script, if it’s missing).
2. Open the server’s terminal (or SSH) with a user that uses sudo. In the panel, choose Linux server: the configuration stays in /etc/arkame.
3. Paste the command. The one here is a sample with the folder /etc/arkame and the code atk_...: copy the one from the panel, which already carries your code.

   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. In the panel, check the machine and the key fingerprint and approve the server. The agent then runs in the background.
5. Create the plan: in the What to copy step, Apps and commands tab, choose Containers and check the projects (or all of them).
6. If the plan also has folders, leave /etc/arkame out: it holds the bucket key.
7. Check: sudo docker logs --tail 50 arkame-agent shows the agent running, and in the plan the recipe tree shows the server’s projects.

Verified. On a real CasaOS on Debian 12, with the app installed from its store (CasaOS’s own API): apps are compose projects in /var/lib/casaos/apps/app-name, with the compose labels the agent reads, and the data lives in /DATA/AppData.

ZimaOS: verified against the official file system of version 1.8.0 (paths and labels), but the agent has not yet run on a ZimaOS. On ZimaOS the agent runs in a container (recommended): the system is read-only and updates replace everything outside /DATA; a persistent install of the native program is still being studied.

1. Before: CasaOS installed (Debian or Ubuntu) or ZimaOS. In the panel, choose the CasaOS or ZimaOS platform: the suggested folder is /DATA/AppData/arkame, where app data lives and, on ZimaOS, the only part updates don’t replace.
2. Open a terminal over SSH with your user. The command goes with sudo.
3. Paste the command. The one here is a sample with the folder /DATA/AppData/arkame and the code atk_...: copy the one from the panel, which already carries your code.

   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. In the panel, check the machine and the key fingerprint and approve the server. The agent then runs in the background.
5. Create the plan: in the What to copy step, Apps and commands tab, choose Containers and check the projects (or all of them).
6. If the plan also has folders, leave /DATA/AppData/arkame out: it holds the bucket key.
7. Check: sudo docker logs --tail 50 arkame-agent shows the agent running, and in the plan the recipe tree shows the server’s projects.

Being validated. On TrueNAS SCALE 24.10 or newer, each app is a compose project named ix- followed by the app name, with the generated compose file in /mnt/.ix-apps/app_configs and the data in /mnt/.ix-apps/app_mounts or in the datasets you chose.

The agent runs in a container created from the terminal, with its configuration on a pool dataset: TrueNAS updates replace the system root.

The Containers recipe requires 24.10 or newer, when apps started running on Docker. On 24.04 (Dragonfish) and earlier, apps run on Kubernetes (k3s) and there is no Docker on the system: the agent can’t see the apps. There, update to 24.10 or 25.04, which migrate the apps on their own; first, back up the configuration (System → General → Manage Configuration → Download File) and snapshot the datasets. Backing up only the datasets’ files on 24.04, with the agent and no recipe, is still being validated: the Linux installer doesn’t work there, because apt is disabled and the system is replaced on updates.

1. Before: TrueNAS SCALE 24.10 (Electric Eel) or newer, with Apps configured on a pool (Apps → Configuration → Choose Pool). Create the arkame dataset on that pool (Datasets → Add Dataset): with the pool tank, the folder is /mnt/tank/arkame. In the panel, replace tank with your pool’s name.
2. Open the terminal at System → Shell, or over SSH with the administrator user. The command goes with sudo.
3. Paste the command. The one here is a sample with the folder /mnt/tank/arkame and the code atk_...: copy the one from the panel, which already carries your code.

   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. In the panel, check the machine and the key fingerprint and approve the server. The agent then runs in the background.
5. Create the plan: in the What to copy step, Apps and commands tab, choose Containers and check the projects (or all of them).
6. If the plan also has folders, leave /mnt/tank/arkame out: it holds the bucket key.
7. Check: sudo docker logs --tail 50 arkame-agent shows the agent running, and in the plan the recipe tree shows the server’s projects. On TrueNAS, each app shows up in the plan as a project named ix- followed by the app’s name.

Being validated. Unraid does not use compose: each container comes from an XML template in /boot/config/plugins/dockerMan/templates-user, which the agent takes along with the container's configuration. Data usually lives in /mnt/user/appdata.

The system runs from memory, so the agent goes in a container, with its configuration in /mnt/user/appdata, on the array. The socket path is still to be checked on the device.

1. Before: the array started and Docker enabled (Settings → Docker). On Unraid, Docker only starts with the array started: with the array stopped, the agent is stopped too.
2. Open the terminal with the terminal icon at the top of the interface. It is already root: the command goes without sudo. Use the one-line command: Unraid doesn’t ship docker compose.
3. Paste the command. The one here is a sample with the folder /mnt/user/appdata/arkame and the code atk_...: copy the one from the panel, which already carries your code.

   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. In the panel, check the machine and the key fingerprint and approve the server. The agent then runs in the background.
5. Create the plan: in the What to copy step, Apps and commands tab, choose Containers and check the projects (or all of them).
6. If the plan also has folders, leave /mnt/user/appdata/arkame out: it holds the bucket key.
7. Check: docker logs --tail 50 arkame-agent shows the agent running, and in the plan the recipe tree shows the server’s projects.

Being validated. On DSM 7.2, Container Manager keeps projects in folders such as /volume1/docker/project-name, and Docker in /volume1/@docker. Both paths still need checking on a real device, since there is no official DSM virtual machine.

The agent runs in a container, created from the terminal, with Container Manager installed.

1. Before: DSM 7.2 with Container Manager installed, which creates the docker shared folder. Create the arkame folder in it (File Station) and turn on SSH in Control Panel → Terminal & SNMP. If your volume isn’t volume1, change it in the panel.
2. Open a terminal over SSH with the administrator user. The command goes with sudo.
3. Paste the command. The one here is a sample with the folder /volume1/docker/arkame and the code atk_...: copy the one from the panel, which already carries your code.

   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. In the panel, check the machine and the key fingerprint and approve the server. The agent then runs in the background.
5. Create the plan: in the What to copy step, Apps and commands tab, choose Containers and check the projects (or all of them).
6. If the plan also has folders, leave /volume1/docker/arkame out: it holds the bucket key.
7. Check: sudo docker logs --tail 50 arkame-agent shows the agent running, and in the plan the recipe tree shows the server’s projects.

Being validated. In Container Station, apps live in /share/volume-name/Container/container-station-data/application, a path we still have to confirm on a device.

The agent never uses system-docker.sock: it belongs to QNAP's own system, not to your containers.

1. Before: Container Station installed, which creates the Container shared folder. Create the arkame folder in it (File Station) and turn on SSH in Control Panel → Telnet/SSH.
2. Open a terminal over SSH with the admin user, which is already root: the command goes without sudo.
3. Paste the command. The one here is a sample with the folder /share/Container/arkame and the code atk_...: copy the one from the panel, which already carries your code.

   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. In the panel, check the machine and the key fingerprint and approve the server. The agent then runs in the background.
5. Create the plan: in the What to copy step, Apps and commands tab, choose Containers and check the projects (or all of them).
6. If the plan also has folders, leave /share/Container/arkame out: it holds the bucket key.
7. Check: docker logs --tail 50 arkame-agent shows the agent running, and in the plan the recipe tree shows the server’s projects.

Being validated. Stacks created by Portainer keep the compose file inside its container, at /data/compose/number. The agent recognizes this case and finds the file through Portainer's /data mount, usually the portainer_data volume. When it cannot, the backup details say which file was not found; the rest of the project goes as usual.

Being validated. Support exists but has not yet been checked on a real Podman. The agent talks to the Podman socket: /run/podman/podman.sock as root, which is off by default (turn it on with systemctl enable --now podman.socket); the native agent without root looks for $XDG_RUNTIME_DIR/podman/podman.sock. Quadlets come in a later version.

Devices without Docker, such as older Iomega units, cannot run the agent. The way is to install the agent on a computer or server on the network and back up the share mounted there. Having the agent mount the share itself is planned.

• The panel never sends a command to run in a container. It only sends the choice: which projects, which services, whether to copy volumes. Each dump command is fixed in the agent, picked by the database image.
• On the Docker API, the agent only makes the calls on a closed list: list, read the configuration and run the dump inside the database container. Creating, deleting, stopping or pulling images is refused before it leaves the agent.
• The panel never receives the environment variables or the passwords: only names and paths. The .env and the container configuration (the inspect, which carries the variables) go to your bucket as they are on the server, like any file in the backup: the agent does not encrypt files. Keep the bucket private and turn on your provider's encryption. The dump is made with the password the database container already has, without going through the panel.
• Access to the Docker socket is the same as being administrator (root) on the server. It is the same access the agent already has to read the files, which is why the calls are restricted in the agent itself.

• No pausing or stopping containers. The dump is consistent; volumes are copied while the app runs, and a file written mid-copy may come out half-done.
• Restoring a whole project is not available yet. From the panel you restore the files (compose, .env, volumes) and the dump; loading the dump into the database and starting the project with docker compose up is up to you.
• A failed dump makes the backup partial, with the reason in the details and in the email notice: image without the database client or without sh, wrong password. A stopped database gets no dump: with copy the volumes on, its data folder goes whole, since stopped it is consistent; without that option, the stopped database has no copy. What was uploaded stays restorable. Docker unavailable in a containers-only plan makes the backup fail with the reason.