Just want to be 100% sure. From my testing and items I have read on forum. UrBackup cannot do Exchange incremental backups it uploaded the full .edb every time.
I think I’m having this same problem.
Essentially, I’d like advise on the best way to backup Exchange if possible. I’m not sure Image backups are necessary here but am on the brink of trying them as a solution.
I’m running Exchange 2010 (with Circular Logging enabled) on Server 2008 R2.
Backing up over the internet to UrBackup 2.2.11 running on Server 2012 R2 to a dedicated local Dynamic NTFS volume with Compression enabled. The client is running ‘2.2.12-cbt beta’
The job is set up as a File Backup just doing the desktop (c. 60Kb of data) and with only the Mailbox Database and Public Folder Databas selected under Windows Components. CBT is enabled for this client. These two DBs are 87Gb total on Disk. There are just 4 low-daily-use but quite old mailboxes active on this server so minimal daily change.
Image backups are disabled.
Having read something somewhere I set ‘Local full file backup transfer mode’ to Raw instead of Hashed for this client.
I would have hoped that this would have resulted in an original c. 80Gb Full Backup followed by MUCH smaller and quicker incrementals… but it seems to be producing c. 80Gb incrementals each time… and yes, they’re 80Gb on disk.
Any assistance, thoughts, advise will be gratefully received.
If you set the local transfer mode of incremental backups to “block differences - hashed” it should only transfer changed blocks in the file. On Windows with NTFS it will still store whole copies of files.
Currently it can only directly store differences with ZFS or btrfs (on Linux/FreeBSD). On Windows you can for example use Windows Server Dedup, though that would be a bit less efficient. Windows Server Dedup also compresses, I think.
Hi Uroni and thank you for your quick and helpful response.
I have enabled Dedup and will do some testing on it.
I have also made the “Block Differences - hashed” change to “Local incremental file backup transfer mode” but I had previously ignored this as I didn’t think it would make a difference to this backup as it is over the internet (The server and the client are on two different networks separated by the internet - there is no UrBackup server on the same network as the client)
Just for what it’s worth, enabling DeDupe on my UrBackup volume yesterday has recovered just 12 Gb of Space. The volume is currently 460 Gb in size. Free space went from 140 to 152 Gb. I’m pretty sure no Backup jobs had an impact on this at the time. Worth remembering compression was already enabled on this volume.
Any feedback on my previous post gratefully received.
Ok, then you’d have to set it for the Internet transfer mode. It will show the amount of data transfered during a backup in the backup logs.
Thank you Uroni… but the “Internet incremental file backup transfer mode” was already set to “Block Differences - hashed”.
The backup that’s currently running is taking much longer than previous ones - it’s been running since Monday but is due to finish later today. I’ll let it finish before changing anything else. I’m wondering if maybe it’s never been able to make a full backup and therefore every time it tries it’s trying to do a full… though the attached screen-shot disagrees. The setting for “Internet full file backup transfer mode” is “Raw”… and that might be better off as “Hashed”.