We’re using UrBackup on our network (3 backupped machines). The server itself is set to backup about 280GB of files. The other 2 machines are disabled. An incremental backup, with maybe 1GB of changed data (pessimistic guess) takes 2 days. We’re on Server and client 1.4.1.
Something must be wrong, but I cannot figure out what it is. Any ideas?
Can you set the clients & server to debug mode and post the logs?
What spec is your server/clients/network too?
The server is running on Windows Server 2012 R2, having 1 quad-core hyperthreaded cpu, with 8GB of ram. The client connected is the same machine (It’s a fileserver, hosting about 280GB of files). So network is loopback (should be)
I can’t find a debug mode setting anywhere. What am I missing?
Server: C:\Progam files\UrBackupServer\urbackup.log
Client: C:\Progam files\UrBackup\debug.log
In Windows there is a args.txt in the same directory as the log file. Change warn here to debug.
You need to restart the server/client for this change to come into effect.
As another thought, is this all on the same disk? I’m wondering if there is some I/O disk performance problems at play, might be worth monitoring with the backup?
It is on the same disk. (The system runs in a hyperV machine) However, a couple of weeks ago, an incremental backup took about 1.5 hours. My guess is I’ve goofed up some setting…
Tomorrow I’ll restart the server+client, and restart a backup.
Maybe it is the poor hard-link performance of NTFS? Do you have the “Use symlinks during incremental file backups” enabled?
In 1.4.2 the server will also write some more information about the backup progress into the normal logs.
Uroni: Yes, symlinking option is enabled. I thought that was default behaviour in 1.3 as well?
I found some leads I think: vssadmin list writers shows that all writers are in “Waiting for completion” state.
Doesn’t sound ok.
How can I post files, which wont be viewable by all?
I’d like the log files to be handled a bit “confidential”…
Send it to martin@urbackup.org or per private massage.
Okay. I can see no obvious problems, except that it downloads too much files during incremental backups. This could be caused by
To further narrow down the problem you could look at the produced file list at urbackup\data\filelist.ub on the client and the clientlist_[id].ub on the server during a incremental file backup and compare them via e.g. WinMerge.
Can this be caused by Windows Server Deduplication?
Answering my own question: Yes it does. See http://support2.microsoft.com/kb/2906888
Now I’m just curious if there’s a workaround for this behavior, or any other way to speed up my backups…
Also, I’m unable to disable the symlinking. Urbackup keeps enabling the checkbox.
Thanks for the hint! Just fixed that.
I still don’t understand what changed and caused my backups to take a day. I’ve been using deduplication from the start of my urbackup adventure…
Any ideas?
NTFS allows one to list the paths of all hard links to file data. For that it has to actually save the paths for each hard link. The first 7 times or so this data can be saved into the MFT, after that it has to allocate a separate (called non-resident) section causing an additional disk seek, which causes much lower hard link performance. See e.g. here http://osronline.com/showThread.CFM?link=228355 .
You could try to remove IO from the backup volume by using the temporary files for file backups (in the advanced settings). That way the files are loaded to the temporary folder and not the the backup storage.
Are you considering to implement improved support for Windows Server deduplication? See http://msdn.microsoft.com/en-us/library/hh769304(v=vs.85).aspx