I take backups of 2 laptops across wireless connections to a NAS.  A couple days ago I had a wireless connection drop during a backup - a new full backup.  Not surprisingly, the backup failed.  There followed a multi-step tale of woe.

1. When I restarted the backup it failed again with a message indicating that a backup was still in progress. 
   
2. There was a "Backup Running" (or something like that) and a .tmp file in the target directory.  Not knowing anything better to do, I deleted them.
3. The next backup seemed to be running fine but hung up when saying there was only a few seconds left.  After about 10 minutes I tried cancelling the backup but the cancel did nothing (other than give me the "Are you sure?" popup).  After another few minutes I rebooted out from under the backup.
4. There followed a repeat of items 1, 2 & 3 (with much shorter waits on my part).
5. I deleted and re-entered the backup definition, performed step 2, and tried again.  Repeat of step 3.
6. I performed step 2 again and booted a Rescue Medium. It hung when trying to find the backup files (which were present).  Cancel was ignored.  The Rescue Medium was not current - v7.2.5107, I think - but I suspect that was not the problem.
   
7. I moved all backup files into a new directory (for future diagnosis if needed) and tried a new backup.  It worked flawlessly.

My guess is that a previous backup got corrupted when the network disruption happened, but I don't understand how.   I don't have access to this laptop at the moment, but I'm almost certain the backup scheme is very simple - saving 2 full backups and any associated incremental backups.  Cleanup involves deleting a whole chain; no synthetic fulls or any other kind consolidation; nothing that would require rewriting (or even reading) any of the backup files.  I try to keep backups to the NAS as simple as possible.

So what could have happened?

Hi Patrick,
happy new year lad!

1 When I restarted the backup it failed again with a message indicating that a backup was still in progress.
you have in fact to delete the backup in progress file
Canceled or terminated backups alone should not cause such error states from my testings and you know me

If you can reproduce this, I would appreciate to open a ticket, the support is much more responsive and professional as we are used to. Promised 👍🏻

+x

 

alQamar - 7 January 2021 8:42 PM

If you can reproduce this, I would appreciate to open a ticket, the support is much more responsive and professional as we are used to. Promised 👍🏻

Since the problem seems to have started with a network problem I have no easy way of reproducing it.  And I don't really have any way of collecting diagnostic data. I guess I could perpetually run a packet trace, but I'd rather not do that.

+x

 

alQamar - 7 January 2021 8:42 PM

Hi Patrick,
happy new year lad!

1 When I restarted the backup it failed again with a message indicating that a backup was still in progress.
you have in fact to delete the backup in progress file
Canceled or terminated backups alone should not cause such error states from my testings and you know me

If you can reproduce this, I would appreciate to open a ticket, the support is much more responsive and professional as we are used to. Promised 👍🏻

Cancelled or terminated backups generally don't, Macrium cleans up the temp files, however, if a drive (network or directly attached) gets disconnected, there's no way it can do so, since it can't see the drive to delete the temp file.

In the case where a USB drive became disconnected, you almost certainly want to run CHKDSK (/scan or /f) on it before the next backup, so personally I don't see not automatically deleting the temp file as an issue, but rather an alert that manual intervention is called for. 

it is a good practice to enable the automatic chkdsk in the backup & restore options. I stopped counting the issues I had with backups that worked fine and restores that failed because of a competitor product does not do this and the restore took ages and ultimately failed due to MFT issues in the backup.
Patrick to reproduce the issue if you are using wired or wifi you can unplug the cable or disable the wifi this should cause a similar behaviour and different to just disable the adapter in Windows 10

I agree with Beardy in such a case the app is not able to delete the file and won't delete it next run. Packet trace is not necessary at this stage.

+x

 

alQamar - 8 January 2021 9:36 PM

... to reproduce the issue if you are using wired or wifi you can unplug the cable or disable the wifi this should cause a similar behaviour and different to just disable the adapter in Windows 10

This problem happened when I was trying to diagnose what I thought was an intermittent wireless drop-out problem.  To check it I disconnected my desktop PC's Ethernet cable, plugged in an external wireless adapter, and watched it for a day.  When the problem hit, it seemed like the wireless connection  dropped and reconnected several times in rapid succession.  If so, just breaking the connection once probably will not provoke the problem.  But I'll try it.

I see Patrick, this tool should help you, we use it sometimes to track issues with Citrix ADC and VPN
https://jagt.github.io/clumsy/index.html

+x

 

alQamar - 8 January 2021 10:13 PM

I see Patrick, this tool should help you, we use it sometimes to track issues with Citrix ADC and VPN
https://jagt.github.io/clumsy/index.html

I'll look into that, but I'm not short of packet sniffing tools.  I regularly use WireShark and sometimes have used Windows' built-in netsh trace command.   Just today I discovered both of them can create circular trace output files.  I could set up the trace to run perpetually ... as long as I notice that there's been a problem and stop the trace.

This is probably not the way to approach the problem, though.  I guess I really should open a Macrium problem ticket and ask what diagnostic data to collect in case the problem reappears.

Patrick, this is not a sniffing tool but can simuilate different network issues. There is a how-to / docs on the webpage

Good news. potientially

Bug fixes and Improvements v7.3.5550 - 18th January 2021

Backup_running
A failed backup, due to power failure or removing the target drive, could cause the next backup to fail by detecting, but not deleting, the 'backup_running' mutex file. This has been resolved.