Depending on the applicaction using Paradox, sometimes they have their own internal backup routine or scheduler that dumps to a FLAT file. DO that, and have BackupExec pick up that flat file.
It's best you talk to the vendor of the application, what THEY recommend to select and protect when talking backup.
I've used PARADOX in the past with various small accounting packages, and it's not hard to protect, oncec you understand from the vendor whats required to restore the application. Stop with the "There is no agent for this," business.
Stop with the "There is no agent for this," business.
What is wrong with the statement? It correctly says that BE is not able to backup the Paradox database directly. Since Paradox is not longer one of the mainstream dbms, you cannot expect other users to know its capabilities and hence how to get around the problem of BE not having an agent for Paradox.
Does Paradox run at a Service level like Oracle and SQL as the only version I ever encounted (a long time ago) ran at Application/Client level (like MSAccess)
Basically if it runs at Servcie level you can almost ceratinly back it up by stopping the service, however if it runs at Application/Client level then you would have to make sure all users have closed the application down before you can backup the data.
Either way Backup Exec does not have a specific agent for it, hence we do not do any specific testing to certify it and you should be checking with the Paradox vendor, or in their documentation for information on backing up and restoring the data and you should test the process. before you have to use it in anger.
Because the problem with Support at Symantec and other organizations is they only see things in black and white, and to some degree this forum does it too... I think this is a cultural thing for many since much of the support is out of the country, and many support personnel here on this forum, don't always register as a "Symantec Employee."
This is the WRONG approach to providing a solution. The correct answer is that there isn't an agent that is compatible with taking a live/hot Db backup. However, there are flat file backupss that can be done if you can dump the database manually. Or see the application vendor for guidelines on backup options.
Another example is where you want to do DR testing. You want to recover IDR from physical to virtual machines. Whoa, hold on there, that is NOT supported screams the Symantec technician! However, since Vmware's hardware template is based on decades old Intel 440BX and similar chipsets, odds are is that it works just never tested and certified. Hardware detection will work, and only needed things are installing vid and network drivers again via VMware tools. Granted IDR sucks, but it has it's use cases if you want to work through getting it working.
So the issue at hand in many vendor support organizations, this forum by many "trusted advisors," etc is they read off a book, KB article, or what their cubicle mate told them they heard from their cousin's uncle that X is the only way to do this, and any other way is futile or not supported.
Not supported, doesn't work, and not tested are all different things with different meanings. Were here to provide solutions and workarounds.
There are a couple of problems when you don't read off the book.
1) You must know a lot of about the application to properly offer an advice. If we are dealing with SQL Server, then it is easy. I can tell the user to dump the database to a flat file and back this up. I have dealt with Paradox a long time ago but is not conversant with its current capabilities, so I cannot tell him to back it up as a flat file or dump it to a flat file and back this up. Even if I offer him these two methods, can I be sure that they will work when he needs to restore the database?
2) You can advice the user how to get around an unsupported configuration, but at the end of the day, are you going to stand beside him and face the boss when things go wrong?
It is easy to offer advice without having to face the consequences.