Issue: Drive that backups were on failed, was able to recover back up files that were in good places on the drive.
Replaced HDD with a new one and restored all of my data, using the same drive letter / path as previous install and copied the zips back into the location.
Run the restore process and get the errors below:
System.IO.FileNotFoundException: Could not find file ‘N:\Outlook\backup_202203251844.zip’.
File name: ‘N:\Outlook\backup_202203251844.zip’
at System.IO.FileInfo.get_Length()
at MailClient.DbBackup.FormBackup.Restore(String backupFile, CancellationToken cancellationToken)
at MailClient.DbBackup.FormBackup.Restore(CancellationToken cancellationToken)
at MailClient.DbBackup.FormBackup.<>c__DisplayClass27_0.<MainForm_Load>b__0(Object a, DoWorkEventArgs b)
at System.ComponentModel.BackgroundWorker.OnDoWork(DoWorkEventArgs e)
at System.ComponentModel.BackgroundWorker.WorkerThreadStart(Object argument)
System.IO.FileNotFoundException: Could not find file ‘N:\Outlook\backup_202203291844.zip’.
File name: ‘N:\Outlook\backup_202203291844.zip’
at System.IO.FileInfo.get_Length()
at MailClient.DbBackup.FormBackup.Restore(String backupFile, CancellationToken cancellationToken)
at MailClient.DbBackup.FormBackup.Restore(CancellationToken cancellationToken)
at MailClient.DbBackup.FormBackup.<>c__DisplayClass27_0.<MainForm_Load>b__0(Object a, DoWorkEventArgs b)
at System.ComponentModel.BackgroundWorker.OnDoWork(DoWorkEventArgs e)
at System.ComponentModel.BackgroundWorker.WorkerThreadStart(Object argument)
System.IO.FileNotFoundException: Could not find file ‘N:\Outlook\backup_202203121844.zip’.
File name: ‘N:\Outlook\backup_202203121844.zip’
at System.IO.FileInfo.get_Length()
at MailClient.DbBackup.FormBackup.Restore(String backupFile, CancellationToken cancellationToken)
at MailClient.DbBackup.FormBackup.Restore(CancellationToken cancellationToken)
at MailClient.DbBackup.FormBackup.<>c__DisplayClass27_0.<MainForm_Load>b__0(Object a, DoWorkEventArgs b)
at System.ComponentModel.BackgroundWorker.OnDoWork(DoWorkEventArgs e)
at System.ComponentModel.BackgroundWorker.WorkerThreadStart(Object argument)
Files in question are there and I can open and unzip/read their contents, but the application will not.
I was able to perform the restore and my data is there, however the issue (that I thought was caused by the bad HDD) imported back into the client. I lost the ability to authenticate to outlook.com and the client would not pull any new emails.
So basically I restored my email files and the problem is back. Is there a place where I can reset the account settings for eM client?
You can allways then go to “Menu / Accounts” in eM Client and remove and re-add your IMAP or Exchange EWS Outlook account via the normal automatic email wizard which will then normally automatically authenticate with the new Microsoft EWS (Exchange servers) otherwise you can manually setup Outlook IMAP or Exchange in Accounts with Other options.
Note: Usually the restore in eM Client with the correct recent backup.zip file will restore all your correct Outlook accounts and just login as mine do if I restore. Could be then the backup eM Client restore you used was possibly corrupted.
Ps When it’s all going again, make a new backup via “Menu / Backup” and copy that a couple times to other drives just in case. You can allways dbl-click the backup.zip files to see what’s in them and screenshot what’s there if any problems in the future with same issue. There is also an automatic period backup you can set to backup where you like via “Menu / Settings / General / Backup” if you don’t like doing manual eM Client backups.
Update: So the email client crashed last night and I didn’t bother to TS as it was late and I wanted to sleep, however… the client did do something that I’ve never seen before when I launched it this morning. It when through an auto repair and integrity check that seemed to have resolved the authentication issue. I am now able to get my emails and send/receive. thanks everyone for your input on this matter!
This is a little late, but I had a very similar issue. In my case I was backing up to a folder I called C:\Users|(my username\EmBackup. On my new laptop that folder didn’t exist and I simply put the backup zip file into Em’s primary directory. I navigated to it when asked “where is the backup file” using Em’s RESTORE function. After a little playing around I figured out that if you’re using the built-in restore function it will ask you where the backup file is BUT unless that backup file is actually in the SAME EXACT directory the original EM Client expected to backup into on the old laptop it will fail with that “Can’t find file” error. It’s a VERY odd thing and it doesn’t seem to be documented anywhere. I really don’t see why it asks where the backup file is but as soon as it starts analyzing it the system immediately disregards it and goes looking for the original backup path. If that exact path doesn’t exist it will fail. I got curious and repeated the process multiple times on multiple laptops. Each time the only way to successfully restore from backup was to ensure the original path was where the backup file lived on the new laptop. Em should fix this or at least make sure it’s well documented in the RESTORE procedure. Hope this helps people
One reason it could fail is if the folder where you placed the zip file is also the actual destination for the database that is being restored. That won’t work and you will get an error about the file can’t be found.
That is why I always recommend using the default locations, but you can have the backup folder anywhere you want and it will work, as long as it is not the same as the database folder.
Your answer about how the product “should work” makes sense, however that was not my experience and as I mentioned I was able to reproduce this on several laptops. Each failed the restore with a “file can’t be found” in the logs when I attempted to restore AND specified the backup zip file WHEN that zip file was in a different file path location relative to the User-Space than it was when created by the original running installation. ie. fully configured and working Em Client with backups being made to C:\Users(my username)\embackup , then putting the zip file into C:\Users(my username)\documents. Then installing a fresh (same version) Em Client, opening FILE>RESTORE, navigating to C:\Users(my username)\documents. The process would start then immediately die with the output log saying "backup (correct backup filename) file not found. I was able to correct this by creating the same file path relative to the User-Space and putting the backup file in the C:\Users(my username)\embackup. I did this on 2 different laptop with the same reproducible results. Bottom line… there’s a bug in the restore feature and I’m betting a lot of users simply don’t know because they aren’t testing the restore feature prior to using the product in production. Simply telling people the feature works as intended isn’t doing anyone any good when it clearly doesn’t based on the amount of posts about it.
there’s a bug in the restore feature and I’m betting a lot of users simply don’t know because they aren’t testing the restore feature prior to using the product in production.
There is no bug in the restore. If you put the backup.zip file “in the same location” as you backed it up on the same computer or new computer, it will restore perfectly as I personally have done many times in eM Client V7, 8 & 9 and with no issues.
You specify that location in “Menu / Settings / General / Backup”.
By default it goes in your profile documents folder.
The amount of posts to the contrary would disagree. Since 80% of anyone trying this (or any other) product won’t likely take the time to post on forum boards and wait for replies you can imagine the real number of people seeing this issue is much grater by multiple factors. Also, as mentioned I was able to reproduce this behavior multiple times on 2 different machines. Both with and without same file path from the user-space forward. The results were exactly as I posted. You can call it “working fine” but I’d call it “poor documentation” or a “bug”. The product seems to absolutely takes into account the original path structure once it starts to read the backup file and if that location is different than it existed on the original machine that made the backup the process dies. In fact the restore procedure documentation is extremely light and zero insight into possible solutions to common errors. Poor documentation is a whole other discussion. At the very least this should be documented in the restore procedure. Either way I’ve figured out the work around and if we move to deployment across our organization it’ll be included in our internal KB so it’s a non-issue on our end.
Can you please try this again, and when it fails, go to Menu > Operations > Log tab and copy the full restore error and post it here. If the error does not include the path, can you please give it as well.
C:\Users(my username)\embackup , then putting the zip file into C:\Users(my username)\documents.
So from what I can see from your post above, you are backing up to one location “embackup” and then trying to restore from a different location “documents” which will not work. The backup and restore location must allways be the same.
The database will restore to the same location where it was when the backup was made, but the backup zip file doesn’t need to be in the same location as it was made to. As long as you select the correct folder where the zip file is, and it is not the same folder as the database, it should work just fine.
the backup zip file doesn’t need to be in the same location as it was made to.
I’ve found if you don’t it doesn’t work.
Also all the forum posts I’ve ever read on restore allways say to restore the backup.zip file you put it in the same location as you initially backed up.
However I will do more testing with restoring the backup.zip from a different location as you say.
Ps I see the eM Client documentation does confirm what you advised about specifying other locations for restoring the backup other than the default “c:\user\yourname\documents/eM Client” location.
Quote: “If you put the backup file in the new device in the same folder structure as the default (…\Documents\eM Client) the restore will find it right away. Otherwise, you’ll need to specify the path where the backup file can be found (in Menu > Settings > General > Backup)”.
Yes, we figured this out the hard was as it doesn’t seem to be documented anywhere in your “restore procedure”. For example. Let’s say someone were backing up to a Dropbox account and the file structure was
C:\Users\Ray\Dropbox\embackup\backup20220613.zip
Then that machine crashed and died and was replaced by a new laptop.
You get a copy of the backup.zip file and place it here on the new laptop:
C:\Users\Ray\Documents\backup20220613.zip
Then you install a fresh (same version) copy of Em Client, open the program and choose:
MENU>FILE>RESTORE
The program will ask where the backup file is located and IF you were to browse to:
C:\Users\Ray\Documents\backup20220613.zip and choose that file the program will start the restore process but then fail with a “backup file backup20220613.zip can not be found”
As you can see from this example Em Client is fully aware the file is called “backup20220613.zip” but will act as if it has no idea where it’s at. This appears to be because once it starts looking at the backup file that was selected it additionally want to now see that backup file in the same backup directory it was originally made in by the old (now dead) laptop.
However, if you were to place that backup file in the same exact spot as it was originally created in, navigate to it during the restore process, and proceed the process will complete without errors.
We confirmed this behavior on 2 different laptops while testing the restore functionality.
We would suggest you update your “restore procedure” to include this bit of advice as it doesn’t appear to be documented anywhere.
Since we’ve figured it out on our end we no longer need assistance with this portion and will continue testing the platform to see if it’s a good fit for us.
No, if you have copied just that file to the default location, it will not ask where it is located. When there is only one file in that folder you will get the confirmation that you want to restore, and then it will begin.
If there are more than one backup zip file in that location, you will not be asked where the file is located. Rather you will get a choice of which file from the default location you want to use.
Or are you using the same database in which you have already changed the backup location?
If you are, then you will need to point to the location if it is different from settings before the choice of files and the restore will begin.
I’m not clear on what you mean by “default location”. If you are referring to C:\Users(username)\AppData\Roaming as the default installation location then no, it still does not work if the original backup file was created in a different location on the old laptop. In fact, in our testing (AS MENTIONED multiple times) if you put the backup file anywhere besides where it was originally created by the old laptop it will fail during the restore. This is starting to be redundant. The fact is that the restore process requires path specific considerations based on where the backup file was originally created. We can argue about it but ultimately this is how it behaved during our testing. You can choose to document it or not. Also, as mentioned since we’ve now identified this flaw and found a suitable work-around it’s a non-issue for us anymore. The only point of this ongoing conversation is to potentially help others. Also, as mentioned there are a lots of posts discussing restore failures where this solution seems applicable.
