On 01/10/2012 10:44 AM, IEM - network operating center (IOhannes m zmoelnig)
wrote:
> (sorry if this comes thru as a dupe; i first sent this mail from an
> unsubscribed account)
>
>
> hi all,
>
> i have a problem with bacula and incremental/differential backups
> from an XFS filesystem.
> to put it simple: bacula always creates full backups.
>
>
> the long story:
> we deployed bacula to backup our users' directory a while ago (that was
> bacula-2.2.4 or so) and had good success so far (thanks, btw)
> back then, the homedirectory on the fileserver (running debian/i386 with
> bacula-fd) was a 2TB partition using ext3.
> the backupserver (running debian/i386 with bacula-dir (postgresql) and
> bacula-sd) stores all data on an DLT-S4 autochanger with a capacity of 12TB.
> incremental backups of the user' homedirectories typically took less
> than 30GB each day.
> unfortunately our users filled up the homedirectory, so we decided to
> upgrade the fileserver, and it now has a capacity of 20TB. since there
> are no ext4 userland tools to handle such a capacity, we are now using
> xfs as the filesystem. the fileserver is now also running an x86_64
> system (still debian).
> the new fileserver runs bacula-5.0.2 (as packaged for debian), so we had
> to upgrade the backup-server from the originally used bacula-2.4.4 to
> bacula-5.0.2; the upgrade had some problems (regarding the postgresql db
> update), but it seems to have succeeded.
> at least all the other servers that are being backed up, are doing fine.
> these servers are running bacula-2.4.4 and bacula-2.2.8
>
> unfortunately, the backup of the new fileserver makes problems:
> there are 2 jobs for this server, one doing a system backup, and the
> other one doing the backup of the users' homes.
> the system backup seems to work fine, but the homes fail to do
> incremental backups.
> after an initial full backup started last wednesday (which consumed
> 1.33TB), an incremental backup was started on friday (which also
> consumed 1.33TB, and is virtually identical to the full backup just
> made); another incremental backup just started and has currently
> consumed 280GB, indicating that it is running yet _another_ backup of
> the entire fileset.
>
> i wonder what went wrong?
> i suspect that the problem is related to the use of XFS and/or to the
> fileserver now being 64bit.
>
> below you can find some technical info.
>
> any help is appreciated.
> esp. since i simply cannot afford to spend a DLT tape each day....
>
>
> mfgasdr
> IOhannes
>
>
> bacula specific information
> ===------------------------
> according to [2] i collected the directoris configuration and the output
> of "list jobs" and "llist" for the Full-job and the Incr-job (that
> wrongly did a full backup again). find them in the attached tgz.
>
>
> operating systems
> =----------------
> backupserver$ uname -a
> Linux backup.server 2.6.32-5-686 #1 SMP Thu Nov 3 04:23:54 UTC 2011 i686
> GNU/Linux
> fileserver$ uname -a
> Linux file.server 2.6.32-5-amd64 #1 SMP Thu Nov 3 03:41:26 UTC 2011
> x86_64 GNU/Linux
>
> inode size
> =---------
> i compiled the following little program as found on [1] on both my
> backupserver and my fileserver:
> <snip>
> #include <sys/stat.h>
> #include <stdio.h>
> int main(void) {
> struct stat s;
> printf("Size of inode is %d bytes\n\n", sizeof(s.st_ino));
> return 0;
> }
> </snip>
>
> results:
> fileserver : Size of inode is 8 bytes
> backupserver: Size of inode is 4 bytes
>
> XFS on the fileserver
> =--------------------
> root@fileserver# xfs_info /dev/vda
> meta-data=/dev/vda isize=256 agcount=20, agsize=268435455 blks
> = sectsz=512 attr=2
> data = bsize=4096 blocks=5119999991, imaxpct=5
> = sunit=0 swidth=0 blks
> naming =version 2 bsize=4096 ascii-ci=0
> log =internal bsize=4096 blocks=521728, version=2
> = sectsz=512 sunit=0 blks, lazy-count=1
> realtime =none extsz=4096 blocks=0, rtextents=0
>
>
>
> links
> =----
>
>
> [1]
> http://www.backupcentral.com/phpBB2/two-way-mirrors-of-external-mailing-lists-3/bacula-25/bacula-xfs-and-inode64-98549/
>
> [2]
> http://www.bacula.org/5.2.x-manuals/en/problems/problems/Bacula_Frequently_Asked_Que.html#SECTION002280000000000000000
>
>
First of all, I'm using also xfs on data source and/or backup media.
There's no special trouble on them to get incremental/differential backup.
What I suspect could be : an antivirus or any other scripts running on the xfs
partition that change attribute or acl on files
It will be better for you have 5.0.3 or wait until 5.2.4 release version.
Check also the parameter used for your incremental (did you use Accurate
Backup?)
If the filesystem xfs is not mounted with the noatime option, check to have
noatime option in the bacula job.
so it will not change each file during the full backup, then creating a new
fool backup for the incremental.
--
Bruno Friedmann
Ioda-Net Sàrl www.ioda-net.ch
openSUSE Member & Ambassador
GPG KEY : D5C9B751C4653227
irc: tigerfoot
------------------------------------------------------------------------------
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create
new or port existing apps to sell to consumers worldwide. Explore the
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users
|
