new Full needed when changed drive connection
This post is just FYI:
Incremental failed because I switched the SATA connections on the backup destination HDD from a SATA-PCI card to an onboard SATA port. I didn't expect it (but I'm not surprised, on Norton Ghost restore operations could be dependent upon not changing connections [aka 'backup architecture]), but my next step was to run a Full and it completed AOK. In case anyone's curious, here's the failure operation's log:
11/16/2018 12:26:36 PM: -08:00 4932 I00640000: Backup reserve copy attributes: format tib; need_reserve_backup_copy false; 11/16/2018 12:26:36 PM: -08:00 4932 I00640002: Operation Old-C started manually. 11/16/2018 12:26:40 PM: -08:00 4932 I00640000: Backup reserve copy attributes: format tib; need_reserve_backup_copy false; 11/16/2018 12:26:40 PM: -08:00 4932 I013C0000: Operation: Backup 11/16/2018 12:26:40 PM: -08:00 4932 I0064000B: Priority changed to Low. 11/16/2018 12:26:40 PM: -08:00 4932 E000B0428: Error 0xb0428: The backup location was not found on the destination drive. Make sure the correct storage device is connected to the computer. | trace level: error | line: 0x4d3f22948e29f39f | file: c:\bs_hudson\workspace\431\products\imager\archive\impl\utils.cpp:712 | function: TrueImage::Archive::CheckVolumeDeviceIdMatch | line: 0x4d3f22948e29f39f, c:\bs_hudson\workspace\431\products\imager\archive\impl\utils.cpp:712, TrueImage::Archive::CheckVolumeDeviceIdMatch | Path: G: | ExpectedId: STORAGE\VOLUME\{F8F090DE-CA5B-11E7-B65A-806E6F6E6963}#0000000000007E00 | ActualId: STORAGE\VOLUME\{1BF8F3D5-E9DC-11E8-BB40-806E6F6E6963}#0000000000007E00 | $module: ti_demon_vs_12510 11/16/2018 12:26:40 PM: -08:00 4932 E013C0005: Error 0x13c0005: Operation has completed with errors. | trace level: error | line: 0x9f2c53c72e8bce5f | file: c:\bs_hudson\workspace\431\products\imager\demon\main.cpp:617 | function: main | line: 0x9f2c53c72e8bce5f, c:\bs_hudson\workspace\431\products\imager\demon\main.cpp:617, main | $module: ti_demon_vs_12510 Start: 11/16/2018 12:26:36 PM |


- Accedi per poter commentare

Thank you very much for that info, Steve!
Does this 'drive ID' situation also pop up during (pre-ATIH2019, and ATIH) boot media (I never restore in my OS) restore operations?
(I would have thought that this was a dumb question, but with Ghost the connections of the source and destination drives sometimes had to be the same [even if the original source HDD had died and was being replaced]. So when I change the connections of HDDs involved in backups, I always put a txt file in the backup folder so that I know how to replicate the backup architecture during the restore. I don't change connections much (and I never do backups to external drives) but it would be a nice convenience to have restores be free of such concerns. (It's pretty minimal inconvenience to just need to do a new Full when architecture changes.)
Maybe enough for me to go for ATIH2019 after all!
- Accedi per poter commentare

Never heard of any of these ID issues when using the ATI Rescue Media as this is independent of the internal Acronis database where this information gets stored away for backup tasks shown in the GUI.
- Accedi per poter commentare

Sweet. That is a great relief. I guess I've been needlessly noting my infrequent changes in backup architecture!
- Accedi per poter commentare