Project

General

Profile

Actions

Bug #3012

closed

Bug in full backup size computation and/or display

Added by Jerome Alet over 8 years ago. Updated over 8 years ago.

Status:
Closed
Priority:
Normal
Category:
Backup / Restore
Target version:
Start date:
05/29/2013
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
2.1
Affected Architecture:

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

pfsense-bug.png (27.8 KB) pfsense-bug.png Jerome Alet, 05/29/2013 04:29 PM
Actions #1

Updated by Chris Buechler over 8 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.

Actions #2

Updated by Jerome Alet over 8 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).

Actions #3

Updated by Renato Botelho over 8 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.

Actions #4

Updated by Renato Botelho over 8 years ago

  • Assignee set to Renato Botelho
Actions #5

Updated by Jerome Alet over 8 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.

Actions #6

Updated by Chris Buechler over 8 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.

Actions #7

Updated by Jerome Alet over 8 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.

Actions #8

Updated by Jerome Alet over 8 years ago

Sorry I meant gzip 1.3.12

Actions

Also available in: Atom PDF