Backup forum

Okay, I'll just start the IDrive app again, and let it do its thing, even if it takes hours. Hopefully, that'll work. It's just that I don't have a ton of new files to back up every week, so it usually takes less than a half hour to complete, these days. Thanks!

Further info regarding Preparing file list issues can be found here.

.

Zeke wrote:

The only reason I use Windoze anymore (on my dual boot system w/Linux Mint) is to perform this backup.

.
Most peculiar. Why use Windows to back up Linux data?

I used a small Linux partition to do all my Windows housekeeping. Much more reliable and predictable.

Linux is too dangerous for me to use now. It's too powerful. I find it stressful.
.

Zeke wrote:

I will eventually get around to set up the scripts so I can kiss Windoze goodbye for good.

.
Use fsarchiver in its default config to start with. Examine the results, then play around with the options. You can use diff with a -r switch on two different backup sets to examine the effects of different options.

Thanks

Sharing my experience. Hopefully, this will slightly reduce the overall suffering in the World

In short: My IDrive got stuck with “Preparing file list” looping forever when I tried to execute backup. The solution for me was to enable “Optimize CPU resources” under “Settings”

Longer version:
I bought IDrive for three of my Windows machines as a cheaper replacement of CrashPlan. Unfortunately, two of my machines constantly froze right when backup was starting. It just looped over “Preparing file list” in the beginning. After half a dozen contacts to support, two data dumps to their development team and months of debugging, I got it working.

I still do not know the background reason, but the solution MOST LIKELY was to enable the setting “Optimize CPU resources”. The setting does not seem to be mentioned anywhere in the official documentation. However, according to my Task manager it seems to manage whether the program executes on a single process or multiple processes. I’d guess that the single process somehow got deadlocked. Thus, allowing multiprocessing, things went forward.

Some other things I learned during my journey:
* You can force backup of a path by right clicking in File Explorer (you might need to enable this behavior somewhere in the IDrive settings). This seemed to work all the time, even when scheduled backups or "Backup Now" failed.

* IDrive is not very good with long filenames (> 250 or so characters). You can list these filenames with Windows Powershell script

Get-ChildItem . -Recurse -Force -ErrorAction Continue | Where-Object {$_.FullName.Length -gt 250}
If you do not know Powershell, you should google it a bit. It is a more powerful command line tool than the standard one.

* IDrive does not handle permission problems very well. From Windows standard Command line you can set the permissions correctly with
cacls . /T /E /C /G <user>:F
Replace <user> with your username. This gives you full control for all the files under the current path. More information here: https://ss64.com/nt/cacls.html

An important flag here is /C. It allows the command to continue in case of errors. However, you should also execute the command without the flag. This way you’ll find the files/paths that for some kind of reason are problematic. Typically filename is somehow faulty. Most likely these files are, anyway, skipped by IDrive. So, you need to solve the issue somehow (by renaming, moving or deleting files).

* IDrive does not work with on-demand synching of e.g., Google Drive or OneDrive. Thus, turn on-demand off and have all the files always on your machine.

* IDrive stores interesting logs to
\ProgramData\IDrive\IBCOMMON\SYSTEM\Tracefile.txt and
\ProgramData\IDrive\IBCOMMON\<Windows username>\Tracefile.txt
files. I got error messages like “Error in GetSubRecordsForDedup2() : System.FormatException:” about strings not being valid DateTime values and “Error in FileMove :System.IO.IOException:” about processes not being able to access files

There are also a lot more debugging logs that you can enable by putting a flag value to an IDrive settings file. However, I don’t remember the value and the IDrive support gives it to you when you need to give data dump to their developers.

It seems like IDrive somehow refreshes the backup set selections a bit late - you need to execute backup a few times before seeing the effect in logs. For example, if you add a path to the backup set, the related errors won’t appear in the next backup. In the one after that one, they usually do.

Hopefully, this helps people who can't find good alternative solutions for backup.

Last edited by fohwomp (2022-07-19 21:09:44)

I discovered my IDrive had this issue this morning (wef 22:30 last night).  Whilst informative, this thread (specifically fohwomp's detailed post) did not provide me with the information to stop the continual 'loop'.

However, I found that editing the frequency of the schedule interrupted the loop and it did not restart thereafter.

It's worth a try if your system is affected.

I did set 'Optimize CPU resources', but this setting did not stop the loop, albeit it might later have prevented it recurring ... time will/might tell.