This one's kind of weird. Once a week, I update three images, two for drives on my main PC, a Windows 11 box, and one for the system drive on my Windows 10 file server PC, which I access over Remote Desktop. I always run the remote IFW concurrently with the local IFW; the destination is the same folder on a local SSD I use just for backups. Tonight, I started the remote incremental image as usual and proceeded to concurrently image my local VM drive. I saw the VM image depended on 9 backups, so I cancelled the operation just after it began so that I could make a new full backup. To my surprise, this local IFW instance popped up a message box asking me for the filename of the incremental image the remote IFW was writing to. Not knowing what to do, I clicked "Cancel", and that was that. The error log contained:
[02/01/2024 12:40:51 AM] Are you sure you want to cancel?
[02/01/2024 12:40:53 AM] Elapsed 0:00:00:08
[02/01/2024 12:40:53 AM] Deleting incomplete or failed backup.
[02/01/2024 12:41:37 AM] Are you sure you want to cancel?
[02/01/2024 12:41:39 AM] Cannot open "Q:\Images\nas-w0-2024-02-01-003820-chg.TBI".
[02/01/2024 12:41:44 AM] Deleting Q:\Images\vm-w4-2024-02-01-003907-chg.TBI
[02/01/2024 12:41:44 AM] Elapsed 0:00:01:01
[02/01/2024 12:41:44 AM] Operation Completed with Error Code 1 (Cancel)
[02/01/2024 12:41:44 AM] Stop
The remote IFW was writing to the "nas" TBI file. The local IFW was cancelling the "vm" TBI file. Why would the local IFW care or even know about what the remote IFW was doing? I don't see the connection.
Spooky interaction between remote and local IFW 3.60 instances
-
- Posts: 3628
- Joined: Thu May 05, 2011 10:37 pm
Re: Spooky interaction between remote and local IFW 3.60 instances
It doesn't, but you may have chosen the one as the base. The full log would show more.
Re: Spooky interaction between remote and local IFW 3.60 instances
That's the only occurrence of "nas" in the full log. I've attached the full logs for the local and remote IFW instances in a zip file. I did search/replace my main system's network path name with "mainsystem" and deleted all the VSS exclusions, which contain several usernames, and can't have any bearing on the issue.
I remember pressing "Cancel" twice because the first press didn't seem to have any immediate effect, and that seems to be confirmed by the log snippet I posted in my OP. I considered the possibility that I mistakenly cancelled in the remote instance and then switched back to my main system and cancelled there, and thus was mixing up which system I was on, but the log snippet in my OP comes from:
vm-w4-2024-02-01-003907-chg.log
The remote instance used this log file, and it contains nothing about cancelling, nor does it contain anything about "vm":
nas-w0-2024-02-01-003820-chg.log
This "nas" log contains the following, which you can see completely brackets the time interval from the "vm" log snippet in my OP having to do with cancelling; nothing about cancelling on the "nas" side:
[02/01/2024 12:40:03 AM] Total Sectors:974,518,944 (464.69 GiB) Sectors to Process:180,972,304 (86.29 GiB)
[02/01/2024 01:01:36 AM] 7,593,400 Sector(s) (3.62 GiB) backed up
The remote IFW on "nas" completed normally without any interruption. AFAICT, the weirdness was all happening in the local IFW instance.
I remember pressing "Cancel" twice because the first press didn't seem to have any immediate effect, and that seems to be confirmed by the log snippet I posted in my OP. I considered the possibility that I mistakenly cancelled in the remote instance and then switched back to my main system and cancelled there, and thus was mixing up which system I was on, but the log snippet in my OP comes from:
vm-w4-2024-02-01-003907-chg.log
The remote instance used this log file, and it contains nothing about cancelling, nor does it contain anything about "vm":
nas-w0-2024-02-01-003820-chg.log
This "nas" log contains the following, which you can see completely brackets the time interval from the "vm" log snippet in my OP having to do with cancelling; nothing about cancelling on the "nas" side:
[02/01/2024 12:40:03 AM] Total Sectors:974,518,944 (464.69 GiB) Sectors to Process:180,972,304 (86.29 GiB)
[02/01/2024 01:01:36 AM] 7,593,400 Sector(s) (3.62 GiB) backed up
The remote IFW on "nas" completed normally without any interruption. AFAICT, the weirdness was all happening in the local IFW instance.
- Attachments
-
- crawfish.zip
- (2.39 KiB) Downloaded 130 times
-
- Posts: 3628
- Joined: Thu May 05, 2011 10:37 pm
Re: Spooky interaction between remote and local IFW 3.60 instances
it shows the two, but not the entire chain, you won't see it now that it's gone, but if you highlighted the full in the ifw file list, press del, it will show all the files in the chain (obviously cancel out of the delete dialog).
Re: Spooky interaction between remote and local IFW 3.60 instances
Oh, that's interesting. I didn't know you could get that information that way. It turns out I haven't overwritten my weekly offline backups of these files, so I still have copies from last week, which were the basis for the ones I've been talking about. I did what you said for the full "vm" and "nas" backups, and they only reference "chg" files with their same respective "vm" and "nas" prefixes, all the way up to the ones I made last week, the basis for this week. I don't see how it could be otherwise. See attached screenshots.
The files I'm talking about in the subject of this thread were created in exactly the same way using the same scripts as these predecessor files. I don't see how the file created by the remote IFW:
Q:\Images\nas-w0-2024-02-01-003820-chg.TBI
could have gotten into the different chain ending in this file created less than a minute later by the local IFW (file creation date/times are in the filenames as yyyy-mm-dd-hhmmss and set by the script I use based on the current time):
Q:\Images\vm-w4-2024-02-01-003907-chg.TBI
These are different backup sets that image different drives of different sizes containing different partition sets residing on different systems, backup sets that are created/appended in the same way using the same scripts every week. I think IFW would reject any attempted mixing, and there hasn't ever been any. The only occurrence of the filename prefix "nas" in the logfile for "vm" is in the error message that says it "cannot open" it in the middle of the cancellation of "vm". In particular, no filename pertaining to "nas" appears in the command line for "vm". Why would the local IFW instance processing "vm" prompt me with a dialog box that it can't find a "nas" file and record this in its logfile when I tried to cancel "vm"?
The files I'm talking about in the subject of this thread were created in exactly the same way using the same scripts as these predecessor files. I don't see how the file created by the remote IFW:
Q:\Images\nas-w0-2024-02-01-003820-chg.TBI
could have gotten into the different chain ending in this file created less than a minute later by the local IFW (file creation date/times are in the filenames as yyyy-mm-dd-hhmmss and set by the script I use based on the current time):
Q:\Images\vm-w4-2024-02-01-003907-chg.TBI
These are different backup sets that image different drives of different sizes containing different partition sets residing on different systems, backup sets that are created/appended in the same way using the same scripts every week. I think IFW would reject any attempted mixing, and there hasn't ever been any. The only occurrence of the filename prefix "nas" in the logfile for "vm" is in the error message that says it "cannot open" it in the middle of the cancellation of "vm". In particular, no filename pertaining to "nas" appears in the command line for "vm". Why would the local IFW instance processing "vm" prompt me with a dialog box that it can't find a "nas" file and record this in its logfile when I tried to cancel "vm"?
- Attachments
-
- 2024-02-02.png (11.64 KiB) Viewed 2238 times
-
- 2024-02-02 (1).png (8.22 KiB) Viewed 2238 times