Bug #3012
closed
Bug in full backup size computation and/or display
Added by Jerome Alet almost 11 years ago.
Updated almost 11 years ago.
Category:
Backup / Restore
Description
We have installed several releases of 2.1 on AMD64 since it's in BETA stage over the course of several months, but this minor bug is still present (I've previously reported it to the users mailing list). The full backup disk size as displayed in the "Diagnostics: Restore full backup" page is entirely incorrect. See the attached PNG image for details.
Files
that's the extracted size, not compressed size. Whether it's better to put the compressed size there I'm not sure, people need to know the restored size if going to restore it.
Sorry but how could a 30 GB compressed file be extracted and only consume 640 MB ? If restoring is not complete and ignores some directories, then I don't see any reason why backup would be complete, and so a significant list of "directories to ignore when backing up" should be integrated into the backup script (i.e. Squid's cache, for example in our own case, which takes HUGE time to backup).
- Status changed from New to Feedback
Seems there is something wrong with the backup file. I tested it here, GUI says 392.43Mb and I checked the file:
[2.1-RC0][admin@pfsense.localdomain]/root(2): ls -la pfSense-full-backup-20130531-1017.tgz
-rw-r--r-- 1 root wheel 140928784 May 31 10:17 pfSense-full-backup-20130531-1017.tgz
[2.1-RC0][admin@pfsense.localdomain]/root(4): gzip -l pfSense-full-backup-20130531-1017.tgz
compressed uncompressed ratio uncompressed_name
140928784 411494400 65.7% pfSense-full-backup-20130531-1017.tar
Try to run a 'gzip -l' on your 30Gb file to see what it says.
- Assignee set to Renato Botelho
[2.1-BETA1][root@pfsense1.univ-nc.nc]/root(2): ls -la pfSense-full-backup-20130519-0828.tgz
-rw-r--r-- 1 root wheel 30472611938 May 19 09:54 pfSense-full-backup-20130519-0828.tgz
[2.1-BETA1][root@pfsense1.univ-nc.nc]/root(3): gzip -l pfSense-full-backup-20130519-0828.tgz
compressed uncompressed ratio uncompressed_name
30472611938 655804416 -99.9% pfSense-full-backup-20130519-0828.tar
[2.1-BETA1][root@pfsense1.univ-nc.nc]/root(4): uname -a
FreeBSD pfsense1.univ-nc.nc 8.3-RELEASE-p8 FreeBSD 8.3-RELEASE-p8 #1: Wed May 15 13:51:55 EDT 2013 root@snapshots-8_3-amd64.builders.pfsense.org:/usr/obj.pfSense/usr/pfSensesrc/src/sys/pfSense_SMP.8 amd64
As you can see, the ratio is incorrect.
To the best of my knowledge the fact that the file is 30 GB is probably correct, because our 32 GB Squid cache is included in the full backup.
HTH.
- Status changed from Feedback to Closed
something wrong with that backup file, or maybe with gzip itself. Nothing we can do either way, it does work correctly in general, and we don't maintain gzip.
Nothing to do with this particular backup file, since the problem is there each time we do a new full backup. Most probably related to the backup's size. FYI on a 64 bits GNU/Linux with gzip 1.3.7 the ratio appears as "-4546.6%" when doing "gzip -l" on this file.
Sorry I meant gzip 1.3.12
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by 