Pack & Go creates corrupt backup packages

[Steffen]

Hi,
recently, Pack & Go started to "successfully" produce backups that are reported as defect when I verify them with Pack & Go. What could be the reason and how can it be avoided?

Regards,
Steffen

[Mario]

I have no idea. Never had a report like this.
Please include the log files produced by Pack & Go (see the Pack & Go help for details) in your report.
It is even unclear at this time what defect Pack & Go found when restoring the package. The log files will tell us more. Please ZIP before attaching, thanks.

Pack and go calculates checksums for each file in the package. After copying the file, it reads the file again and compares the checksum produced during the read with the checksum stored int he package. If these match, the write operation is considered good and Pack & Go continues with the next file.

If Pack & Go restores or verifies a package, it performs the same operation. If copies the file and calculates a checksum during that step. If the checksum does not match what's in the package, the copy operation failed to produce the right files, or the package has been damaged.

[Steffen]

Sorry to be to unspecific! I have attached the log files.

[attachment deleted by admin]

[Joe Austin]

Seeing the same thing here on my most recent backup package.

Backups on Oct30 and Nov01 verify, backup on 1103 fails.   All three were reported successful at the time they were generated.

[attachment deleted by admin]

[Joe Austin]

Just created another successful backup after successfully diagnosing both databases included in the backup.

Verification of the second database within this latest backup package fails as well.

[attachment deleted by admin]

[Mario]

I have used Pack & Go successfully to create three backups on two machines. I used a new database, and two existing databases (10,000 files and 50,000 files). Backup, Restore & Verify without problems on Windows 7 and Windows 10.

If you run P&G with the same (new) database again, does it fail again?
If so, send me the database. Perhaps this is something caused by a specific size or checkum-sum perhaps.

[Joe Austin]

I am not sure what you mean by "same (new) database".  I P&G two databases.  Running P&G again on these would be the 'same', but not 'new'.  I have already done this.

I have run P&G on my two databases two consecutive times now with verification failures indicating failure on the smaller of the two db's both times.   My last two packages fail, the two before that do not.   The last four packages are as far back as I have tested verification.

Do you need both databases that are P&G'ed together?

[Mario]

We need to identify a set of files (database + settings db + other files) which causes this problem. I have no chance to finding this otherwise. My tests worked without a problem, I tried a couple of other scenarios in the mean time.

All I can say now is that the verification of the database fails, which means that the checksum of the file after unpacking does not match the checksum calculated during packing.

Does the database work? I mean can you open it in IMatch and run a diagnosis with 0 warnings and errors? If this is the case, the checksum is either calculated wrong during the packing, the un-packing or the file is not identical, but in a place where it does not matter. Without a file set which produces this effect reliably, finding the cause of this will be almost impossible...

[Joe Austin]

Yes, both db's work , and both can go through a diagnosis with no reported problems.  See description above.

The P&G backups report no problems.

The verification of the package errors out on the smaller of the two db's.

This has happened on two consecutive backup packages, but does not happen on the two previous packages.

I am concerned that this makes the Imatch P&G backups unreliable.  If two db's are backup up in one package, and
I match cannot read one of the db's is the other still recoverable?  What do you need to diagnose this?

[Mario]

As I said above, I need a set of files which cause this problem.
When you create a package and the verify reports a problem, and you can repeat that multiple times, I would need all the files in that package, DB and all. If it also fails here when I P&G the same files, we have a change to find this.
Does only the Verify fail or does the Restore also fail?


This must be something specific, because there are no other reports. And it works here for all tests.

I am concerned that this makes the Imatch P&G backups unreliable.  If two db's are backup up in one package, and

Pack & Go is not a backup software. It's meant to quickly move IMatch settings, presets and databases from one PC to another. If you only rely on Pack & Go backups, you should change your workflow.

I use P&G to transfer databases and settings between two computers, a tablet and several virtualized Windows installations. So far, never a problem.

[Joe Austin]

As I said above, I need a set of files which cause this problem.
When you create a package and the verify reports a problem, and you can repeat that multiple times, I would need all the files in that package, DB and all.

I do not know what comprises the set of files that you need.   Are they the files described in the "Package Contents" of the "Protocol" tab in P&G when you verify a package?

Does only the Verify fail or does the Restore also fail?

I am not going to attempt a restore with a suspect package.

This must be something specific, because there are no other reports.

Well, there are two reports.

Pack & Go is not a backup software. 

I only use term 'backup' because Imatch does (shutdown menu).

[Mario]

Well, there are two reports.

Yes. But also more than 2 users who use Pack & Go frequently, including myself. If this would be a more general problem, I would expect more reports. And since I used pack & go yesterday with five databases on three different computers without any problem, this is nothing that happens on all computers.

I am not going to attempt a restore with a suspect package.

You can restore into a different folder. You don't need to replace your original files.
If you are unsure, make sure your IMatch database and the Documents and Settings folder is included in your standard daily backup.

I would need all the files in the package. The folders which are packed are reported in the protocol. You can open the protocol in Notepad by clicking on the link at the top of the protocol. The folders are listed right at the top.

It could work if you just upload the package to my server so I can unpack it here.
But that would prevent me from testing the packing procedure with your files, so it would be better if you can just ZIP the folders and DB and then upload everything. Then I can run the pack and the verify / restore here and see what's wrong.

[Joe Austin]

I have created a zip which I believe contains all of the files described by the protocol.   I will try to ftp it, but it is 25gb in size, 90% of which is the preview cache.

As an experiment, I removed the Imatch_personals database (the one that P&G describes as causing the failure) from the P&G-Pack list, re-ran P&G-Pack only on the larger database, created a new package and was successfully able verify that package.

[Mario]

25 GB cannot be uploaded to my FTP. It has a 1.5 GB limit.
You can keep the preview cache out if things brings it down to maybe 1 GB. Maybe I can repro the problem anyway.

[Joe Austin]

I can get it down to 2gb by removing the preview cache.

I can get it down to .3gb by removing he larger of the two databases (the db that packed and verified on its own).

I'll remove the cache and the larger db from the zip,  then I can send the large db separately if needed.

[Mario]

This has been solved with topic https://www.photools.com/community/index.php?topic=5046.0