Backup with Image for Windows getting slower and slower

[mirko]

I'm doing backup of 2TB disk (in mirror - Intel Matrix Storage Manager) with ~600 GB of data, using Image for Windows 2.74.
The backup strarts fine, ~50MB/sec (~3 1/2 hours remaing), but then it slows down constantly, and remaining time increases. Now it's on ~5MB/sec. 55% done, and it says "12 hours remaining."
OS is Windows Server 2003 SP2, Acronis snapman driver is not installed.

Why is it slowing down? Did anyone have similar problem?

[TeraByte Support]

what's your target device? how much other activity? With IO throttling
enabled (the default) it gives way for other io to complete.

"mirko" wrote in message news:3127@public.image...

I'm doing backup of 2TB disk (in mirror - Intel Matrix Storage Manager) with
~600 GB of data, using Image for Windows 2.74.
The backup strarts fine, ~50MB/sec (~3 1/2 hours remaing), but then it slows
down constantly, and remaining time increases. Now it's on ~5MB/sec. 55%
done, and it says "12 hours remaining."
OS is Windows Server 2003 SP2, Acronis snapman driver is not installed.

Why is it slowing down? Did anyone have similar problem?

[adx]

The same here. Apologies if there is a newer thread on this subject, but my computer is going too slow to browse for it

I am backing up from an internal magnetic drive to an external USB3 drive. HDtune transfer rates are somewhere around 90 & 110 MB/s respectively, the internal drive does drop as the test progresses as usual, but not to less than 50%. Windows XP is running off a SSD, which usually transfers somewhere around 200MB/s. It's running on an i7 (8 cores with HT), max RAM. NOD32 antivirus, but nothng else intrusive to the filesystem that I can think of. Imagew 2.83, I've just upgraded from 2.22 where I've never noticed that problem before, though don't read too much into that.

With compression turned to fast A, the Image backup started fine at peaks of 70MB/s (written), then visibly drops over a few mins, I assumed due to inner tracks at first. But it just drops lower and lower, initially I thought this might be due to compression or IO throttling (which I then turned off and left off) so abandoned a few backups. But this morning about 280GB into a 750GB disk after 10 hours it's down to 4MB/s with frequent big gaps of nothing, all the while the system is running like treacle, HDtune gives me something like 1MB/s off the SSD now, which drops to zero with tiny spikes. Transfer rate is continuing to drop and I assume the 7 hours to complete wil never reduce, so I'd better abandon it before the system crashes and I lose any Pylock data (never had a data loss problem).

But before I do, task manager says Image's CPU has risen to 9% (from 4), System is using 13% (ie all of one of the 4 physical cores). I can't get much more useful info out of Process Explorer, although it's just SYSTEM and services.exe doign a lot of kernel stuff from what I could see.

I'll revert to 2.22 and if I have any astounding insight's I'll post them here.

CPU usage is about 4% (ie about 30% of a physical core).

[adx]

Reading my reply I should clarify that the overnight 'test' had compression on (fast A) and throttling off.

BTW after reverting to IFW 2.22, it's currently backing up the inner tracks of the drive a little slowly (writing at ~25MB/s varying depending on compressability I assume), but after half an hour has not showed any signs of dropping, or stalling the filesystem. CPU use appears to be high but non-saturated. Running HDtune on C:'s SSD gives ~180MB/s reads (which is normal) and doesn't appear to affect the image backup running off/to the other drives.

[adx]

Update: It's doing exactly the same on IFW 2.22. The slowdown is progressive and continuous. I'm sure I used to be able to back up a whole drive, but would usually leave it going overnight so may not have noticed? This partition used to have a lot less on it.

The shorter backup I mentioned was ok but a small slowdown was visible by the end. But this one (a 460GB partition) is now 5 hrs in, 319MiB done, time remaining has gone from 2:10 to 2:09 over 15 minutes. HDtune says 24MB/s off the otherwise-idle SSD (this number drops and drops), the system is getting too laggey to use so I'm going to have to abort the backup again to get any work done tonight. Backup writes are down to 6MB/s, starting from about 35MB/s 5 hours ago. Disabling NOD32 did nothing. There is no runaway memory use or anything like that I can see.

[TeraByte Support(PP)]

If you have any old IFW log files from when you think it was working you could check them. The logs might be in an older backup.

Have you tried using No Compression when backing up?

Have you checked the Windows Event Log for any file system errors?

Have you checked the SATA cables, connections, etc.?

Have the Storage Controller drivers (most likely AHCI) been updated/changed? You could check for a more current version.

Is the system cooling properly? It doesn't sound like it's stressing it enough to overheat, but doesn't hurt to check.

[TeraByte Support]

If something is hitting your drives hard it will slow down the backup as
well as other IO (indexing for example). If there are any media issues
starting that will also slow things down as the drive takes longer to
respond.



"adx" wrote in message news:6202@public.image...

The same here. Apologies if there is a newer thread on this subject, but my
computer is going too slow to browse for it


I am backing up from an internal magnetic drive to an external USB3 drive.
HDtune transfer rates are somewhere around 90 & 110 MB/s respectively, the
internal drive does drop as the test progresses as usual, but not to less
than 50%. Windows XP is running off a SSD, which usually transfers somewhere
around 200MB/s. It's running on an i7 (8 cores with HT), max RAM. NOD32
antivirus, but nothng else intrusive to the filesystem that I can think of.
Imagew 2.83, I've just upgraded from 2.22 where I've never noticed that
problem before, though don't read too much into that.

With compression turned to fast A, the Image backup started fine at peaks of
70MB/s (written), then visibly drops over a few mins, I assumed due to inner
tracks at first. But it just drops lower and lower, initially I thought this
might be due to compression or IO throttling (which I then turned off and
left off) so abandoned a few backups. But this morning about 280GB into a
750GB disk after 10 hours it's down to 4MB/s with frequent big gaps of
nothing, all the while the system is running like treacle, HDtune gives me
something like 1MB/s off the SSD now, which drops to zero with tiny spikes.
Transfer rate is continuing to drop and I assume the 7 hours to complete wil
never reduce, so I'd better abandon it before the system crashes and I lose
any Pylock data (never had a data loss problem).

But before I do, task manager says Image's CPU has risen to 9% (from 4),
System is using 13% (ie all of one of the 4 physical cores). I can't get
much more useful info out of Process Explorer, although it's just SYSTEM and
services.exe doign a lot of kernel stuff from what I could see.

I'll revert to 2.22 and if I have any astounding insight's I'll post them
here.

CPU usage is about 4% (ie about 30% of a physical core).

[adx]

Hi, thanks for the replies. I actually penned this reply after the first one but didn't have time to send it.

I suspect hardware has little to do with it. As soon as I cancel, system responsiveness and tranfer rate from the SSD are back up to normal. I haven't checked for SATA errors thoroughly, but haven't seen any disk errors on this machine, or SMART ent-to-end errors etc. The drives also seem to be capable of reading and writing faster, with spikes of high transfer if used during a backup. I don't appear to have any thermal problems, a week or so ago I had the system happily running with 8 CPU cores and 2 GPUs all at 100%.

It's a Gigabyte P55 motherboard, all drives are IDE emulation, UDMA5 according to Windows (easier to fix something if it goes wrong). If I let Windows have at the driver update, it doesn't suggest anything newer for the Intel chipset.

Nothing untoward in the event log.

CPU rises from from very little (say 1%) to imagew.exe using 7% System 6% (and will keep rising to use ~1 core (12.5%) each). When the "System" process becomes saturated, that's when the main system responsiveness slowdown seems to start.

At the same time, backup transfer rates smoothly reduce (see attached png). But using HDtune (previously), internal HDD transfer rate is constant until about 20% into the disk, so if the backup is starting from the outer tracks then there should be no slowdown during the first few minutes at all. Despends where it starts I suppose. The external drive is a cheapie new Seagate USB3 which doesn't drop off at all from 110MB/s (admittedly reads). The disk can write a lot faster even during a backup (using Windows perfmon). Maybe something is clogging up in the USB3 controller - I'm used to using Imagew with USB2 and higher compression which would tend to mask the problem. The problem becomes noticeable after about half an hour of backing up where the transfer rate might be half and system slowdowns start to become noticeable.

The only thing that could have been loading up I/O during the backup (except for short deliberate Hdtune tests) is a SW firewall which both reads and writes to the disk regularly, but with it disabled completely the problem still existed. I have all indexing etc turned off, all things like superfectch or whatever XP calls it (no benefit with an SSD). The only thing I wanted to do during a backup was use Word and stuff like that.

I retried with PHYlock disabled and ignored the warning, and saw the same effect. This was surprising, since I can't see what else it could be, if it's not something low-level like this. A windows drag and drop copy goes ok (it's what I did in the end, since the 450 GB partition isn't bootable). BTW, the main reason I use Image, is to backup my system every so often so to avoid the enormous expense of rebuilding it in the middle of an important job - something that only becomes apparent after a crash! I back up the data separately and regularly as well.

Maybe this slowdown is just something wrong (ie a known limitaton) with Windows XP? I'm inclined to write it off to something like that now, may belong in the "too hard" basket.

[attachment=0]IFW start H no compression.png[/attachment]