Issues backing up Epicor???

[LeoJBI]

Hello,

I am continuously experiencing issues backing up Epicor. My question is; Has anyone else experience similar issues and do you have any good remedies for the problems created from the process?

My primary concern is:

I backup our Epicor server & database nightly. However on a regular basis, users will find themselves unable to log onto the system in the morning. I am told it is due to Veeam and the backup process. I have done extensive research regarding snapshots and VSS, yet I have no solution. The problem does not occur after each backup, but it does occur frequently enough (lately it has been at lease once during the week).

Input would be greatly appreciated.

[dellock6]

Waht is Epicor, and what kind of database it uses in the backend???

Luca.

[Davd]

Leo:

We have the exact same problem and worked with Epicor consultants for months trying to solve the issue but without success and Epicor simply gave up and advised us to run file level backups instead. Since we don't do file level backups and use Veeam as the only backup solution, for now we have a post-backup job that reboots the Epicor application server since that’s basically the only way we can get the application back online after it has had its internal "meltdown".

Epicor consultants started off, pointing at Veeam but the problem isn't with Veeam since I can reproduce the exact same issue when performing a regular snapshot in vCenter. After extensive investigations we identified that the “Epicor-internal meltdown” was caused in the Progress OpenEdge database that Epicor-application uses for internal tasks. In our environment Epicor is using Microsoft SQL for our company data which in itself works fine but since Epicor application also uses a Progress OpenEdge database for some application-internal tasks and that’s what’s causing the issue. Once we narrowed it down to this, Epicor said that since Progress is not built by Epicor (even though it’s included in the Epicor installation and an integrated part of Epicor application and you would hope that they would take some kind of responsibility) they don’t want to take any responsibility of it and therefore they closed the case with comment that “perhaps Progress OpenEdge database will address this issue in a future update”. And reply from Progress support was that “We do not recommend to use a third-party backup utility to perform a live backup of OpenEdge database files.”.

So we are also interested to find out if anybody has a better way of dealing with this issue.


Luca:
Epicor is an ERP system

[foggy]

You could probably use pre-freeze/post-thaw scripts to quiesce the Progress database before backup and starting it after the VM snapshot is taken (apparently, there is no VSS writer for it).

[veremin]

Since VMware tools quiescence doesn’t work well for MS SQL, you can probably implement the same algorithm here:

• Freeze the Progress databases.
• Start a given VB&R Job, with or without application-aware image processing.
• Once the snapshot of VM is taken, unfreeze the Progress databases.

Hope this helps.
Thanks.

[LeoJBI]

Thanks everyone,

I had a question regarding the Freeze / Thaw process. Is this something that I need to manually configure? Within Veeam?

I am on a Windows environment. Therefore, I believe that enabling the VSS writer performs the Freeze / Thaw process without my intervention?

[veremin]

Therefore, I believe that enabling the VSS writer performs the Freeze / Thaw process without my intervention?

Yes, of course.

However, the problem is that in contrast to SQL databases Progress OpenEdge ones can’t be frozen via VSS writer. Moreover, you can’t utilize VMware Tools Quiescence since it’s not recommended to use such an option while backing up/replicating MS SQL server.

From my perspective, the only potential workaround you have is to write a custom script that will freeze corresponding Progress OpenEdge databases, start a given job (which, in its turn, will prepare SQL databases) and once the snapshot is taken, unfreeze Progress OpenEdge databases.

The auditorial part responsible for checking snaphost status has been already written, thus, the only thing you have to do it to put the freeze/unfreeze part to the existing script.

Hope this helps.
Thanks.

[LeoJBI]

Thanks v.Eremin,

not recommended to use such an option while backing up/replicating MS SQL server

Thanks,

My Epicor admin just came back from the Epicor Conference and was told that an alternative option until version 10 (which will be 100% SQL) is released next year is to:

Backup SQL to another drive
Than backup that off-line drive. A snapshot of the off-line copy should not create any issues

My concern is in order to accomplish this, I need to resort to using Backup Exec to create a backup of our SQL server. Which had problems that took us in the direction of using Veeam in the first place.

I'm going in circles…

only potential workaround you have is to write a custom script...

What has been the outcome of using a custom script? Has it worked for you?

[veremin]

What has been the outcome of using a custom script? Has it worked for you?

In fact, it’s nothing but a guess.

Based on the answer provided by David Hirsman which quoted Epicor support engineer, the underlying problem of backing up/replicating Epicor was that Progress OpenEdge databases were not successfully quiesced (in contrast, to SQL).

So, I’ve decided to propose you a workaround that combines two quiescing approach (AAIP for SQL, pre-freeze/post-thaw script for OpenEdge) and that might do the trick.

Thanks.

[Davd]

I haven't tried the custom script since our problem with Epicor applications server/OpenEdge mainly occurs during snapshot commitment. Its in the final part of snapshot commitment wher we loose 1-2 pings on the VM that Epicor application server throws in the towel and has its internal crash. So a possible workaround for us would be to have a pre-job script that stops Epicor application server service and then a post-job script that launchs it again but since our organization (at least for now) is ok with reboot, we are continuing with that.

But thanks for the suggested workarounds.

[dellock6]

David, maybe this can relax you a bit, we did the same for a customer with Oracle 10 on Windows some years ago, that was crashing everyday after snapshot commit. Since VSS support arrived only on 11g version, we scheduled a reboot after every backup, otherwise the database was not working after the backup.

Luca.