Can't select Destination Folder on external USB Drive for Backup using ATI 2016
I've upgraded from ATI2014 to ATI2016 so that I could continue my backups after upgrading to Windows 10. When the software starts, it finds my former backups on my USB WD 4TB MyBook. However, once I select the button to try to look at the destination folder, all I see is a picture of a USB connector. All that can be selected is the root of that drive. There seems to be no way to drill down to select lower level folders. (Remember, that the lower level folders orignially showed up in the summary list of existing backups.)
Is there a limitation of the new version that prevents this selection (i.e. a bug)?
Or am I doing something wrong?
Help! This is very frustrating.
Also, the former backups don't run. I suppose that is because the software cannot recognize the old location (Although I don't know why since the program knows how to find the instructions). I think this must be a bug!
Could you post some screen shots of the trouble? If it sees the older backups, you should be able to recover just fine. To recover files/folders, you only need to double click on a backup.tib file in Windows File Explorer and should be able to see the files in it and then copy and paste from it.
If you want to recover a full partition or disk, then I would boot into your Acronis offline bootable recovery media, click on recover, navigate to the backup file, select the restore to the desired disk and let it run. As always, when restoring... if possible, restore to a different disk (just in case so you don't overwrite the original if that's the only working copy).
Most likely, you need to re-select the source and destinations in your backup scripts and they will begin running again. Othwerwise, just create new backup tasks moving forward, and hold onto the old ones for posterity.
Maybe I can simplify my question a bit. Forget whether or not I can select a former backup set. What I cannot do is set up a new backup set to point to a folder lower than the root of the External Hard Drive.
I am attaching two screenshots...
The Custom Destination is what you see when you go to select the destination.
The USB Option is all you get to select within the External Drive.
In your second screenshot, just click on "browse". It should then list all disks attached to the system and allow you to navigate to them. If you attached the drive after starting acronis, close Acronis and restart it and it should detect the drive after that. Drives attached after starting Acronis, are not always automatically detected.
You are right. I looked there before but just didn't drill down to the right place.
Late to the party - I know. Can't afford to update to all the latest whiz-bangs, so I still use ATI2016 and suspect others do too.
I started seeing this problem with my USB3.0 backup drive, possibly related to Windows 10 Anniversary Update or later revisions. I say that because other WX users complain the OS saves power by putting external drives, especially USB3.0, a bit too quickly and deeply asleep. They've tried many tricks - registry hacks, disabling power saving per device or USB hub in Device Manager, and using odd or somewhat crippling settings in system Power Options - with varying success; none of which I am fond.
I could hear my drive revving up after the ATI notification icon in the taskbar went red and ATI refused to continue (and termed it "my decision"), so here's what I did ...
I added a folder named HDDwake on the backup partition and added a batch file ("N:\HDDwake\HDDwake.bat") containing:
@Echo %Date% %Time% %UserDomain%\%UserName% %* >> HDDwake.log
where: "%* = any arguments you wish, and ">>" (creates the log file if it does not exist and) appends to the log file (change ">>" to ">" to replace the log file on each write).
Then I modified my daily, self-cleaning, differential ATI backup profile to add a Pre-Command:
|Command = N:/HDDwake/HDDwake.bat|
|Working directory = N:/HDDwake|
|Arguments = ATI2016 PreCommand DOS write to wake HDD for backup|
|[v] Do not perform operations until the command's execution is complete|
|[v] Abort the operation if the user command fails|
Then I closed ATI and waited until I heard the drive power down, and then initiated a commandline backup by profile name (same as a scheduled backup). Happily ATI stalled, then I heard the drive power up, then I saw a DOS box briefly wink in and out of existence, and then the daily backup completed without error for the first time in over a week.
Neutron - good test/work-a-round. This should also be useful for those who only wish to backup on their local network so it doesn't keep trying when they are away. If the log can't write, it won't be able to proceed with trying the backup :)
If only ...
As it turns out, the DOS write may not occur, possibly because ATI has decided that N:\HDDwake\HDDwake.bat couldn't possibly exist; so hey, must be an error. In case that's so, I'll move the batch file to known-approved location C:\somewhere\HDDwake.bat and make it shout across to N:\HDDwake\HDDwake.log because I doubt ATI (or much else, for that matter) can read and pass judgement on creepy batch code.
If it's reliable, I'll give it a little more charm and post it back here. Seems like ATI itself could perform a preliminary extra-contextual bump test like this before assuming the backup location is gone.
In the mean time, I did the registry hack which, I discovered, Microsoft has already done for other devices in the same HKLM Key. If this actually works, then I will have to remove it for an accurate test of the batch approach - the latter being safer for ordinary mortals than regedit.
OK, the registry hack works by itself and likewise the batch write; i.e., it's unnecessary to use both methods. Probably.
Batch Write method
On a drive, which ATI always sees, exists (e.g.) "C:\someFolder\HDDwake.bat", entered as the ATI Pre-Command executable, containing:
Manually create the log folder (and subfolder, etc) yourself. You can make the batch file write any junk you please:
— "@Echo FOO >> N:\HDDwake\HDDwake.log"
but it won't be as informative. Another advantage is that you can "ping" your specific backup location (network drive, folder). This Batch Write method saves a bit of HDD wear by only waking it up when needed, it doesn't require you to alter your (pristine?) Windows OS, and specifically it doesn't require a risky system registry modification. That said ...
Hack Edit method
If you've heard this before, here it is again. Avoid editing the Windows system registry if you can get the same effect via established user settings. If you must edit the registry (in this case, you must): make certain you are wide awake (even if you already think you know what you are doing), keep your hands (and cats) away from the touch-screen (use a mouse), and back up the registry (or at least the parent key) first. Because registry edits are real-time, you are one errant drag-n-drop or keystroke away from sorrow. Never leave the registry open and unattended. Sorry: it's my standard speech. Here are the steps, using my HDD's codes for example - your codes are different ...
In Device Manager, find the HDD device, right-click and open its Properties
Right-click Start > Run > type "regedit" (sans quotes), then cascade-open down to the following key:
Close Regedit. Disconnect the drive (let it spin down) and reconnect the drive. Done.
Barring unforseen catastrophe, this Registry Edit method will keep the backup drive spinning (and wearing) from the moment you power it up to the moment you power it down. I know, it's modern hardware; so why harp on wear? 7200rpm * 60min * 24hrs = holy crap! And you actually use how many of those cycles? This is why modern power management exists.
If the backup drive is currently spinning, ATI will see it either:
— when ATI checks the specs in Pre-Command(s), or
— when ATI begins backup processing,
whichever occurs first; else it will fail. While the drive is asleep, ATI will display the last-known backup location specs, per the OP's screenshot, but it won't try to awaken the drive.
I believe that modern Windows's aggressive power management is the "reason" why it has been said that ATI sometimes fails to see the backup drive; but it's also because ATI presumes user error without testing its own presumption.