Ja, hát kérem, az élet nem habostorta. Az adatmentés hely nélkül meg olyan, mint vőlegény nászéjszakán szerszám nélkül. :)
A stratégiát alapvetően az határozza meg, hogy mennyi az annyi.
Mekkora most a gz? Mennyi lenne kitömörítve az image? Kb mennyi terület foglalt benne (beleértve a szemetet is)? Kb mennyi adat ami megmentendő? És ehhez most mennyi hely áll rendelkezésre? Illetve reálisan mennyi helyet tudsz még keríteni?
Illetve: van-e bármi belső struktúra, bontható-e önálló egységekre (pl particionált-e, és mekkorák a particiók), amikkel külön-külön lehet foglalkozni.
Ha ezek ismertek, akkor kb el lehet kezdeni gondolkodni.
Ha a .gz legalább 2x (de reálisan inkább 3x) nem fér el, akkor minden konverzió felejtős, és el kell gondolkodni azon is, hogy a gz-ből kimentett adatokat is valahova tenni kell majd...
Ez esetben maximum azt tudom elképzelni, hogy pl ezzel https://github.com/google/fuse-archive felcsatolod a gz-t (valamelyik feature requestben írják, hogy működik mezitlábas gz-vel is, nemcsak .tar.gz-vel: https://github.com/google/fuse-archive/issues/5)
Ha 1 konverziónak megfelelő hely van (vigyázz, a .gz-nél kisebb blokkmérettel fog dolgozni, rosszabb lesz a tömörítési aránya), akkor fuse-archive mount majd qemu-img convert.
B variációnak az üres helyre egy btrfs-t létrehozni, tömörítést bekapcsolni rajta és oda kitömöríteni a gz-ből az image-et, aztán hagyományos módon losetup-pal loop device-ra felvenni.
Lehet még zcat-tal qemu-img dd subcommandba pipe-olva átfejteni (sose csináltam) illetve stdin-ről qemu-nbd-be pipeolással ugyanez: https://unix.stackexchange.com/questions/536404/qemu-img-compress-image-from-stdin-gunzip de így tippre azt mondanám, hogy ezekben az esetekben a végeredmény nem lesz tömörített.