How to Migrate Collection-Master Across Servers
Using a Physical Storage Device
Goal
The goal of this document is to aid in migrating between servers when running Collection-Master.
Help Manual
The Collection-Master has comprehensive documentation under Help > Troubleshooting > Windows Server Migration for Client-Server. For convenience purposes, the information has been copied here as well. Carefully read all of the documentation before starting.
Transferring the Data
It is critically important that the method of transferring the data is as reliable as possible. DO NOT Use Windows drag and drop. The built-in drag and drop is notoriously unreliable and is likely to result in incomplete or damaged information during the transfer.
Restoring from your backup software is reliable and may be your best option.
Windows has a built-in utility called RoboCopy that offers high performance and reliability.
It is best to “pull the data” from the source server to a local drive on the destination server. When “pushing the data,” Windows will sometimes overflow the cache and lose some data.
A Sample RoboCopy Command:
robocopy \\server1\drive_F\clsinc f:\clsinc /mir /mt=16
- /mir = Mirror the files and folders from the source folder, adding and deleting files and folder as necessary.
- /mt = Multi-Threaded mt/=16 will create 16 parallel.
- Be aware that you will completely overwrite the destination information, so care must be taken. As an example, if you accidentally reverse the parameters you will erase all of your source data.
Using a Physical Storage Device
If you are trying to migrate across servers that are not on the same physical network, the initial copy may take too long, particularly if you are copying several terabytes of media.
If you are copying over a slow internet connection you may want to perform the copy using a physical hard disk and overnighting the drive. In this case, use RoboCopy to populate the hard disk and then again to populate the destination. Make sure your data is encrypted on the device.
You can overnight the storage device and the first copy (or seed) will be significantly faster.
Copy Multiple Times
One of the great features of RoboCopy is that it will only copy the information that has changed since the last copy. The first time you copy the information, it might take many hours or even days to finish. Each subsequent copy will only transfer the information that has changed. It is likely that you will want to change a few configuration options in the destination system. If so, make a copy of these specific setup files or build a checklist of the necessary changes, as they will need to be made again after copying the information.
Final Copy
Once you are confident that you are ready to transfer to your new server, make sure you have a good backup, as you always should. Perform the final copy and make any setup changes as required.
Usually, there is no need to use a physical storage device for the final copy as RoboCopy will only copy the changes.
A common problem is some of the workstations continue to map to the old server. On the source folder, create a folder called “_Transfered”. Move all the “Transferred Folders” into this folder. They will be safe in case you want to move them back, but it won’t be possible for a client to connect to the old version by mistake. There are many similar strategies you can follow, but test to make sure that an old client cannot connect to the old server.
Windows SMB 3
Microsoft has struggled with SMB protocols. For a very long time, Vertican recommended using SMB 1 which was very reliable, but it has since been replaced with SMB 2 and finally SMB 3. It is our opinion that SMB 2 never worked properly. Fortunately, SMB 3 seems to be much more reliable and supports encryption in motion. Most of your clients require encryption in motion, so implementing SMB 3 on every server and workstation (without exceptions) will ensure data integrity.
In Collection-Master Client-Server, most of your data resides on the local drive of the server and is not accessed over a shared network. This eliminates most of the SMB issues, but there are many tasks that still use network sharing, so it is still very important!
vMedia users should migrate their metadata to SQL server to avoid these same problems.