Because there is no "final copy", the data is immediately ready to go on the target server, and you can immediately start up the new environment for post cut-over testing, saving hours of your Saturday night. When you get the last user out of the source server and shut down, the final bytes that were changed are transferred to the target server immediately. Since the source server is constantly replicating the data to the target server, the target server will usually be only seconds behind the source, if even that. With Migrate, though, this process is far simplified. Worse still, if something doesn't work, you might have to copy all of the data back to the source server (another few hours lost) and move everyone back to the old environment. The typical cost is an entire Saturday night and a whole bunch of stress in the wee hours of Sunday morning. That takes us to the scary moment of the cut-over to the new system - a time that all system administrators dread! The old way of doing this was pretty simple: you locked users out and shut down the old environment, waited hours for the final data copy to complete, then started up the new environment and tried to remember what changes you had to make to the environment (server name, IP address, config files, etc.) to get it to work. In short order, the recent changes on the source server are mirrored to the target, and the data is once again in sync between the two systems and changes are replicated continuously from that point forward. Once testing has shown that the environment is working, you re-enable the replication from the source environment to the target. If your environment is very complicated, you can even rely on Migrate to make wholesale changes to the target server, bringing in the server name, IP address, and other attributes from the source server to enable full-scale testing. You can even load up a bunch of users for performance testing. You can easily pause the replication process and fire up the application on the target server and run the same application to ensure that everything is working properly. Once a copy of the data is on the new environment, you will probably want to do some testing. This makes it safe for PSQL databases, too! Once the mirroring is complete, replication technology ensures that changes made to the source disks are also made to the target disks, in the exact order in which they occur. There is NO downtime needed to copy the files over, because the data is moved disk block by disk block. When the mirror is complete, continuous replication technology ensures that the data is complete. With a quick and easy setup (usually less than an hour), you can get Migrate working to mirror your source data to the target environment, all while users are still using the production system.
Yes, whether you are doing a complete server migration or just migrating the data for your application to a new platform, Carbonite Migrate can handle all of these situations with ease.
How do you know the new environment is really configured correctly for the application? How do you know if you will have the right performance in the target environment before actually swapping over? How can you manage the downtime involved when you need to copy over many GBs or TBs of data at a time when nobody is using the system, which usually means late nights on a weekend? The problem with most migrations is that you are taking an application environment which works perfectly fine and making wholesale changes to the underlying environment. It doesn't matter whether you are moving to a new physical server, a virtual server, a new operating system, a new database engine version, or a new storage system - the risks involved can be quite unnerving, and one little mistake can ruin your entire weekend! Get more details from the Carbonite web site.Īre you working on a migration project? Server migrations can be one of the most stressful operations for an IT staff to complete. Get our Carbonite Migrate data sheet here. Carbonite Migrate for Actian Zen/PSQL Migrations
0 kommentar(er)
