Restore from Pack & Go seems to have database corruption

[CollieDog]

Hi,

My main IMatch database became corrupted for some reason- possibly during a sudden power failure earlier this week.
When I started IMatch after the power came back on, a message appeared saying the database had errors and I ran the diagnostic. It reported the database suffered physical damage and suggested I restore from a backup. I decided to first try running the "Repair Database" tool, but it did not succeed and the error reappeared after running repair.

Luckily, I had made a backup using Pack & Go prior to this. I ran P&G and opened the backup and navigated to the IMatch Database.imd5 file that was located inside IMatch5 2019 database/IMatch_20181201/PHOTO - VIDEO CATALOGUES/IMATCH5 DATABASE/.

Thankfully, it seems to run perfectly. I was not sure what to do about the strange file structure package that comes along with the P&G recovery. What should I do with ProgramData, Users and the other appended folders?

While its great that the restored database is usable, today when I tried to run a backup again after doing some work, the backup failed with a log message saying there is some type of corruption. What is going on? I will send the log file, but I'm not sure where it is located.

Could someone out there, perhaps Mario, advise me on how to proceed to get my database back running with a normal files so that it can be backed up?
I am now implementing proper backup protocols for my entire system.

On a side note, I'm pleased to report that IMatch 2017 runs very well in a Win10 virtual machine inside Manjaro Linux. The database catalogues are stored on SSD drives formatted in EXT4, and the photo images are all stored on Seagate NAS grade 4tb harddrives formatted in EXT4. So far, its been running very well.

[Mario]

Note that Pack & Go is not a backup software. It is designed for users who work with IMatch on multiple computers.

Here is the help topic for Pack & Go

Which explains where the log files are stored, what to do with the contents of the package during restore etc. I cannot repeat all that information here.

The Protocol File In the same folder you'll also find the other Pack & Go log files (and the IMatch log files).

Pack & Go by default (unless you disable it) performs a database diagnosis and only completes if this diagnosis is OK. This is to prevent damaged databases from being packed.
If your database becomes damaged after restore, something in your system is fishy.

Restore the database again and make sure that you actually open the restored database, not the original, damaged version (we had that in the past already, where a user restored the database to folder B but tried to work with the old database in folder A all the time).

Open the restored database and run a database diagnosis immediately. It is very unlikely that a database becomes corrupt in Pack & Go packages, because they are protected by check sums and P&G would tell you if the package is damaged. It is also unlikely that a damaged database is stored by Pack & Go, unless you disable the diagnosis step.

I'm pleased to report that IMatch 2017 runs very well in a Win10 virtual machine inside Manjaro Linux.

This could be the reason for trouble. Virtual environment, (simulated) network protocols to access the database and images. A lot of potential for damage. Do you run database diagnosis regularly? IMatch prompts you by default once a week, but in  potentially unstable virtual environment  daily database checks, at least during the first couple of weeks, are advised.

I run IMatch on virtual systems in the (Azure) cloud for testing and installer validation in many configurations and have not seen any problems. Your mileage may vary.

I am now implementing proper backup protocols for my entire system.

Much too late.

[CollieDog]

Thank you for your reply Mario,

For some reason, I thought IMatch included a backup protocol in addition to Pack & Go. I will review the help file for P&G again and see if I can figure out how to put everything back where it should go.

Much too late.

Your "much too late" comment regarding my backup protocols is valid, but only in relation to my IMatch database. I neglected to familiarize myself with IMatch's backup requirements properly. I had been relying too much on P&G and that was negligent.

I'm not very proficient with computer systems compared to IT tech guys, but have done quite well keeping my 25 TB of data backed up over the last 8 years using a combination of onsite and offsite/offline storage. I'm revising my current setup to convert several RAID 5 drives to JBOD. I had a RAID failure a while back and was not pleased with the results.

I've been running IMatch in a Win10 virtual machine for over a year. For the most part, it has been running quite well, and recently, especially well after converting NTFS format drives to EXT4. Though running IMatch in a VM may not be ideal, like many who chose to not use Windows, this is a good solution. I'll just be careful to follow your advice to do regular database checks, implement a proper weekly backup of my IMatch database, and run P&G after all major changes I do to my collection.

Now I'd better attend to fixing that database. Thanks again!