Function reclaimed_bytes_since 

pub fn reclaimed_bytes_since(
    before: &MaintenanceInfo,
    after: &MaintenanceInfo,
) -> Option<i64>

Bytes of backend storage actually freed by the maintenance run that happened between two kopia maintenance info observations.

kopia maintenance run prints no machine-readable result, so the only way to learn what a run reclaimed is to diff the per-task run history it appends to the schedule blob. Returns None when no counted task produced a new successful run — the honest answer for an epoch-enabled repository’s quick run, which kopia short-circuits into compact-single-epoch + advance-epoch only (runQuickMaintenance), neither of which deletes a blob. Some(0) means a counted task did run and freed nothing; None means unknown. They are never conflated.

What is counted, and what deliberately is not

Counted, because each issues real blob deletes against the backend:

task	statistic
quick-delete-blobs, full-delete-blobs	DeleteUnreferencedPacksStats::deleted_total_size
delete-superseded-epoch-indexes	CleanupSupersededIndexesStats::deleted_total_size
cleanup-logs	CleanupLogsStats::deleted_blob_size

Not counted: snapshotGCStats.deletedContentSize, however tempting its name. snapshot-gc only marks contents deleted in the index (snapshot/snapshotgc/gc.go) and frees no storage at all — the blobs still occupy the bucket until a later *-delete-blobs removes them. Reporting it would show tens of gigabytes “reclaimed” while the bucket did not shrink by a byte. rewriteContentsStats is excluded for the mirror-image reason: it writes new packs and orphans the old ones, so its bytes are moved, not freed.