Backup and restore solutions

[MPalicki]

Need to hear what sort of solution others are using, and what sort of succes you've had.

We're running OSM and MM 13.20. We've been on the same backup solution for many years. It's pretty much your typical daily incremental/weekly full tape backup system.

But we've never been able to successfully retore any OSM parts/assemblies. After months (really years) of laying the groundwork, I think I have all the necessary pieces in place. I have file server logging turned on. I have a system that archives each day's file server log, so that I can search any log file for the physname for the document I need. Of course, if it's an assembly, I have to find the physname for the assembly and all children.

To date, we've attempted numerous times and never once had success. Often I think it was because OSM generates a new physname with every save operation. Other times perhaps we didn't get all the children. Other times even though I was certain I was looking up the correct physname, we simply could not find the physical file on our backups.

It just seems that with CoCreate's file structure and saving methodology, it's downright impossible to use a traditional backup/restore solution. Someone prove me wrong. Someone show me a method that works - PLEASE!

[MPalicki]

Ok, so what I am to presume is that of all the CoCreate users worldwide, there is no one who has successfully implemented any sort of backup/restore logic for OSM models? Well that's very comforting


:eek: :eek: :eek: :eek: :eek:

[May Kung]

Well, our network admin doesn't visit this site, so I don't have the details of exactly how we keep stuff backed up. The way we currently run things, we can do a rollback of our database. We haven't used it yet, since it would rollback everyone's work to the backup date, but it's not meant for recovering "oops, I accidentally deleted that model."

The last time I asked, our admin explained that while Oracle allows data mining and letting us dig back in time for a particular missing file, Model Manager isn't set up to do this, hence having to rollback.

[MPalicki]

Well, our network admin doesn't visit this site, so I don't have the details of exactly how we keep stuff backed up. The way we currently run things, we can do a rollback of our database. We haven't used it yet, since it would rollback everyone's work to the backup date, but it's not meant for recovering "oops, I accidentally deleted that model."

The last time I asked, our admin explained that while Oracle allows data mining and letting us dig back in time for a particular missing file, Model Manager isn't set up to do this, hence having to rollback.

Thanks, this confirms what I've found. We can rollback the entire database/storage area to a point in time, but if an assembly gets irreparably corrupted and needs to be recovered from a previous date, well, let's just say it's faster to create the second time, eh?

[May Kung]

One way to minimize the risk is to be generous with rolling revisions in Model Manager for files. A lot of users here continuously Overwrite, so if there's a bad save somewhere or the file gets corrupted or the user didn't mean to Overwrite, there is no going back.

Here, I encourage folks to save multiple revisions. Every time I make a significant change to my model or 2D, I save a new minor revision. It's almost file snapshots we use on our filer for non-CAD files.

[Steve]

I've run into this kind of problem with other CAD software packages, too. Generally, the problem is when they use a PDM system that is merely seen by the native OS as a "database", you are backing up the DATABASE and the system is oblivious to what is in that database. I agree it is difficult and restoring an entire database is usually not an option for restoring one broken file - usually the file is not discovered to be broken until some time later after many many other files have been added to the database, and you cannot throw away all the new data by rolling back the database just to get the needed backup.

I agree with May's suggestion - allow users to be generous with revisions, so that they can "roll back" themselves to a previous version of a saved part if they need to.

There really needs to be a custom CAD software backup and restore tool.

Steve

[MikeP]

We use a script to export the database as night. Then we backup the export and the file storage area. When we need to restore, we get these 2 items for the proper tape backup and import them into another "restore" MM Server.

To export DB, Put the following into a batch script.

_______Batch Script Syntax____________________

exp DBusername/DBpassword log=c:\LogFileLocation\dbexp.log file=C:\ExportFileLocation\dbexp.dmp compress=Y full=n consistent=Y owner=medmgr
___________________________

TO RESTORE

Copy the dbexp.dmp file from tape backup to restore Server
Copy “File Storage” from tape backup to the same location on restore server
Oracle Import: This method uses Oracle’s SQL Plus tool to remove the user “medmgr” and recreate it before actually importing the database backup.
Model Manager uses the following 5 services.
OracleDBConsoleWM
Oracle OraDB10g_home1TNSListener
OracleServiceWM
CoCreate Database Server
CoCreate File Server
Start only the first 3 (Oracle) Services on restore server
The last 2 (CoCreate) services should be stopped

Do the following from restore server
1. Click Start; All Programs; Oracle – OraDb10g_hom1; Application Development; SQL Plus
2. Login Username: ??? Password: ???
3. From the prompt, type the following
4. SQL> drop user medmgr cascade;
5. SQL> commit;
6. SQL> create user medmgr identified by medmgr;
7. SQL> grant connect,dba,resource to medmgr identified by medmgr;
8. SQL> commit;
9. SQL> exit;
10. Run the following batch file to import the database:

_________Batch script syntax_________________

imp DBusername/DBpassword BUFFER=65536 FILE=dbexp.dmp INDEXES=Y full=y ROWS=Y log=dbimp.log
___________________________
11. Start the 2 CoCreate Services.

Connect MM to restore server to access recovered data.
Disconnect and connect to live MM server and save back.

Ya, It's a clunky way, and time consuming when you have a large DB, but it works. Hope this helps someone.

[jkramer]

Hi,

I'm not an IT specialist, but another suggestion is to run the MM server on a VMWare server. So, the complete system (hardware, OS & software) is just one disk image.
The database server is stopped each night, and the disk image is being backuped. If the server would crash in any way, you'd just take any other server, copy the diks image over there, and be up and running in no time.
Kind regards,
Jaap

[MikeP]

If you're running Oracle, it's not supported in a virtual enviorment.

[jkramer]

Hi,

yes, that seems to be a problem; I believe there are more large vendors who don't support VMware officially. Even CoCreate, I think??!!

Kind regards,
Jaap

[ludw]

Restoring database is just one point. We should be able to restore the complete system made of database and vault and to keep them well synchronized. If not you may have:
- db docs that point to missing files
- orphan files on vault that you will be never ble to access to
Model Manager implement a huge number of files associated to the data structure even without CAD (std and custom searches, thumbnails, BOM checkpoints, etc.). It could be a nightmare when async db and vault.
An embedded CoCreate save&restore would be fine.

[acasoli]

If you have Oracle 10g Enterprise Edition, you can use "flashback" with a huge time for undo (and big space on storage system); default is 15 minutes... too short for your purpose...