Hi Sergio,

You are right about the file sets. The Windows file set is about a quarter the size, compared to the Linux one. There are no database backups, just files. Neither have I seen any network bottlenecks. Both servers are connected to the same switch, with a 10GbE trunk directly to the backup server. And the backup jobs are scheduled at different times, so there should not be any network bottlenecks with competition for bandwidth. The Windows server is using NTFS, whereas the Linux server uses the ext4 file system.

I haven't got a clue if the the time it takes for creating the VSS snapshots is included in the total time, or if the time it takes is significant. I guess somebody with knowledge about the inner workings of Bacula FD could answer that question.

Best regards,

Peter


On 01.03.2019 8:35, Sergio Gelato wrote:
* Peter Milesson [2019-02-28 20:22:41 +0100]:
I'm backing up 2 servers with Bacula, one with Windows 2016, the other one
with CentOS. The hardware is described below. The Windows server is much
more powerful than the Linux server in all respects, and should
theoretically deliver data to the Bacula server at a much higher rate. But
in reality, the Linux server delivers data about 7 times faster over the
network, than the Windows server.

Is this completely normal, or should I start to check up the Windows server
for problems?
You didn't provide enough information. Are the filesets being backed up
comparable? (I mean in terms of number and size of files and fraction of
the filesystem being backed up.) It looks like both backups take nearly
the same wallclock time but end up with vastly different transfer rates,
so I'm guessing that the Windows backup job is a lot smaller. In fact,
the wallclock times are so close that I wonder if they aren't dominated
by some kind of fixed setup cost (slow database? network timeout issues?)

With a storage throughput of only 60 MB/s on the SD the difference in network
speeds (1Gb/s vs. 10Gb/s) is not going to be significant.

You also didn't mention the filesystems involved. NTFS on Windows and one
of the usual suspects (ext4, xfs, btrfs) on Linux? For backup jobs involving
lots of small files filesystem overhead is likely to make a difference.

How long does VSS snapshot creation take on the Windows side, by the way?
Is that overhead included in the average transfer rate calculation?

I suppose you meant TB instead of GB for the hard disk capacities.

Best regards,

Peter


Windows server (file server, RDP-server, Hyper-V host with 2 very lightly
loaded VMs)
=====================================================================
Hardware: HP DL180 Gen9, Intel Xeon E5-2683v4, 48GB RAM, Smart Array P440
Controller, 6x SAS 1GB (7200 rpm, 12 Gb/s) in RAID5
Network: 2x 10GbE to HPE 1950 switch (LACP)
OS: Windows 2016 (build 1607)
Throughput to Bacula server: 23-Feb 08:52 MySd JobId 991: Elapsed
time=00:26:09, Transfer rate=4.071 M Bytes/second


Linux server (plain file server with Samba)
==================================
Hardware: HP DL120 Gen9, Intel Xeon E5-2603v3, 8GB RAM, HP Dynamic Smart
Array B140i SATA Controller 2x SATA 2GB (7200 rpm) in RAID1
Network: 2x 1Gb to HPE 1950 switch (LACP)
OS: CentOS Linux 7.5 (1804)
Throughput to Bacula server: 23-Feb 08:26 MySd JobId 990: Elapsed
time=00:26:08, Transfer rate=28.29 M Bytes/second


Bacula server
===========
Hardware: standard motherboard with a 6-core AMD FX-6300 CPU, 4xSATA 8GB
(7200 rpm) in RAID10
Network: Tehuti 10GbE NIC to ProCurve 2910al switch
OS: CentOS Linux 7.6 (1810)
Bacula server throughput to the RAID array: ca. 60 Mbytes/second

All switches are connected to our 10Gb/s optical network backbone.






_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Reply via email to