Command Server Database Backup / Restore Procedure (for Windows OS):
In anticipation of a catastrophic failure, you should always protect your NovaStor DataCenter command server, as this contains the database required to browse and track your backups. This guide also covers migrating from one Command Server (Windows OS) machine to another Command Server (Windows OS) machine in your DC environment (like if you need to replace the OS utilized on the original Command Server with a new OS, and you need to migrate the original Command Server app and app data to a new machine), and that info can be found in the "File copy/overlay (not using DataCenter .SV files)" section.
The below instructions are for Windows OS based Command Server installations. There is a separate KB article guide for Linux OS based Command Server installations here.
The following steps are critical in creating a backup job to protect your backup server:
- Create a disk pool for the exclusive purpose of holding only the NovaStor DataCenter database, for ease of recovery. It is recommended to configure a 3-day retention of this database for data integrity.
NOTE: ONLY use this pool for your NovaStor DataCenter Disaster Recovery Backup job!
- Configure some method of replication offsite or in the cloud of this storage pool so you can recover it in case of disaster.
- Configure the backup job to use the pool that was created exclusively for this purpose with the Fileset containing the “NovaStor” folder in ProgramData and Program Files:
C:\ProgramData\NovaStor\*
C:\Program Files\NovaStor\*
- Create a backup job to capture the NovaStor software installation locations:
NOTE: Make sure to NOT configure Multiplexing and splits on this job, as it makes it almost impossible to restore later.
- It is recommended that the backup be performed after all other critical data backups and Retention operations have completed:
Restore Procedure:
- Locate the DBDR (or NSDR) media pool folder (the backup directory assigned to the media pool) that your DataCenter Command Server Database backup (typically called DBDR, NSDR, or DataCenter Self-Backup) job was utilizing as the backup directory, it will contain .SV files that you will need to perform a direct restore of the Command Server Database database data from. If your DBDR backup pool was using a backup directory located on a local hard drive, for instance where a disk pool utilized the backup directory 'D:\DataCenter\DBDR\', then you will have a dated list of .SV files for those DBDR backups in that pool folder. If your DBDR backups were going to a network location such as a NAS then navigate to that network path, and look for the DBDR pool there to see the dated list of .SV files. You likely will only need the latest dated .SV file from that pool. If the .SV files are located on a tape pool that uses a single tape drive or tape library medium then the DBDR backup log will indicate which tape was utilized for the most recent DBDR backup job, and in that case you will have to perform a direct restore of the contents of the tape itself to retrieve any of the DBDR .SV file(s). Note: It is possible that the DataCenter software was setup to backup the database to two different locations, or for instance was cloning backups from a disk pool to a secondary backup location such as a tape or NAS, in that case the latest version of the .SV should be all that you need which normally would still be located on a disk pool to be able to copy directly via Windows Explorer. No matter what medium the backup was stored to, to make it easier you can just copy the latest DBDR backup .SV file to a path on the new Command Server machine such as 'C:\Restore\'. Note: Locate the physical disk pool folder for the .SV backup files via Windows Explorer by navigating to the backup dirrectory that your disk pool utilized to store the DBDR backups to locate the latest .SV file there to perform a direct restore on (the .SV files in the folder listing will be dated for you to know what date is the newest DBDR .SV backup, and if you had email notification enabled, or you can read the logs from the original Command Server regarding these backups, then the DBDR backup log itself when viewed will tell you what the exact .SV filename was that was written per DBDR backup to be able to identify which exact one you need, although most people would just restore the latest DBDR .SV file). If you still have your original Command Server machine around and it is still functional and you can login to it, then you can view the media pool, such as a the disk pool, where your DBDR backups utilized, via the Storage Management area of the GUI. The list will be dated, and the backup directory where those backups physically exist will be shown in the backup directory value at the top of the pool. If you still have the DBDR backup logs, whether they were emailed to you or you can view them in the Report Manager area of the UI, then each DBDR backup log will state the exact .SV filename that each backup utilized, to also know the exact filename, although keep in mind again that most people would only need to be able to restore from the latest dated DBDR .SV file, although if your DBDR backups were stored in a pool that is shared between multiple backup jobs (never recommended when it comes to DBDR backup jobs), which are not DataCenter database related (for instance if your DBDR + SQL backups + File backups all go to the same disk pool), then you may need to know the exact .SV filename in that case which the emailed logs or being able to view the logs via Report Manager on the original Command Server would be useful to obtain.
- Install the same version (or as close as possible) of the DataCenter Command Server software that was utilized on your old Command Server machine onto the new Command Server machine. No settings or special options needed just a Next, Next, Next, Wait. The only requirement is that the new machine that you are installing DataCenter Command Server software on must use the same computer name that the old Command Server machine utilized, at least for the base part of the computer name, the domain name it is joined to could be different, for instance the new machine could exist in a workgroup but contain the same base computer name as the old Command Server utilized, or if the old Command Server were joined to a domain, then the new machine could exist in a workgroup and that will work. The new Command Server machine can exist in a workgroup without much problem, even if all of your other computers are in a domain, and even if the old Command Server did not exist that way prior; as long as the base computer name on the new server matches the old server it will be fine; as the computer name requirement to be able to restore an old Command Server onto a new machine only cares about the base portion of the computer name.
- Follow the procedure to perform a direct restore of the latest DBDR .SV file located in the target backup directory that was assigned to the pool that the DBDR backup job utilized for the backup folder location, such as in the disk pool folder that your Command Server's DBDR backup was set to utilize, it would be easiest just to copy that latest .SV file as a single file to a path on the current Command Server machine such as 'C:\Restore\', to make it easier to perform a direct restore from.
https://support.novastor.com/hc/en-us/articles/360005856213--Guide-DataCenter-Direct-Restore-from-SV-file
- You can also use the simple_restore.cmd script to do this, simply copy the script into the folder that contains your .SV backup file
File copy/overlay (not using DataCenter .SV files)
This is the procedure to manually backup/restore the DataCenter/Network command server before/after a full system reinstall.
NOTE: This is also the same procedure you would use if you migrate from one machine to another, I.E. Physical machine to Virtual Machine. If migrating the Command Server to a new or replacement machine, you would need to make sure that the new machine has the exact same computer name and domain name as prior, the IP address could be different, but the computer name has to be exactly the same as the old Command Server machine. You would need to make sure that the old Command Server machine is renamed or taken offline. A special mention and a caveat for this is below, for instance in case your original Command Server machine was a Domain Controller that cannot easily be renamed to support moving your Command Server node to another new machine (which requires the machine name to match the original CmdSrv machine):
One caveat and requirement to doing this is that the new machine you want the CmdSrv to be on HAS to contain the same computer name exactly as it did prior, if it does not then things won't work. If the original CmdSrv node computer was joined to a domain and is called "CMDSRV1.mydomain.local" then the new machine has to be the same, it only cares about the first part of the name however for this requirement, so for instance if you are unable to rename the original CMDSRV1 machine on the domain to get it renamed to CMDSRV2, or CMDSRV_old, to then be able to rename the new machine that is also joined to the same domain to be named "CMDSRV1.mydomain.local", then you COULD in that case have the new physical server joined to WORKGROUP and not the domain, and in that case you will be able to name it "CMDSRV1" without renaming the original CmdSrv node. When you go to name the computer, it will take issue with the fact if CMDSRV1 on the domain already exists, but not if the new machine is in a WORKGROUP, it does not care that there are two CMDSRV1 machines active, so it will allow naming that way on the new machine if absolutely needed to do so. I would try to rename the original machine to be different before attempting to rename the new machine to the same way, but there are cases where some customers installed DataCenter Command Server on a Domain Controller so renaming the machine is not feasible to do in that case as it will break all AD functionality in that very specific case.
The process to backup and restore to a new install is a very simple process.
**** Be sure you have the installer for the same version currently installed before starting the backups. ****
**** Installing any upgrade before backup would be a good idea to ensure the versions match. ****
Before doing the migration you will need check where your media pools are storing the backup data. This can be found on the Storage Management tab of the GUI. Each Media Pool will have a path to its storage location.
- If these locations are on a NAS device or some other network location, I.E. \\device\storage\Backups, then there is no need to worry, as that path will be the same as it currently is.
- If you are using a local storage location, i.e. D:\Backups, then you will need to make sure to copy all data in these folders to an external location, or all backup data will be lost.
- You will also need to be sure to recreate the same local drive partition structure after refresh so the data can be copied back to the same path it is currently configured to look for in the Database (i.e. D:\Backups).
Procedure:
- Identify the version of the DataCenter Command Server that is installed currently on the production Command Server machine. You will need to have the original CmdSrv*.exe installer for that version downloaded. Contact the DataCenter Support team by creating a ticket, if you do not have the particular version download, as you will need it in step 5.
- Stop all "NBK DC *" or "NovaStor DC *" services on the Command Server machine (You can use the Stop.bat or Stop.ps1 file attached or create your own, see below). Once all of the services are stopped:
- Copy the C:\ProgramData\NovaStor\DataCenter folder from the original Command Server machine, to backup it up into a zip file and copy that somewhere externally.
- Copy the C:\Program Files\NovaStor\DataCenter folder from the original Command Server machine, to backup it up into a zip file and copy that somewhere externally.
**** At this point your database has been copied and is able to be restored to this point in time later or used to migrate the Command Server to a new machine, as detailed below. ****
- Install the same version of the Command Server software onto the new machine just as before. No settings or special options needed just a Next, Next, Next, Wait......
- Once the Command Server install is complete: Stop all of the DC services again. (You can use the Stop.ps1 file attached or create your own, see below).
- Copy the previously backed up folders, such as either from your manually copied folder structure mentioned in Steps 3 and 4 above, or from the file contents contained inside your latest DBDR backup .SV file that all of the files were restored from using the Direct Restore method, to their original locations (Program Files and ProgramData) and overlay the current data. If you are concerned, rename the newly created folder and copy the old here.
**** If needed, copy any moved backup data to their original path (i.e. local storage). Disregard if you store data on a network location. ****
- Once the Program Files and ProgramData folders are overwritten as performed in Step 7, you will now install the same version of the Command Server one more time, on top of the existing, using the same version of the CmdSrv*.exe file, which is the same version that was performed in Step 5.
- Start the DC services and launch the GUI. (You can use the Start.bat or Start.ps1 file attached or create your own, see below).
- Finally, confirm that the GUI is able to load, and you are able to see your old data, such as your old backup jobs, logs, disk pools, etc.
Batch Scripts to stop/start services
Stop.bat is a batch script to stop NBK DC services.
sc stop "nbksrv"
sc stop "DerbyDB"
sc stop "hijacc"
sc stop "hiserv"
sc stop "mpx"
sc stop "OpenEJBServer"
sc stop "rcmd-dispatcher@port:32335"
sc stop "rcmd-executor@port:32334"
sc stop "DCWebserver"
Start.bat is a batch script to start NBK DC services.
Start.ps1
sc start "nbksrv"
sc start "DerbyDB"
sc start "hijacc"
sc start "hiserv"
sc start "mpx"
sc start "OpenEJBServer"
sc start "rcmd-dispatcher@port:32335"
sc start "rcmd-executor@port:32334"
sc start "DCWebserver"
PowerShell Scripts to stop/start services
Stop.ps1 is a PowerShell script to stop NBK DC services.
"nbksrv", "DerbyDB", "hijacc", "hiserv", "mpx", "OpenEJBServer", "rcmd-dispatcher@port:32335", "rcmd-executor@port:32334", "DCWebserver" | %{ stop-service $_ }
Start.ps1 is a PowerShell script to start NBK DC services.
"nbksrv", "DerbyDB", "hijacc", "hiserv", "mpx", "OpenEJBServer", "rcmd-dispatcher@port:32335", "rcmd-executor@port:32334", "DCWebserver" | %{ start-service $_ }
Tips & Tricks from us to you
- Try utilizing a Task Scheduler entry to run a RoboCopy script to create a spare copy of the C:\ProgramData\NovaStor & C:\Program Files\NovaStor folders and zip them with the current date (if you wish)
- You can then have a Cloud sync program target these copies to have it offsite in case of failure (i.e. Google Drive, Dropbox, OneDrive, Amazon Drive, etc.)