Page 1 of 1

Migrate projects, users, and resources to DR environment

Posted: Wed Aug 22, 2012 2:09 pm
by DanSelf
We are in the process of building out a new Go Anywhere Director and Services environment at our disaster recovery datacenter and would like to know the easiest way to migrate all of the settings that are in our primary production environment to the new environment. The base OS is Red Hat installed on VMware. I have tried
1) Cloning the existing virtual machine that is used for production
2) Attempting to do a backup and restore using the built in GA utilities.

Both methods offered little success. The hostname, IP address are different for the DR environment. We have licensed the DR instances completely and would like to have them as a warm standby and always available.
One final requirement is that we would like to automate this sync process on a daily or weekly basis.
Suggestions?

Re: Migrate projects, users, and resources to DR environment

Posted: Wed Aug 29, 2012 2:06 pm
by ngeorgieff
We are replicating our Tier1 LUNs with DataDomain in real time to our DRDC but you can use rsync to keep GoAnywhere up2date.

Re: Migrate projects, users, and resources to DR environment

Posted: Thu Aug 29, 2013 7:36 am
by robliberti
I was about to ask a similar question.

In my case, I am about to enable the feature to disable users after 3 months of inactivity on my production system. How can I keep the user's enabled/disabled status in synch with DR?

Re: Migrate projects, users, and resources to DR environment

Posted: Thu Aug 29, 2013 8:27 am
by Support_Rick
Rob,

There is really only 2 ways to maintain this Sync'd status.

1- Externalize your database. If you externalize your database, then both the Prod and D/R box will use the same data during Production and/or Disaster Recovery Use. Thus, allowing you to maintain the same status for each user on each system. This would be easier using Data Replication for the database used between the Production site and the D/R site, but it's not mandatory. The key here is that only 1 GAService can be active at a time, otherwise ... database integrity could be compromised.

2- On a nightly basis, after internal database backup, you could FTP/Copy the latest zip file from your Production System to your D/R system and have the Database Replaced on the D/R system. This means that if your system needs to be switched to the D/R Server, it would be as of the last restore not as of last use change.

A cluster license would allow you to handle this situation easily, but keep in mind ... a DBA is needed for any of your External Database maintenance and replication.

Some planning is necessary, but the end result is very obtainable.

Re: Migrate projects, users, and resources to DR environment

Posted: Thu Aug 29, 2013 2:08 pm
by robliberti
I would prefe to externalize the database, but that is not an option for me at present.

In terms of the solution, I know exactly where the backup zip file is, but I don't know how to restore it. Would I have to use "Switch Database"? I tried to read the man page but I didn't see where you would point at that zip file. Also, would there be a way to automate such a restore or is it all interactive using the GUI? Thanks!

Re: Migrate projects, users, and resources to DR environment

Posted: Thu Aug 29, 2013 3:58 pm
by Support_Rick
Rob,

No "switch database" is needed.

You will have a Zip file available to you from the Internal (scheduled) backup. Same folder as the Database, but ... in the /Backups Folder.

It's just like restoring a Zipfile that you made for any other backup. Check the Zipfile for the data and compare it to what you have in Production. Then, when you get ready to restore on your D/R Server, remove the same folder (ie, the GoAnywhere Derby Database) and restore the one from the Zipfile into it's place.

Just make sure the D/R GoAnywhere Service is inactive!

I just got through training your people on utilizing GoAnywhere Director ... Yes, it can be automated!

Go forth and Script!! Make me proud!! :)

Re: Migrate projects, users, and resources to DR environment

Posted: Fri Sep 27, 2013 9:05 am
by Rocky
Rob,
We have had great success with Mimix. You might want to contact Vision solutions (or one of their competitors) and discuss their replication products to see what would fit your particular needs. We replicate our entire GoAnywhere Director product with Mimix to our DR system.

We don't have GoAnywhere active on the DR system normally. But so far every time I've brought it up on the DR system for a test, it works perfectly. We use the Derby database. And when we upgrade GoAnywhere on production, the upgrade is sent to the DR system without any effort at all

Bear in mind that setting the product in the beginning is complex, and the products can be pricey. But once it's done you have everything you need being sent over in real time. So if you lose your main data center unexpectedly you'll have everything you need to recover. You can also configure for other software and databases to be replicated as well.

- Roc

Re: Migrate projects, users, and resources to DR environment

Posted: Fri Jan 24, 2014 12:47 am
by bothunbr
Rob, see my post about clustering. You could setup a gluster filesystem and get your DR nodes up to date the second a file is updated. It's basically copy on write to other nodes in the cluster.

howto-services-director-ha-config-for-l ... ensuse-477

Re: Migrate projects, users, and resources to DR environment

Posted: Fri May 20, 2016 10:48 am
by Rocky
We have just migrated to GA/MFT 5.2.3. We use Mimix to replicate GA for Disaster Recovery. I believe that MFT is different enough to merit a white paper from Linoma R&D on how to do real time replication of GoAnywhere. That is what to replicate and what not to replicate; to our target DR system. It doesn't need to be specific to Mimix.

Can someone at Linoma who knows the GA/MFT folder paths take out the 15 minutes to write up something that just says copy these files/folders and don't copy these files/folders? That will give us the safety of replication while avoiding the chances we would do something to mess up GA/MFT.

Whatever can be done will be deeply appreciated. Thanks.

- Roc