Hi, I recently finished setting up my Asustor NAS, and I found the snapshotting setup in it a bit confusing, so I'm writing this as a quick reference that might be hopefully useful to others.

For context, my device is a AS1102TL, and it's running ADM 4.3.3, but I imagine it should apply to all recent Asustor devices.

First of all, the reason I picked Asustor instead of e.g. Synology... it's because it was not clear if the latter actually supported LUKS full disk encryption on an external usb hd. In Asustor you have to ssh into your NAS, but you can definitely do it.

The only gotcha: If you created the LUKS volume recently on another system, it's likely that it'll be using Argon2 for key stretching. A memory-intensive algorithm, for which the 1GB of memory provided by my AS1102TL is not enough. The solution is simply to add another key with a different algo, e.g. PBKDF2, or just create the volume on your Asustor. Either way, you're going to be able to read and write it both from the NAS and another Linux on your pc.

$ sudo $(which cryptsetup) luksOpen /dev/sdb1 encrypted # "encrypted" is just the name that I gave to the device, pick anything... remember the `-S` flag if you need to select a key in a different slot
$ sudo mount /dev/mapper/encrypted /mnt/USB1
... do what you want ...
$ sudo umount /mnt/USB1/
$ sudo $(which cryptsetup) luksClose encrypted

Unfortunately, this doesn't mean that once mounted, the disk will be integrated in the ADM ui (you're not going to be able to see it in the "External Devices" ui, nor be able to select it as a destination in the "Backup & Restore" ui).

Normally, mounted external drives are available on paths like /share/USB0, /share/USB1. Maybe it could be possible to mount (or symlink your mount point for) your disk there, to make it usable to ADM, but by default /share is an immutable loop mount of /volume0/.@system/sharebase.loop

$ lsattr -d /share/
-----i------- /share/

Trying to workaround that with chattr and maybe manually modifying sharebase.loop felt a bit more risky than needed, so I didn't attempt that (the ADM ui doesn't provide a btrfs send functionality, so it's not very interesting for our purposes anyhow).

Now, you have two different approaches to accomplish incremental backups of btrfs snapshots, one where you just create them yourself from the CLI, and one where you can try to reuse the snapshots created in ADM.

1. Create snapshot from the cli

sudo btrfs subvolume snapshot -r /volume1 /volume1/.@snapshots/v20250710-0951

pick a parent snapshot, and send the incremental changes:

sudo btrfs send -p /volume1/.@snapshots/v20250710-0936 /volume1/.@snapshots/v20250710-0951/ | sudo btrfs receive -v /mnt/USB1/

I'm using the same naming convention, and same location that is used for snapshots created by ADM (you wouldn't get conflicts anyhow, unless you're creating another one in the exact same minute).

I recommend the -v verbose flag for btrfs receive, otherwise you're not going to see progress while the operation is ongoing.

That's it! Of course, the first send will have to happen without specifying a parent with -p, to do a full clone.

1. Reuse snapshots created in ADM

There are two problems with this: the snapshots created by ADM are not read-only and they are mounted right under the toplevel.

To address these issues:

sudo mount /dev/md1 -o subvol=/ /mnt/rootvol
sudo btrfs property set /mnt/rootvol/v2025079-2324/ ro true

then pick a parent snapshot, and send the incremental changes:

sudo btrfs send -p /mnt/rootvol/v2025079-0824/ /mnt/rootvol/v2025079-2324 | sudo btrfs receive -v /mnt/USB1/

As above, use the -p and -v flags as needed. That's it!

If you're wondering why did we have to mount the / subvol, you can try without:

You can mount the snapshots directly in ADM's Snapshot Center, by toggling the Preview toggle for a snapshot. In that case, they are still going to be RW, though mounted as RO. You can deal with that by remounting: sudo mount -o remount,rw /volume1/.@snapshots/v2025079-2324/ && sudo btrfs property set /volume1/.@snapshots/v2025079-2324/ ro true,

You can then try to send the changes, but what you're going to get is:

$ sudo btrfs send -p /volume1/.@snapshots/v2025079-0824/ /volume1/.@snapshots/v2025079-2324
ERROR: not on mount point: /volume1/.@snapshots/v2025079-2324

The error is a bit confusing (you have mounted the volume! why is that not good enough?), but you can get a bit of clarity with btrfs subvolume list.

$ sudo btrfs subvolume list /volume1 -qua
ID 256 gen 159842 top level 5 parent_uuid -                                    uuid cbc37b20-901f-b043-8cf1-59b814814140 path <FS_TREE>/base
ID 258 gen 151914 top level 5 parent_uuid -                                    uuid 5039c206-1a89-dc45-a9fe-43f8959cb672 path <FS_TREE>/.iscsi
ID 259 gen 159840 top level 5 parent_uuid -                                    uuid 06d46207-9aa2-2944-ba38-e5736963ec12 path <FS_TREE>/.@plugins
ID 2758 gen 157876 top level 5 parent_uuid cbc37b20-901f-b043-8cf1-59b814814140 uuid 256c36c5-7033-a945-a2db-b6a334a8419f path <FS_TREE>/v2025079-0824
ID 2759 gen 157859 top level 5 parent_uuid cbc37b20-901f-b043-8cf1-59b814814140 uuid 88942ee6-8b52-3d4d-b972-5de2d6764728 path <FS_TREE>/v2025079-2324
ID 2762 gen 159833 top level 256 parent_uuid cbc37b20-901f-b043-8cf1-59b814814140 uuid 6d636914-35a0-3f42-9486-bf5d673b94c5 path base/.@snapshots/v20250710-0936
ID 2763 gen 159836 top level 256 parent_uuid cbc37b20-901f-b043-8cf1-59b814814140 uuid e99df217-4946-a740-bba9-99f64f1a0d69 path base/.@snapshots/v20250710-0951

Now, compare with the output when listing /mnt/rootvol:

$ sudo btrfs subvolume list /mnt/rootvol/ -qua
ID 256 gen 159867 top level 5 parent_uuid -                                    uuid cbc37b20-901f-b043-8cf1-59b814814140 path base
ID 258 gen 151914 top level 5 parent_uuid -                                    uuid 5039c206-1a89-dc45-a9fe-43f8959cb672 path .iscsi
ID 259 gen 159840 top level 5 parent_uuid -                                    uuid 06d46207-9aa2-2944-ba38-e5736963ec12 path .@plugins
ID 2758 gen 157876 top level 5 parent_uuid cbc37b20-901f-b043-8cf1-59b814814140 uuid 256c36c5-7033-a945-a2db-b6a334a8419f path v2025079-0824
ID 2759 gen 157859 top level 5 parent_uuid cbc37b20-901f-b043-8cf1-59b814814140 uuid 88942ee6-8b52-3d4d-b972-5de2d6764728 path v2025079-2324
ID 2762 gen 159833 top level 256 parent_uuid cbc37b20-901f-b043-8cf1-59b814814140 uuid 6d636914-35a0-3f42-9486-bf5d673b94c5 path <FS_TREE>/base/.@snapshots/v20250710-0936
ID 2763 gen 159836 top level 256 parent_uuid cbc37b20-901f-b043-8cf1-59b814814140 uuid e99df217-4946-a740-bba9-99f64f1a0d69 path <FS_TREE>/base/.@snapshots/v20250710-0951

as you can see, the snapshots created in ADM are directly under top level 5 and if you list them under /volume1 (which is just the mount point for the /base subvolume), they are not found directly underneath (despite them being mounted there), which is why you see them being under their own <FS_TREE>.

Conversely, the ones that you can create directly from the cli under volume1, appear as top level 256 and they are under /base if you list the subvolumes under /mnt/rootvol.

I hope this has been useful.