Bug #3012
closed
Bug in full backup size computation and/or display
0%
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
Updated by Chris Buechler over 11 years ago
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.
Updated by Jerome Alet over 11 years ago
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).
Updated by Renato Botelho over 11 years ago
- 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.
Updated by Jerome Alet over 11 years ago
[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.
Updated by Chris Buechler over 11 years ago
- 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.
Updated by Jerome Alet over 11 years ago
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.