Here is a generic list of a few speed related issues you may find with hard drive backups:

• Slower USB ports – If the HR subsystem is inadvertently using slower USB (1.0, 1.2, or 2.0) versus USB3.0 , it will make a huge difference in performance.
• Anti-virus or Spyware scanners – Often people are running real time anti-virus or spyware scanners. These dramatically slow down performance because each read is run through the AV I/O sub-system. The same is true for *any* piece of software that hooks into the I/O. This can include image utilities like Acronis or Storagecraft if multiple different programs are installed. Try temporarily disabling any AV or anti-spyware software and testing the speed that way.
• Backing up over ethernet – DAS is generally faster than NAS (Network Attached Storage). We sell both, and each has it’s place. For maximum speed use DAS over eSATA or USB3. Backup speeds taking data off remote servers over the 100MB Ethernet network will be slower than Gigabit Ethernet.
• File size and depth structure- plays in heavily to performance. Larger files and fewer deep directories will be much faster to backup than lots of smaller files with complicated directory structure. It’s hard to do much about this but if there are lots of small files that could be the problem. Imaging software that reads at the block level may be better for lots of small files (Acronis, BESR, StorageCraft, Windows native backup).
• Cluster size and drive fragmentation – can dramatically affect read performance. Try defragging (preferably with a 3rd party defragger) the source drive and read http://www.ntfs.com/ntfs_optimization.htm for more tips. If the HR drive has been heavily used, and/or already contains existing data, you may achieve some advantage by defragging it as well as your source drive, but it may not be necessary if your backups delete or overwrite the drives (full backups).
• Backup software – Our speed tests were generally performed with imaging products like StorageCraft’s Shadowprotect. Filebackup is usually slower than block level imaging.
• Compression – If compression is turned on, either on the source NTFS disk, on the destination disk, or in real time while using the backup software, it can slow down backups. Oddly sometimes it speeds it up if compression is done before the data is transferred to the disk because with fast processors that compress quickly, less data is moved to the destination drive.
• Full vs. Incremental Backup – Incremental backups move less data and can be more efficient.
• Verify Options – Any option to verify the backup during performance testing doubles the backup time and should NOT be counted in the benchmark.
• Backup Agents – Some backup “agents” such as Exchange, open file, or SQL agents, may backup much more slowly than native file backup.
• Multitasked CPU – If the CPU is heavily loaded, doing any other type of task, that will obviously affect backup performance. For example, if a server were being heavily used for database access, running spyware, or doing computations during the time of the backup, then fewer CPU cycles would be available to the backup process. Do a CTRL-ALT-DEL, and on the processes tab, arrange processes by “CPU” to see if there is a process taking an inordinate amount of CPU during the backup. Remember spyware can kill performance!
• Low RAM – Systems with very low amounts of available RAM will use the pagefile excessively, dramatically slowing performance.
• Errors on Disk – Errors on the source or destination hard drives will slow performance.
• RAID Arrays – Often servers are running RAID arrays, or software mirrored drives, whose read performance is lower than a stand alone drive would be (In theory it should be faster to read from multiple drives but we’ve seen several examples where RAID performance is a problem). Upgrades to RAID controllers can sometimes be done by adding RAM or processor power. Run our programs called “Fakeback” and TRMark to determine if your source drives are running slowly.