Topic: AFFA Server disk space usage

[gklaus]

It seems I seriously miscalculated the amount of disk space an Affa server needs for backups and am wondering if this is its normal behaviour:

The Affa server backs up a production server with a total disk capacity of roughly 140 GB. Yet the first backup run takes 448 GB on the Affa server, more than three times the amount of the original data.

Is this possible normal behaviour or have I encountered a bug or committed some known misconfiguration?

Before deploying the Affa server I did some test runs on different hardware and with less data and did not observe this relation in the sizes of original and backed up data.

The production server holds a huge amount of very small files. Could this be the reason? I do not know how the ext3 filesystem works, but maybe the block size (or something similar) needs to be adjusted?

Also, the production server is configured with separate partitions for /tmp /var and so on, could this possibly cause the larger disk space use?

Many thanks in advance for any replies and comments.

Gerwin

[jester]

Doesn't sound like normal behavior... file a bug if there is not already one.

[mmccarn]

I've had issues when trying to convince Affa to backup to a volume that doesn't support hardlinks (cheap NAS device, for example).

Is there any chance that you are backing up more than you think you are?  That is, does the target server have any mounted network shares that you may be backing up unintentionally?

[gklaus]

Thanks for the replies!

I checked for any additional filesystems being mounted and included in the backup, suspecting a USB disk used for local backups might be mounted by mistake. But that was not the case.

However, I found that the majority of data in the backup folder is contained in .../files/.shadow. It looks to me as if the affa server / rsync replicates links created by the samba-ShadowCopy function as real files on the backup server. I'm not sure how ShadowCopy works, but otherwise I can't explain how the backup of .../files/.shadow can be larger than the entire disk capacity of the source server.

Currently I am testing how well freedup will solve the problem by linking duplicate files within the backup. Another work-around would be to exclude the ./shadow folder from the affa backup. However, I will need to test if this will cause complications when restoring from backup.

I'll file a bug report when I know more.