Backup over FTP x3 faster than SMB

Good question. I too believe there are issues with how the app handles SMB server connections. Having recognition and logon credential issues myself which I have resolved. Yours is the first report I have seen of speed degradation however. Judging from what you post everything except a backup work as intended.

I suggest that you use the applications Feedback feature that can be found in the Help section of the GUI (open book icon) to report your findings. That is the only way to get your issue before the development team.

Posting bugs on an official support forum is not enough?!...

Unfortunately it is not. This Forum is only a user oriented Forum. Acronis development has a very limited presence here so complaints and bug reports are not guaranteed to get to the developers of the product. Using the in app feedback accomplishes this goal.

Acronis is not alone in there being no active monitoring of its forums by support staff. I participate in many Forum and only one has active monitoring (and it is not very active forum). With some forums I have used the moderators report confirmed bugs to the company (but even then nothing may happen).

A Forum is essentially a means for users of a product to help other users.

Ian

PS During beta testing Acronis technical support staff do have a more active presence on the beta forum.

I did sent my comments through the app.
But I realy wonder how such a basic backup task can be so problematic...
I wich Acronis put some work on basic backup task rather than drawing this hugly and non fonctional new interface.

Installed build 5628 : no change :(

I agree with propergol! I have exactly the same issues. These problems also exist in ATIH 2015. It seems like ATIH is not using the current SMB protocol introduced with Windows 8.x

A short layer investigation shows that_
- ATIH 2016 does use SMB when transferring a backup file from PC 1 to PC 2 (target is an SMB share).
- The transmission is done via TCP at layer 3.

- The SMB2 traffic Acronis creates uses SMB2

- When I copy a file via Explorer the transmission is also done via TCP, however there is more regular SMB traffic within the stream.
- The same SMB protocol version is indicated within the traffic when I copy a file via Explorer (from Win 10 to Win 10).

It might be that Wireshark is not correctly reading the used protocol version of SMB.

http://blogs.technet.com/b/josebda/archive/2012/06/06/windows-server-20…

other related threads:

https://forum.acronis.com/forum/92664
https://forum.acronis.com/forum/98001
https://forum.acronis.com/forum/99699

The sentence in the patch notes "up to 50% faster than the competitors" sounds quite odd. Imho the SMB based backup / restore operation are not near to the possible throughput I have when I copy ordinary files (CPU load due compression is not an issue)

topic on Jumbo frames:
https://forum.acronis.com/forum/98115

edit: when running the powershell as admin on the source (get-smbconnection) "PC1" it will show that on Windows 10 I am using only SMB 3.1.1 connections. The sessions and open file handles are visible on the target "PC2" so from my point of view there is no wrong or old SMB protocol in use by Acronis, still I can confirm that files transfers via Acronis are way slower than via Explorer.

PS C:\WINDOWS\system32> Get-SmbConnection

ServerName ShareName UserName            Credential       Dialect NumOpens
---------- --------- --------            ----------       ------- --------
nas        backups   KARLS-PC\Karl       KARLS-PC\Karl    3.1.1   2
nas        backups   NT-AUTORITÄT\SYSTEM Karls-PC\nasuser 3.1.1   1
nas        IPC$      NT-AUTORITÄT\SYSTEM Karls-PC\nasuser 3.1.1   0
nas        Karl      KARLS-PC\Karl       KARLS-PC\Karl    3.1.1  
nas        Software  KARLS-PC\Karl       KARLS-PC\Karl    3.1.1   2

I agree as well, I too identified several faults with the use of SMB during the BETA testing and reported all of them. At one point it seemed as though some of them were going away but with the final release and each subsequent release they have returned.

The one problem I do not have is speed of transfer. Why that is true I am not sure. Could be because I have upgraded almost all of my network components recently, router, switch, DOCSIS 3 modem, cables, might be something there I suppose.

One often overlooked item is router firmware updates, you might want to check that and make certain your router is running the latest firmware. Server side SMB has had a few updates lately as well so that is another area one might investigate.

I have only a L3 switch and a L2 switch in my environment that are involved. Both of them have recent firmwares. I suffer from slow backup / restore speeds since "ages", so it is a not a new issue to ATIH 2016. I have even created a ticket for that but after hours of investigation - with a very eager and competent support agent - we did not come to a conclusion - at the end of the day slow writing speeds over networks are probably not a network or ATIH issue but slow or inconsistent writing speeds of my WD RED.

The only way to disprove this would be to make backups to a faster target like Raid 0 WD RED or SSDs, I cannot be bothered to invest more into hardware atm. Anyway I still think that the speed of ATIH is a concern even on local backup SSD to SSD where I don't get any near to same transfer speeds I would have when I copy files via Explorer, too and this is not a network connection but just in both cases SATA3.

@Propergol, please tell me which FTP server you use where you have monitored these high transfer speeds, I am quite excited to try out the speeds in my network. I won't bother to have a FTP server running on my NAS (Windows 10) if this speeds up my backups.
I have talked to Enchantech about the thing that I actually get near to full 1 Gbps speed (~112-118 MB/s) on my network when copying files. I can remember he said having a 80 MB/s throughput should be quite the optimum to get using jumbo packets.

Karl,

Interesting your comment about backup speed SSD to SSD being slow. I do not wish to hi-jack this thread but I have experienced the same issue. At least I am not alone there.

More on the thread topic, 80MBps plus should be what you achieve with Jumbo Frame support enabled provided it works for you.

OT: Well "slow" SSD speed is relative... but I think speeds around 200 MB/s are not really a bummer, considering I have high performance equipment that is not only serving speed on the data sheet - except for ATIH :/ The IO output seems to bottleneck here (high response times > 500 ms, 100% active time)

output of a file copy (tib file) from same source to target.

I really hope that I will be able to reproduce the speed improvements using FTP at the Thread opener displays it. For SMB and even Disk to Disk performance I lost a bit of confidence in ATIH. I have no evidence but from my gut instinct I would like to say that ATIH 2009-2011 had the fastest backup speeds. This might be bias because back in time the amounts were considerably smaller but he we dealt with much weaker cpus and SATA 1/2 or even IDE (ATA-100 / 133)

The FTP server is Serv-U 15.1 but I guess backup speed would be the same with other servers.

I did an other backup test of my system SSD. The resulting .tib is 12GB. I did measured time needed :

backup to locale HD : 2min11s
backup to remote FTP : 2min25s
backup to remote SMB : 5min11s

I could use FTP, but it cut the .tib into serval 2GB and I found that it is not as clean as a single .tib.

Yep, that's the downside limitation to FTP, 2GB file size limit has always been there.

Thanks I will try this.

Hi guys,

I have tested the situation for my network. I have disabled all specific jumbo packets again as I have found out that my computer limits the SMB traffic to around 80 MByte/s, now I have 112MB/s again. I might look into that seperately (disabling hyper-v switch, NIC driver update)

However I can actually confirm that FTP backups are way faster than SMB based backups, even though FTP has some seconds of breaks because of the 2 GB file split rule, which needs a bit of time for negotiation and proceeding.

My throughput is not that great as propergol reports it, so in my scenario FTP backups are somewhat slower than SMB file copies.

values are Megabytes per second, not Megabit

SMB file copy (PC1 Win 10 - PC2 Win 10): up to 112 MB/s ~ 100 MB/s
FTP ATIH backup (PC1 Win 10 - PC2 Win 10): up to 90 MB/s ~ 88 MB/s
SMB ATIH backup (PC1 Win 10 - PC2 Win 10) up to 70 MB/s ~ 60 MB/s

FTP Server: Filezilla, Z-Compression off.

Native time:
FTP ATIH Full Backup of my drive C. Total time: 6min 54sec
SMB ATIH Full Backup of my drive C. Total time: 10 min 37 sec

When doing FTP based backups I monitor a very high CPU load (up to 100%) on the source (PC1), which cannot be explained by Acronis data compression. Trueimage.exe is causing the CPU load anyway. CPU load on the target (PC2) is fine

Karl, did you report your test to Acronis using the building feedback tool?
Because it looks like the forum isn't the right place to report issues...
I did report the issue last week, with zero feedback from Acronis for now...
Maybe if more users report this SMB speed issue they would fix it in Acronis TI 2017... :D

I agree, using the in app feedback is the best way to get problems in front of the developers. Of course I am certain that Karl knows this but all users are well advised to use the feedback feature.

More than 3 month later and still no solution from Acronis!

COME ON Acronis : your 2016 version of True Image is 3 time slower than previous version!

WAKE UP!

Hello, everyone.

Just tested this scenario backing up a Windows 10 machine to a Windows Server 2012 R2 machine. In both cases pretty much the full bandwidth was used on a 100 Mbps network: 10.3 MBps via SMB and 11 MBps via FTP.

So I suppose this needs to be checked on a Gigabit network; I'll report the results as soon as I can.

Hello Dmitry, thank you for looking into that issue. It has been a while since I made some tests in this regard.

Your approach to test the performance with a 100 Mbit connection is important, as in this case we can safely exclude any bottlenecks either on network or regarding the write speeds of hard disks.

In the recent months I have experienced that my computer that I use as a backup target (Windows 10 PC) cannot handle a full Gigabit write speed all times, most of all because I just use one WD Red. I think, if I could test the same with an SSD or a RAID 0, this would really be able to answer, whether there is software limitation in Acronis or we have a hardware limitation or anything influencing here. Also Antivirus realtime protection can drastically reduce performance as most AV solution are able to investigate streams.

For example: When I transfer a Windows 10 ISO from my computer to my ATIH backup target sometimes I have transfer speeds about 110-120 MByte per second and otherwise the rate drops down to 60-70 MByte per second.

It would be interesting if there is a difference in performance between a disk or file based backup. I was going to test this but at the moment ATIH is not able to do any backup. I would like to contact you seperately because this already reported problem.

The Screenshots show some SMB file from my computer to my named backup target in Acronis, while having no speed drops due to harddisk overload or other influences.

I have a feeling the performance is going to be more related to the target disks ability.  Take the windows transfer speeds with a grain of salt - you're going to see fluctuation in speeds there based upon a number of things such as disk performance, avaialble memory, bus speed, etc.  You might want to test bandwidth speeds using a third party utility like LANSPEEDTEST instead if you're trying to narrow down network transfer speeds and limit some of the other issues that can slow down transfers in Windows and/or at the hardware level. 

Your taget disk performance can also be impacted if there are multiple writes (and/or reads) at the same time.  You'll see this even on USB attached drives - have one copy session, goes pretty fast.  Add a second or third copy session, and all of their performance will be degraded while they're running at the same time.  The WD reds are also not fast "write" drives - they are primarily intended for NAS storage of data that needs to be accessed.  As a 5400RPM drive, it's definitley not going to be the fastest write performer.

Target disks, especially certain NAS and SAN boxes, also often suffer from performance issues when there are simultaneous writes and/or long writes.  I've never liked that when you let Acronis choose the best size for the TIBs that is usually creates one giant TIB file.  That is a lot more network overhead and caching that needs to take place over the network.  As a result, I generally limit my TIB size to about 3GB each... the idea being that performance will be better on the local machine and cause less overhead stress across network transfers of large files.  Also, if I need to copy to a FAT32 drive, they're still a good size.  This is personal preference on the actual size, but I still think that keeping .TIB's to a reasonable size may provide better results. 

I also wanted to note that file size of transfers will make an impact on transfer speeds - even on SSD's and other fast disks, but especially on USB flash drives and slower spinning disks.  Single large files (.iso's and such) generally transfer much more quickly.  If you have a 4GB .iso and a 4GB folder full of lots of little files and benchmark the transfer speeds, you'll find that the single.iso file is going to transfer much, much faster.  It may not be as noticeable on an SSD as a flash drive, but there's definiltey a performance hit.  

Other third party form posts suggest FTP is much faster than SMB and even AFP due to FTP being able to have simultaneous transfers.  Might just be a limitation of SMB compared to FTP...

http://lime-technology.com/forum/index.php?topic=28429.0

https://discussions.apple.com/thread/2130129?start=0&tstart=0

The fact about transfer speed and file size is true, however when it comes to ATIH backup files we can consider we are speaking about big chunks.

I have solved my issue and so was able to make some more screenshots.

Currently I can confirm my previous thoughts and that the harddisk, is more the limiting factor than Acronis.

Screenshot 25 and 27 show the target (left hand) and source (right hand) with Network and disk stats. Revealing that the current backup target is quite busy.
 

Come on!

Re read my first post! If your target disk was "busy", mine wasn't.

If your target backup disk is too slow to test the same backup/copy test I did in my first post then use something else to test.

Assuming you have enough RAM, create a 20 or 10GB RAM disk as backup target, then come back with valids results.

TrueImage backup through SMB is the bottleneck.

I never said my target disk was busy with something else but just did the one backup.

Can you please post the source and destination disk configuration you used so I can get an idea about your setup? Thank you propergol!

Using a RAM disk or SSD seems to be a good idea to avoid bottlenecks at Gigabit transfer speeds.

I will choose to write on an SSD and post my SMB results.

I finally got to test this case on a Gigabit network and there was no difference in performance between FTP and SMB (on the same machine and with the same data): 3 minutes for a 16 GB backup, resulting in 90 MBps transfer speed.

So this at least shows that this issue is not universal and probably environment-dependent.

propergol, are the FTP and SMB directories located on the same disk/volume on the server?

Did you first tested your network SMB copy speed?

If it is working correctly you should then get 115 to 125 MB/s.

Again check my first post : my SMB copy runs at constant 118MB/s, FTP at 118MB/s too, TrueImage SMB backup at 45MB/s, TrueImage FTP backup at 115MB/s.

Yes the my tests were made on the same volume and directory, fast SSDs (SanDisk Extreme II 480) on both sides.

I am pretty sure I can repeat the test on 2 PC with Windows 10 pro rather than 1 Win 10 and 1 Win Server 2012 R2.

Since I have discovered this issue I have uninstalled TrueImage to test other backup solutions... I guess I could reinstall it and give it a other test.

@propergol, at the beginning I was supporting your point as I did too notice some slowness and posted it in other threads aswell.

I think we agree that copying files via SMB using a modern SMB protocol (like since Windows 8.1) should reach very high traffic speeds up to 115 MBit. I cannot really imagine to pass over that as 125 Mbytes per second is the really theoretical maximum. If not using Jumbo packets (I've also elaborated with this) likewise 8 or 9 K packet size we have to consider some traffic overhead for TCP and SMB likewise, so I really cannot believe you can achieve 125 Mbyte per second but 115 Mbyte per second or slightly more (e.g. 118) is doable.

However I think it would be good to rerun the ATIH backup job with following conditions:
1. disable compression this would prevent any CPU bottlenecking.
check the taskmanager for network throughput during the job

if it is again lower than those 115 Mbyte per second you might investigate the stream using Wireshark and look why this might degrade.

2. Instead of using SMB file transfer you may also try to setup an Iperf session on both sides to measure the maximum TCP bandwith, without SMB.

If you could post some screenshots of both conditions or at least the first one, this would be really helpful. I will run some tests with the SSD via SMB today.

3. It would be interesting to know if the Linux based ATIH is slower than using Windows. This could be in particular the case Dmitry, if you have some time to test that. Just from my feeling I think the Linux based ATIH is slower than using it in Windows, and this might be related that the Linux OS is using an older SMB protocol, and / or the network drivers may decrease performance.

Drivers can really make a change. I've updated my 2009 timestamped Realtek gigabit drivers and this really solved some transmission speed issues outside the ATIH topic btw. On Wireshark I was able to see a high load of TCP retransmissions or double ACKs before.

Hi I am back with some quite valid results.

I have the following setup:

2 computers with Windows 10, so using the latest SMB protocol (3.1.1), each with a Gigabit NIC, switches and NICs with updated drivers and standard packet size (1,5 K)
How to find out the used version: powershell as admin > get-smbconnection

Source disk: Samsung EVO 850 250 GB
Destination: OCZ Vertex 4

ATIH 6027, no compression / to exclude CPU bottlenecks, full disk backup, average speed 660-760 Mbit, SMB, CPU load was about 11-12%
ATIH 6027, no compression, Windows 10 ISO, average speed 760 Mbit, SMB, CPU load was about 13-15%

Windows, Windows 10 ISO file copy, average speed 980 Mbit, CPU load was about 10%

So just in this case I can again enforce the point of propergol that ATIH is considerably slower even when using the same protocol.
The results were reproducible for me.

I am not demanding that ATIH should be able to make full use of the Gigabit link here, as this would only be possible if the source and target disks would be able to deliver, but for current I have the "feeling" that ATIH would not even be able to get up to a much higher speed even if there would be any hardware based limitations excluded. The only idea I have is that ATIH does make some checksum or other calculation during the backup that might slow it, but that's something only Dmitry or anyone other might be able to reveal. This might explain the higher CPU load, too.

Cheers,

Karl