DataCare 9.1A (110324)

Everything has been working great or so I thought until I needed to restore this morning from a Back Up and I found out that the back up is corrupt. Last night DataCare created a a file called DCB1759.ZIP and a second file called DCB1759.Z01. I cannot open either file. The .ZIP file says it is invalid or corrupt.

It did the same thing the night before and the .ZIP file is also corrupt.

The 3 days before that their is only a .ZIP file and no second .Z01 file and they are all working perfect. I can open the .ZIP files.

Why is DataCare creating a second .Z01 file? And why are my .ZIP files corrupt?

I needed to restore this morning since someone has crashed ledger.

Backup of:
Backup file: C:\Backup\DCB1759.ZIP
Backing up data at: I:\data\ with extension: DAT
Backing up all files in data directory
Backup started at: 2011.06.01 23:30 by Susan Tennier
Backup completed ... OK
Backup finished at: 2011.06.01 23:36

Hi Susan,

Is it possible that DataCare is running from two workstations at the same time? I remember that at one point you were running it on the server and mentioned later that you had moved it to a workstation.

I disabled the scheduled task on the server when I setup the job to run on my workstation. I also re-directed the back up to C:\backup on my workstation.

I've attached a screen shot.

Thankfully I was able to restore from another back up system that ran last night.

Also, there is only one job in DataCare History per day.

I have always thought the Z01 files were temporary files used in creation of he zip files. One time I had Z01 up to Z14. Anytime I have had the Z01 (temporary files)I have been able to find another server backup or action that was overlapping the Datacare backup.

David

The zip files can be large. Make sure you have plenty of room on the storage drive. DataCare can also limit the number of stored backups.

The last 2 nights I ran Toolkit before DataCare ran on the scheduled task. I wonder if Toolkit is closing all the files correctly?

The strange thing is that DataCare History didn't report any error with the back up.

I'll test it tonight when everyone is off the system.

The drive I'm backing up to is 150 GB and only half full.

Bob, what do you mean by DataCare can limit the number of stored back ups? Should I delete some history?

In the DataCare company profile, you can set it to retain x backups. There's an audit trail of Toolkit changes, so review that report. It's unlikely that files were left open, but you should consider competing processes. ie. running the Toolkit and Datacare as scheduled tasks. Both products should be looking for exclusive use of the Adagio dataaset. With Datacare, exclusivity is optional.

Susan:

Thanks for confirming that this problem is still occurring. I've known about it for some time but have been waiting for the resent upgrade to see if it would go away (there has been so many problems with DataCare the last 12 months that we stopped reporting and investigating them).

I can confirm that it only happens at large sites. The Z01 is the temp file and if it still exists then the process of creating the ZIP file was interupted. The problem is what is interupting this backup as it is very random.

Susan:
If a ZIP file is too large, the resulting files would be named .ZIP then .Z01, Z02 etc. I don't know the threshold size but maybe you hit it in the past few days.

I haven't encountered this myself but here's a link where someone says that WINZIP can handle the files.

ZIP Discussion

Hi Susan,

We have duplicated the behaviour you saw (with multiple .Znn files) by having a competing process running on the files when DataCare tried to back them up. Our "competing process" was a large GridView View on a composite table, but any one will do - a ToolKit operation, another backup. You get the idea. Can you let us know what processesyou run overnight in addition to your DataCare Job?

Thanks

Hi Andrew,

The only other process I can think of is 3X Back Up that our IT people are testing on our system. It looks like it's scheduled to start running at 8:00 pm. Maybe this is the culprit? I'll try scheduling DataCare Backup to run at 7:00 pm for now so it will finish before 3X Back Up is scheduled to start. If it works I'll rearrange the schedule to avoid having them run together.

As a test just now, I tried DataCare Backup while 3X was running and it resulted in a corrupt backup. Then I paused 3X and ran DataCare Backup again and it resulted in a good backup.

Do you know how long it is taking DataCare to backup your data? You should try and give a 50% margin for error when scheduling these two tasks.

The Backup portion of DataCare takes about 7-10 minutes. The integrity check that follows takes another 7-10 minutes. The total job approx 20 minutes.

You're good to go then.

Andrew:

We have been very careful to make sure that our clients are not running anything else concurrently with DataCare. As DataCare backs up the data first and then does the DIC, is it possible that the zip file is still being built (as winzip creates a temp file first and then writes it to the real zip file) when the DIC starts, resulting in this issue?

Nope.

I will keep an eye on it now that I am aware of the problem. If we get any corrupt backups when there are no other processes running, I will report back. My DataCare was set to only keep 5 back ups so I couldn't look back any further. I've changed it now to keep 25.

Update:

DataCare has been working great now that our other back up job has been scheduled at a different non-conflicting time. Last night someone decided to use Adagio at the time that DataCare was scheduled to run.

The result was this:

DCB1775.ZIP
DCB1775.Z01
DCB1775.Z02
DCB1775.Z03
DCB1775.Z04
DCB1775.Z05
DCB1775.Z06
DCB1775.Z07
DCB1775.Z08
DCB1775.Z09
DCB1775.Z10

This zip file is corrupt and the backup is therefore useless.

The problem is that DataCare reports this as: "Backup completed ... OK and, "Data integrity check was complete with no errors".

Shouldn't DataCare report this as a failure? If someone doesn't check the back up every day, we'll never know whether we have a good back up or not.

Hi Susan:
In Datacare's Company Profile settings there is an option called "Backup error considered a fail". It's located on the "Job defaults" tab. What is your setting?

It's an option because Datacare's foremost job is to check the integrity of the accounting data. The backup process is a secondary function. This option allows the user to flag a backup failure if they wish.

Hi Bruce,

"Backup error considered a fail" is checked. The problem is that DataCare doesn't recognize that there is a back up error.

Hi Susan,

It's my understanding that DataCare would be looking for exclusive access to your Adagio dataset during the backup and data check. That depends on whether the option is checked on the job, 'require exclusive access'. Do your DC jobs require exclusive access? Even without exclusive access, the job should have flagged it as an error. I don't think the creation of these .Z## files are typical. The backup procedure can normally detect when a file is open by some user.

Hi Bob,

"Require Exclusive Access" is checked. I agree, the job should have been flagged as an error. The problem is that it doesn't. This only occurs when there is another process running at the same time as the back up is running which normally is not the case, however, if it happens, DataCare should report an error so that we know our back up failed.

Hi Susan,

Was the user actually in Adagio? If you had "Require Exclusive Access" enabled, then the DataCare job should not have been able to start. Or, if the DataCare job had already started, then the user should not have been able to start an Adagio module.

I agree with Andrew's assessment. Perhaps their backup includes more than Adagio data. It's possible with the latest version.

I know that a user went into Adagio yesterday evening but I can't confirm if they went in at exactly at the same time that the back up and integrity check were running. I only assumed that because the back up failed and nothing else was running that I'm aware of. The user was not blocked when they went into Adagio. They were able to use Adagio normally, without any problems.

Whatever the reason the back up failed, shouldn't DataCare report it as an error?

Hi Susan,

Under normal circumstances, it does report the error. I just tried it. I also tried this scenario...created an extra GL data file, opened it with an editor, so Adagio is not aware of it's use. The backup excluded that file, reported the error and created the zip file without that file. My tests were performed on a local drive, with a small dataset and Windows 7. I'm sure your configuration and circumstance is quite different.

Bob:

This issue was occurring in DC v8.1. It is caused by something running. The problem is what is running. For us this only occurs at sites with large databases. My theory, as reported earlier in this issue, is unchanged. WinZip creates a temp file first and then writes it to the DC####.zip file. My theory is that sometimes this is interupted by DC itself starting the next step because it fails to see that the write out from the temp file is still in progress.