OMV backup creates >25GB dd images despite system partition <5GB full

1. offizieller Beitrag

    I guess the subject line sums it up.


    I have OMV living in a 32GB partition on a 250GB SSD, and a backup running weekly to dd the system to a folder on my HDD RAID.

    The first few backups (after freshly installing OMV) resulted in image files of 6GB, 11GB, and then 13GB in size. Now they've ballooned to an average of 24-25GB.


    This isn't really a problem for me, as I have ample space, but as the actual filesystem usage in OMV is shown to be less than 5GB, I just wonder why the images are so large (especially since they're compressed .gz files). Something to do with unused space on the SSD not being TRIMmed, maybe? Is there something I can do about it?

  • cubemin

    Hat den Titel des Themas von „OMV backup creates >30GB dd images despite system partition <5GB full“ zu „OMV backup creates >25GB dd images despite system partition <5GB full“ geändert.
    • Offizieller Beitrag

    my understanding:

    dd is doing a bit-by-bit (or block-by-block) copy of the filesystem. This is done for actually used data but also for free space and deleted data. If the unused data are mostly Zeros the compression works very good, but deleted data do not compress well. Benefit: you could still restore deleted files.

    To reduce the size of the backup you could write zeros to the space of deleted data, but this will greatly increase the bytes written to the drive. So not a good idea.

    You could also use a different method like fsarchiver.

    You're right. I suppose I'm spoiled by the way Windows imaging software takes a volume snapshot and only copies blocks in use by the filesystem, not a forensic image of the entire partition.

    I guess I was just more surprised that unused blocks on my OMV (ext4) partition (which is to say, non-zero blocks) piled up so quickly. Must be a result of log file rotation and temp files, etc.

    I'll look into fsarchiver etc. and see if they suit my needs better. Thank you. :)

    • Offizieller Beitrag
    Zitat von cubemin

    You're right. I suppose I'm spoiled by the way Windows imaging software takes a volume snapshot and only copies blocks in use by the filesystem, not a forensic image of the entire partition.

    Clonezilla does that as does fsarchiver and borgbackup. Pretty sure no one wants the backup plugin to zero all free space before doing the dd backup.

    omv 7.0.5-1 sandworm | 64 bit | 6.8 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.13 | compose 7.1.4 | k8s 7.1.0-3 | cputemp 7.0.1 | mergerfs 7.0.4


    omv-extras.org plugins source code and issue tracker - github - changelogs


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

    I'm not in the habit of resurrecting old threads, but just wanted to mention I happened across a solution to the issue of overly large 'dd' backup files (while doing something completely unrelated). ^^


    Turns out my SSD hasn't been TRIMmed since the system was first installed because the fstrim.timer service was disabled. So I issued systemctl enable fstrim.timer (for those unaware, this sets up a weekly TRIM of all existing filesystems every Monday at midnight).


    I also ran systemctl start fstrim.service to immediately TRIM my SSD and then ran a new backup. Bam! Much, much smaller now and reflecting the actual filesystem usage of my system. :)

  • cubemin

    Hat das Label gelöst hinzugefügt.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden