#3506 Issue closed: ReaR backup size

Labels: support / question, fixed / solved / done, won't fix / can't fix / obsolete

exfarmer opened issue at 2025-08-05 18:43:

Requesting support or just a question

ReaR backup size

Platform

Linux x64

Question

Is there a way to know the size of the rear backup before it is run?

jsmeix commented at 2025-08-06 06:55:

@exfarmer
what exactly do you mean with "ReaR backup size"?
The size of the ReaR recovery system image
or the summary size of all files in the ReaR recovery system
or the size of the archive of the backup of the files
or the summary size of all files in the backup archive?

Regardless what specific size you mean:

As far as I know there is basically nothing implemented in ReaR
which calculates such a size of "something" in advance
before the actual "something" is made.

The only thing I found right now at first glance
(I did not do an exhaustive search) is
https://github.com/rear/rear/blob/master/usr/share/rear/backup/RSYNC/default/450_calculate_req_space.sh
As far as I see from plain looking at its code
it calls df for the items in backup-include.txt
but I wonder how that works because df reports for filesystems
and when an item in backup-include.txt is not a whole filesystem
then df falsely reports the used space of its whole filesystem
and not only the used space of the item in backup-include.txt
which is what du would do.

As far as I remember some time ago the same kind of question
had been asked here at ReaR upstream but currently I cannot
find that issue...

jsmeix commented at 2025-08-06 07:12:

...I think it had been asked via our GitHub "discussions"
but we removed all our "discussions" contents, cf.
https://github.com/rear/rear/issues/3427
so my former reasoning and explanation is lost :-(

exfarmer commented at 2025-08-06 11:44:

Hi,

I want to know if there is enough space on the NFS share before running the backup.
This does help, I didn’t think about rsync. I thought du would be the easiest, but then I need to know the exact file list.
I thought using rear -s mkbackup would figure that out without actually doing the backup, but that’s not the case.
I also thought that there may be some compression involved.

I can find the actual size in the backup.log file on the share directory, Total bytes written: . That would be a guideline, but that would be nice to figure out before running the backup.

Thank you
Abbott

jsmeix commented at 2025-08-07 10:49:

Usually when making a backup compression is involved
so depending on the files contents it is very different
what size is needed for files in a compressed backup.

Therefore it is impossible to calculate in advance
only from the plain sizes of the files on the disk
what size they will need within a compressed backup
without actually doing the compression of the backup
i.e. without actually doing the backup.

So using du output could be at most a vague guess
what space will be needed within a compressed backup.

An extreme example to point this out:

# mkdir backuptest

# cd backuptest

# dd if="/dev/random" of=random.1GiB bs=1M count=1024

# dd if="/dev/zero" of=zero.1GiB bs=1M count=1024

# tar -czvf backup-random-zero.tgz random.1GiB zero.1GiB
random.1GiB
zero.1GiB

# tar -czvf backup-random.tgz random.1GiB
random.1GiB

# tar -czvf backup-zero.tgz zero.1GiB
zero.1GiB

# ls -lhtr
total 4.1G
...  1.0G ... random.1GiB
...  1.0G ... zero.1GiB
...  1.1G ... backup-random-zero.tgz
...  1.1G ... backup-random.tgz
... 1018K ... backup-zero.tgz

# du -hc random.1GiB zero.1GiB
1.1G    random.1GiB
1.1G    zero.1GiB
2.1G    total

It depends very much on the specific file contents
how much they can be further compressed.
In particular already compressed file formats
(for example audio / video / images data)
versus uncompressed file formats.

exfarmer commented at 2025-08-07 12:19:

Yes, all true.
Thank you for your help

Abbott


[Export of Github issue for rear/rear.]