Backup Central

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

A newly installed CentOS 6 / Bacula 5 backup server is reporting
this when backing itself up:

FD Bytes Written: 53,655,908,904 (53.65 GB)
SD Bytes Written: 53,664,006,577 (53.66 GB)
Last Volume Bytes: 53,705,852,928 (53.70 GB)

Which is truly amazing because the actual amount of data stored
on this system is far less than that:

[r2d2 < at > backup ~]$ LANG=C df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/vg_backup-lv_root
50G 2.2G 45G 5% /
tmpfs 1.9G 0 1.9G 0% /dev/shm
/dev/sda1 485M 47M 413M 11% /boot
/dev/mapper/vg_backup-lv_home
174G 2.4G 163G 2% /home

Any explanations for that discrepancy?

No configuration data included because I don't have any idea
what might even be relevant.

Thanks,
Tilman

- --
Tilman Schmidt
Abteilungsleiter Technik
- ----------------------------------------------------------------
Phoenix Software GmbH Tel. +49 228 97199 0
Geschäftsführer: W. Grießl Fax +49 228 97199 99
Adolf-Hombitzer-Str. 12 www.phoenixsoftware.de
53227 Bonn, Germany Amtsgericht Bonn HRB 2934
- ----------------------------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.12 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk7t9BUACgkQ780oymN0g8NXtgCg5EIX4P9g9aC+nySncfoXoSJX
TnoAoLw+xLMAPingj7+Hooq+dhyaBUAt
=cYe4
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
Learn Windows Azure Live! Tuesday, Dec 13, 2011
Microsoft is holding a special Learn Windows Azure training event for
developers. It will provide a great way to learn Windows Azure and what it
provides. You can attend the event by watching it streamed LIVE online.
Learn more at http://p.sf.net/sfu/ms-windowsazure
_______________________________________________
Bacula-users mailing list
Bacula-users < at > lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

On Sun, Dec 18, 2011 at 9:09 AM, Tilman Schmidt
<t.schmidt < at > phoenixsoftware.de> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

A newly installed CentOS 6 / Bacula 5 backup server is reporting
this when backing itself up:

 FD Bytes Written:       53,655,908,904 (53.65 GB)
 SD Bytes Written:       53,664,006,577 (53.66 GB)
 Last Volume Bytes:      53,705,852,928 (53.70 GB)

Which is truly amazing because the actual amount of data stored
on this system is far less than that:

[r2d2 < at > backup ~]$ LANG=C df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/vg_backup-lv_root
                      50G  2.2G   45G   5% /
tmpfs                 1.9G     0  1.9G   0% /dev/shm
/dev/sda1             485M   47M  413M  11% /boot
/dev/mapper/vg_backup-lv_home
                     174G  2.4G  163G   2% /home

Any explanations for that discrepancy?


No, I have never seen anything like this. And this is from a bacula
user for 8+ years who has run tens of thousands of backups for a
department with 50+ machines and 30 to 50TB on tape. I suggest you
examine what bacula has saved in the backup. The simplest way is to
use the bat version browser or the new restore viewer if you have
bacula-5.2.X.

John

------------------------------------------------------------------------------
Learn Windows Azure Live! Tuesday, Dec 13, 2011
Microsoft is holding a special Learn Windows Azure training event for
developers. It will provide a great way to learn Windows Azure and what it
provides. You can attend the event by watching it streamed LIVE online.
Learn more at http://p.sf.net/sfu/ms-windowsazure
_______________________________________________
Bacula-users mailing list
Bacula-users < at > lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

From FAQ Bacula Wiki:

Why is my backup larger than my disk space usage?

The most common culprit of this is having one or more sparse files.

A sparse file is one with large blocks of nothing but zeroes that the operating system has optimized. Instead of actually storing disk blocks of nothing but zeroes, the filesystem simply contains a note that from point A to point B, the file is nothing but zeroes. Only blocks that contain non-zero data are allocated physical disk blocks.

The single biggest culprit seems to be the contents of /var/log/lastlog on 64 bit systems. Since the lastlog file is extended to preallocate space for all UIDs, the switch from a 32 bit UID space to a 64 bit UID increases the full size to over 1TB.

Luckily the fix is simple - turn on sparse file support in the FileSet, will detect sparse files and not store the zerofill blocks.

Another possible cause is that your fileset accidentally includes some folders twice. Taken from the manual:

Take special care not to include a directory twice or Bacula will backup the same files two times wasting a lot of space on your archive device. Including a directory twice is very easy to do. For example:

Include {
File = /
File = /usr
Options { compression=GZIP }
}

on a Unix system where /usr is a subdirectory (rather than a mounted filesystem) will cause /usr to be backed up twice.


----- Original Message -----
From: "John Drescher" <drescherjm < at > gmail.com>
To: "Tilman Schmidt" <t.schmidt < at > phoenixsoftware.de>
Cc: "bacula-users" <bacula-users < at > lists.sourceforge.net>
Sent: Sunday, December 18, 2011 10:21:58 AM
Subject: Re: [Bacula-users] amazing backup size

On Sun, Dec 18, 2011 at 9:09 AM, Tilman Schmidt
<t.schmidt < at > phoenixsoftware.de> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

A newly installed CentOS 6 / Bacula 5 backup server is reporting
this when backing itself up:

 FD Bytes Written:       53,655,908,904 (53.65 GB)
 SD Bytes Written:       53,664,006,577 (53.66 GB)
 Last Volume Bytes:      53,705,852,928 (53.70 GB)

Which is truly amazing because the actual amount of data stored
on this system is far less than that:

[r2d2 < at > backup ~]$ LANG=C df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/vg_backup-lv_root
                      50G  2.2G   45G   5% /
tmpfs                 1.9G     0  1.9G   0% /dev/shm
/dev/sda1             485M   47M  413M  11% /boot
/dev/mapper/vg_backup-lv_home
                     174G  2.4G  163G   2% /home

Any explanations for that discrepancy?


No, I have never seen anything like this. And this is from a bacula
user for 8+ years who has run tens of thousands of backups for a
department with 50+ machines and 30 to 50TB on tape. I suggest you
examine what bacula has saved in the backup. The simplest way is to
use the bat version browser or the new restore viewer if you have
bacula-5.2.X.

John

------------------------------------------------------------------------------
Learn Windows Azure Live! Tuesday, Dec 13, 2011
Microsoft is holding a special Learn Windows Azure training event for
developers. It will provide a great way to learn Windows Azure and what it
provides. You can attend the event by watching it streamed LIVE online.
Learn more at http://p.sf.net/sfu/ms-windowsazure
_______________________________________________
Bacula-users mailing list
Bacula-users < at > lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

------------------------------------------------------------------------------
Learn Windows Azure Live! Tuesday, Dec 13, 2011
Microsoft is holding a special Learn Windows Azure training event for
developers. It will provide a great way to learn Windows Azure and what it
provides. You can attend the event by watching it streamed LIVE online.
Learn more at http://p.sf.net/sfu/ms-windowsazure
_______________________________________________
Bacula-users mailing list
Bacula-users < at > lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users