anyone used it before ?
if i restore from an mksysb backup, can I use the utility on Progress DB to restore the DB.
or can i do an savevg (Progress DB is on another vg) and then use restvg to restore it ?
normally what is the common ways to backup an DB, so that it can be restore, if there is any problem eg power outage, system failure.
previously my company outsource everything to an vendor.
and the vendor will do everything for us including Disaster Recovery Testing.
now my company take back all, and we have a problem, there was no proper handling over and taking over of documentations/processes/procedures.
now we will have to do everything from scratch including coming up with an Disaster Recovery Procedure at another site of an vendor.
As it is, we use it. My colleague did most of the work including it so i am by no means an expert, but i can tell you that it works well and without any problems.
These are questions which are completely unrelated to each other:
An mksysb image is an image of the rootvg plus some code to boot from it and restore it to a "naked" system. Because the rootvg contains all the really vital filesystems (/usr , / , /var , ...) you can use this to clone a system, either for disaster recovery or to create a test envirnment out of a production environment.
To make this process as easy and robust as possible you should NOT have any application parts (neither binaries nor data) in the rootvg. You create separate VGs for this and group these logically. For instance: a system with two applications, APP1 and APP2:
First (most simple) layout:
rootvg: system and system data
app1vg: all binaries and data for APP1
app2vg: all binaries and data for APP2
Second (more complex):
rootvg: system and system data
app1bvg: all binaries APP1
app1d1vg: data part 1 for APP1
app1d2vg: data part 2 for APP1
...
app2vg: all binaries and data for APP2
...and so on. A reason to separate data and binaries for an application would be to create different ttypes of backups: the applications data are supposed to change permanently so you need backups often to stay current. The binaries change not at all (or rarely: only with release changes) so you take one (long-term) backup and be done. To have more than one backup generation for unchanging data is just a waste of resources.
Now a savevg is the backup of one VG. Its form is basically the same as an mksysb but you cannot boot from it and all the other mechanics to restore it to bare iron are removed. You need to have a running system to restore it.
The most crucial thing you have to do for backups is not to implement them: it is the planning! In this thread i wrote a lengthy article about what to do and what to consider, which you might want to read.
Regarding your DB: the only way to back it up is to shut it down (so data cannot be changed during taking the backup), then take the backup and then restart it. This is called a "cold backup".
Some DBs (Oracle for instance) have provisions to do a "hot backup": you switch the DB into a special mode and take an (inconsistent) file backup along with the archive logs. For restore you first restore the inconsistent file backup, then start the database software in a certain mode and reapply the archive logs taken during the backup making the backed up data consistent again.