Direkt zum Inhalt

new Full needed when changed drive connection

Thread needs solution

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
Stop: 11/16/2018 12:26:40 PM
Total Time: 00:00:04

 

0 Users found this helpful

Another FYI, Acronis has modified the way it detects drives from ATI 2019 by changing from using the drive unique ID to using the partition unique ID for the drive instead, which should help alleviate this type of issue as the partition ID should remain unchanged even when the connection or drive letter changes.

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!

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.

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