The starting point
Our lab is a set of VMs on Azure that we run ourselves. This study follows two of them on 19 October 2026. Each one runs a test app of ours that keeps writing to its data folders.
On 19 October 2026, as each VM’s step began2 lab VMs on Azure · 1 on a btrfs pool, 1 new
Connecting Amoeba
Lab VM B was new. One click in the Amoeba console onboarded it. Amoeba installed its agent on the VM by itself. The agent was running in under a minute and a half. From then on, Amoeba watched the VM’s data. Then it started the move on its own.
Lab VM A was onboarded before 19 October.
Copies a VM’s data onto one btrfs pool while its apps run, then switches each folder to the pool.
When the data goes down, moves it off one disk, then removes that disk. The pool stays mounted.
Per VM, shrinks start on their own or wait for your click.
What Amoeba did
The move onto a pool: two folders, while the app kept writing
19 OctOn Lab VM B, Amoeba built a btrfs pool beside the two old disks. It copied both folders onto the pool while our test app kept writing. Then it copied what had changed and switched both folders to the pool. Not one write failed at the switch, and writing never paused for more than 1.5 seconds. We then let Amoeba release the old disks. It took a safety snapshot of each, then deleted them.
A shrink on our click: 96 GiB down to 72 GiB
19 OctLab VM A is set to Manual, so its shrinks wait for us. First, Amoeba packed the pool’s data more tightly. That freed 5.00 GiB inside the pool. No disk was added or removed, so it cost nothing more. Later, Amoeba planned a shrink and waited for our click. Then it added an 8 GiB disk and moved 16.06 GiB off the 32 GiB disk in 2 minutes 55 seconds. It removed that disk and deleted it. 8 minutes 14 seconds from our click to done.
How the apps and data came through
The move onto a pool is the big step for an app: its folders switch from the old disks to the pool. Here is how long our test app’s writes took on Lab VM B, before and through that move. The app wrote to both folders every second. Each write was saved to disk before it counted.
Before the move, while Amoeba watched18 msslowest 198 ms
Copying the first folder26 msslowest 270 ms
Copying the second folder, during our 1.5 GiB burst28 msslowest 2,420 ms
The last copy and the switch onto the pool20 msslowest 68 ms
At the switch: 0 failed writes, no pause over 1.5 seconds and 0 lost mounts.
| Check | Lab VM A | Lab VM B, through the move |
|---|---|---|
| Test app | 0 errors | No write failed |
| Folders found mounted | 5,677 of 5,677 checks before the shrink, and 118 of 118 during it | Every check |
| Test files whose checksum matched | not checked | Every one, before and after the switch |
What this means: through the copy and the switch, 99 in 100 writes took 28 ms or less. The slowest write, 2,420 ms, came in the stage where we added our own 1.5 GiB burst. In every other stage shown, no write took longer than 270 ms. A service that keeps the data open, like a database, gets a short restart at the switch. Our test app was not restarted. Lab VM A’s test app keeps no timings, so its speed during the shrink was not measured.
How they stayed safe
After the move, Amoeba took a safety snapshot of each old disk before it deleted that disk.
The 32 GiB disk left Lab VM A’s pool only after its 16.06 GiB of data had moved to the other disks. The folders stayed mounted throughout.
Lab VM A is on Manual. Amoeba planned its shrink, then waited for our click before it added or removed a disk.
The result
Before19 Oct
The shrink19 Oct
After19 Oct
| Lab VM | Before | After | Difference | Each month |
|---|---|---|---|---|
| Lab VM A, Manual | 96 GiB | 72 GiB | 24 GiB less | $3.60 less |
Each month: Amoeba’s own figure, at the Azure list prices it reads.
24 of 96 GiB, holding the same 60.07 GiB of data
Zoorik’s own lab VMs on Azure, on 19 October 2026. The figures show Amoeba as it ran that day. Each VM ran Linux and a test app of ours, not a customer’s workload. In our lab, Amoeba read a shorter history of each VM’s data than it does for a customer. So its timing differed, and it sized each pool more tightly. A pool’s size is the total of its disks. Money is Amoeba’s own figure at Azure list prices. Results depend on each VM’s data.