The cause was not a full disk. It was a preference: the stack had no rule about what a movie is allowed to weigh, and Radarr ships with no limit for 2160p at all.

This is the whole story: the disk, the rebalance, and the two declarative layers that now hold the policy.

The failure: 99% on one branch, 71% on the pool

The pool is mergerfs over four branches:

mergerfs used category.create=epmfs: a new file goes to the branch that already holds its directory, and free space is only compared between branches that hold it. The library directories existed on media-sda only, so every import landed there. Both other local disks were empty.

When media-sda dropped under mergerfs’ 4G minfreespace, creates failed with ENOSPC even though the pool had 788G free. That is the trap: df /mnt/media shows the union and stays calm, while the one branch that accepts writes is full.

The symptom was indirect. LazyLibrarian imported a book, could not write to /books, and fell back to its config volume:

WARNING: eBook dir ['/books'] not writeable, using /config:
[Errno 28] No space left on device: '/books/ll_temp'

The book was in the database. The file was in the wrong place. The UI said the download worked.

Rebalancing without losing anything

The first fix is movement, not deletion. mergerfs merges reads, so a folder can move to another branch and keep serving from the same path.

The numbers from that day:

Result:

Total pool content did not change: 318G before and after.

Three rules keep this safe:

1. Never delete before the copy is verified. Compare the file list and the size of every file, then delete the source.
2. Use a tab separator when reading that list. Show names contain spaces, and read -r path size silently splits Season 4 into two fields.
3. Expect a new file in the destination. Sonarr imported an episode during one copy. That is fine, the check only verifies the source list.

A trap I walked into: I first tried to move a 69G movie onto media-sda. That was the wrong direction, it filled the disk I was trying to protect. I stopped it, removed the partial copy and sent it to remote82-sda instead.

The real cause: no preference at all

Moving data bought weeks. It did not explain how a single film reached 68G.

Radarr’s stock quality definitions have maxSize: null for every 2160p class. No limit means a Remux-2160p is an acceptable release. One of them was 21% of the entire library.

The resolution was not the problem. The bitrate was. Two constraints decide what is worth storing here:

• remote streaming is capped at 12 Mbps, so anything above about 5.4 GB per hour cannot be delivered off the LAN at all;
• a 2160p WEB-DL measures 125-310 MB/min, and a 2160p remux measures 450-750.

So 4K is fine as WEB-DL. The remux class has no consumer in this house.

Layer one: recyclarr owns quality profiles

Profiles decide which qualities may be downloaded. recyclarr reconciles them from a file in the GitOps repo, nightly.

Three profiles, all upgrade-enabled:

No profile allows Remux or Bluray-2160p. 4K stays possible, but only in its sane form and only when assigned to a specific movie.

AVI is not a target. It is a 1992 container, usually with Xvid video: no modern subtitles, no reliable seeking index, and Jellyfin cannot direct-play it, so every playback transcodes for nothing. The library is already 100% MKV and it should stay that way. 1080p HEVC in MKV is the default; H.264 only when a client forces it.

Three things went wrong on the way:

1. --dry-run does not exist in the pinned image. The nightly job failed on every schedule until the log said Unknown option 'dry-run' and it became --preview.
2. The config I wrote was version 8 shaped. recyclarr config create pulls templates from the templates repository’s master branch, which is already v8, while the image is 7.4.0. It answered Property 'trash_id' not found.
3. TRaSH presets are not a shortcut for size limits. Their quality_definition now sets Max = 1000 (Unlimited) for every quality. Applying it would have removed the useful 1080p cap and kept 2160p unlimited, which is the accident itself.

Layer two: OpenTofu owns the size caps

recyclarr cannot express numbers, so sizes do not belong to it. OpenTofu has providers for both apps, and quality_definition is a resource.

Caps in MB per minute:

Those numbers come from measurement, not from taste: a 60-minute 1080p episode is about 30 MB/min, the 34G 2160p WEB-DL replacement is about 309, and the 68G remux is about 620.

My first draft said 20/55 MB/min. That was wrong. 55 would have rejected every real 4K WEB-DL, so the cap would have looked strict while quietly breaking 4K. The mistake is in the runbook now, with a note not to repeat it.

The rest of that layer is small but earns its place: root folders imported (not created, that would duplicate them) and a Telegram notification per app, failure signals only. Health issues, restores, app updates and manual interaction. Grab and import events stay off, because a TV library would otherwise send a message per episode.

What the ownership split looks like

One object, one owner. This matters because two reconcilers touching the same object produce a loop: recyclarr would write a profile, Tofu would see drift and revert it, and both would be right.

Download clients and Prowlarr indexers are still imperative, in the setup script. Moving them needs a full config translation per object and duplicates are dangerous there, so they stay for a later slice.

What it bought

• the 68G remux class cannot return through any profile;
• 2160p has a size limit for the first time;
• all three branches sit between 38% and 46%, with 122G free on the busiest one;
• a chapter of configuration that lived only in a SQLite file is now reviewable in a pull request.

What I would do differently: set the caps before the rebalance. Moving 157G by hand was a symptom. The preference was the disease.

That worked, but it was still a script mutating live infrastructure. OpenTofu made the edge reviewable: one plan, one state, one place to see what changed.

This is how the migration went.

What was already in the edge

The account has three zones:

• bismigel.dev, with 21 DNS records;
• ciceley.cc, with two records;
• miguelarbis.dev, with three records.

There is one remote-managed Cloudflare Tunnel, seven Access applications, four security zone settings and one R2 lifecycle policy. The old script owned all of it.

Importing one resource at a time

I did not import everything at once. I started with one DNS record and checked that tofu plan was a no-op. Then I expanded to the rest of the zone, the tunnel ingress configuration, the Access applications, zone settings and finally R2.

The final state covers:

• 26 DNS records across three zones;
• the tunnel ingress configuration;
• seven Access applications with their app-scoped policy references;
• ssl, min_tls_version, always_use_https and security_header;
• the R2 lifecycle rules for homelab-backups.

tofu plan is clean.

The parts that did not import cleanly

Access API timeouts

The first Access import attempts returned 504 from the account-level API. The Cloudflare status page showed a partial outage while the Access component itself showed operational. I did not rotate the token or change the provider. I waited and retried.

When the API recovered, all seven applications imported:

Successfully imported cloudflare_zero_trust_access_application.books
...

The policies are inline, app-scoped policies. The application resource imports their references, so there is no separate reusable policy resource.

R2 lifecycle has no import

The provider documentation is explicit:

This resource does not currently support terraform import.

Instead of leaving R2 in the shell script, I created the cloudflare_r2_bucket_lifecycle resource over the existing rules. OpenTofu adopted the four rules in place. The plan was clean afterward.

There is a sharp edge: OpenTofu cannot destroy this resource. Removing it from configuration and applying would drop it from state, not delete the rules. That is documented in the repo.

State on R2, with native locking

Local state was the next risk. The state now lives in the existing R2 bucket:

terraform {
  backend "s3" {
    bucket                      = "homelab-backups"
    key                         = "opentofu/cloudflare/terraform.tfstate"
    region                      = "auto"
    endpoints                   = { s3 = "https://<account>.r2.cloudflarestorage.com" }
    use_path_style              = true
    skip_credentials_validation = true
    skip_region_validation      = true
    skip_requesting_account_id  = true
    skip_s3_checksum            = true
    use_lockfile                = true
  }
}

R2 speaks the S3 API. No AWS account is involved. The credentials are R2 access keys from the existing backup environment, not values in the repo.

The lock works. I started two plans at once. The second one failed with:

StatusCode: 412, api error PreconditionFailed

That is the S3 native lockfile doing its job. The encrypted state backup remains in r2:homelab-backups/opentofu/ as a recovery copy.

Retiring the daily writer

Once tofu plan was clean, the script had to stop writing. I removed the daily Systemd timer from the NixOS module and kept the service for a manual rollback.

That deployment exposed an unrelated build problem: sops-install-secrets had moved to a Go 1.26 module requirement while the pinned nixpkgs still built Go 1.25.7. The deployment failed before activation. I pinned sops-nix to the last Go 1.25-compatible revision and built the package with the matching vendor hash. The host deployed, and cloudflare-sync.timer no longer exists.

What I would do differently

• Import the read-only resources first. DNS and tunnel were easy; Access was the one with an API outage.
• Move state before adding more resources. The migration is simple while the state is small.
• Test the lock deliberately. A backend without a working lock is just remote storage.
• Do not treat a clean plan as proof that every resource is covered. The plan is only clean for resources that are in configuration. The old script could still write things OpenTofu did not know about.

Links

• OpenTofu S3 backend: https://opentofu.org/docs/language/settings/backends/s3/
• Cloudflare R2 lifecycle resource: https://search.opentofu.org/provider/cloudflare/cloudflare/latest/docs/resources/r2_bucket_lifecycle
• Cloudflare provider: https://registry.terraform.io/providers/cloudflare/cloudflare/latest/docs