Sparse file replication size issue

Hi Guys

Please can you assist us with a problem we’re experiencing when backing up sparse files on Linux. We’re using EXT4 as a filesystem.

When we view the sparse file on the client it is 1.6MB big, however, when it is backed up to the server, the size is reported as 80GB. What could be causing the size difference and how can we overcome it?

Please let me know what questions you may have.

Did you check the size of the actual file on server the server, or just looked at the value in the web interface?

We checked the file on server. Please see below.
Client
# du -h -s ./
1.8M ./
# du -lh --apparent-size ./
81G ./

Server

    # du -h -s ./
       81G     ./
    # du -lh --apparent-size ./
      81G     ./

Sorry you are having issues. To solve the problem the server and client (debug) log would be useful.
If possible, could you post it or send it?

This post describes how to change the client and server to debug logging, where it is stored and where to send it to if posting is not possible: Having problems with UrBackup? Please read before posting

Thanks!

Linux kernel version is important as well, the interface was added with 3.8 for ext4.

Thanks, I have sent log files to bugreports@urbackup.org.

We are using the following as a server:
CentOS Linux release 7.5.1804 (Core)
Kernel 3.10.0-862.14.4.el7.x86_64

Thanks. The client kernel version (+distribution) would be more relevant.

Also relevant is the file system the server stores backups to.

Client details
CentOS Linux release 7.6.1810 (Core)
3.10.0-957.21.3.el7.x86_64

Please let me know what questions you may have.

And could you tell me the name of the file?

On the client:

/opt/zimbra/data/ldap/mdb/db/data.mdb

Also relevant is the file system the server stores backups to.

The server stores backups on a disk with ‘ext4’ on it.

Plus server version… plus client version…

Both on ‘ext4’.

Client:
dumpe2fs /dev/mapper/vg_opt-lv_opt
Filesystem volume name:
Last mounted on: /opt
Filesystem UUID: 80c71ab0-3e78-42f9-aa77-70b3ad517aba
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent 64bit flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags: signed_directory_hash
Default mount options: user_xattr acl
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 32768000
Block count: 131070976
Reserved block count: 6553548
Free blocks: 101166029
Free inodes: 32684786
First block: 0
Block size: 4096
Fragment size: 4096
Group descriptor size: 64
Reserved GDT blocks: 1024
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 8192
Inode blocks per group: 512
Flex block group size: 16
Filesystem created: Tue Jul 9 16:10:22 2019
Last mount time: Tue Jul 16 11:39:47 2019
Last write time: Thu Aug 22 18:03:29 2019
Mount count: 13
Maximum mount count: -1
Last checked: Tue Jul 9 16:10:22 2019
Check interval: 0 ()
Lifetime writes: 571 GB
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 256
Required extra isize: 28
Desired extra isize: 28
Journal inode: 8
First orphan inode: 29626733
Default directory hash: half_md4
Directory Hash Seed: aaddee73-9513-4632-8435-c854eabac028
Journal backup: inode blocks
Journal features: journal_incompat_revoke journal_64bit
Journal size: 128M
Journal length: 32768
Journal sequence: 0x0014ee08
Journal start: 1724

Server:
dumpe2fs /dev/mapper/vg_opt-lv_opt
Filesystem volume name:
Last mounted on: /urbackup_data
Filesystem UUID: 45779648-cefe-4df5-89a6-8855ade81751
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent 64bit flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags: signed_directory_hash
Default mount options: user_xattr acl
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 32768000
Block count: 131070976
Reserved block count: 6553548
Free blocks: 112973935
Free inodes: 31112185
First block: 0
Block size: 4096
Fragment size: 4096
Group descriptor size: 64
Reserved GDT blocks: 1024
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 8192
Inode blocks per group: 512
Flex block group size: 16
Filesystem created: Thu Oct 25 15:56:40 2018
Last mount time: Mon Jun 10 11:31:34 2019
Last write time: Mon Jun 10 11:31:34 2019
Mount count: 5
Maximum mount count: -1
Last checked: Thu Oct 25 15:56:40 2018
Check interval: 0 ()
Lifetime writes: 183 GB
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 256
Required extra isize: 28
Desired extra isize: 28
Journal inode: 8
Default directory hash: half_md4
Directory Hash Seed: b094df85-3403-4d33-8526-09708fbb2e7e
Journal backup: inode blocks
Journal features: journal_incompat_revoke journal_64bit
Journal size: 128M
Journal length: 32768
Journal sequence: 0x0001880b
Journal start: 18182

Sorry, I meant UrBackup Server + Client version

UrBackup Server v2.2.11.2193

UrBackup Client Controller v2.2.6.0

It’s a bug. This patch should fix it: https://github.com/uroni/urbackup_backend/commit/119140af95a8b2b0bde5c5cea1fdc1b1ff8ba0ad