Submit a ticketCall us

Cloud Workloads: Meet Your New Hybrid IT Reality
Have you found yourself in that evolving, hybrid IT grey area and wondering if cloud workloads are now part of your purview? And if so, will monitoring cloud workloads require a new set of dedicated cloud monitoring tools? Your answers: yes, they should be, and no, they don’t.

Find out how SolarWinds® Server & Application Monitor (SAM) can help you monitor your cloud workloads side by side with your on-premises workloads. Register Now.

Home > Success Center > Storage Manager (STM) > SRM Profiler Administrator Guide > Common tasks with SRM Profiler > Set up disaster recovery with SRM Profiler

Set up disaster recovery with SRM Profiler

Table of contents
No headers

Updated: June 16, 2017

  1. If the DR (Disaster Recovery) server has a different IP or FQDN (Fully Qualified Domain Name) please review the following steps, otherwise skip to step 2:
    1. Make sure the DR server has visibility to the agents. Can you ping the agents from the DR server?
    2. Verify you cannot ping the compromised server. If you can ping the compromised server, shut it down to make the IP address available.
    3. If the compromised server's IP address is available, assign it to the DR server along with the FQDN.
    4. Install the SRM Profiler server software on the DR server.
    5. Make sure all of the SRM Profiler services are running on the DR server.
    6. Log into the web console for the SRM Profiler DR server.
    7. Select Settings > Policies > Default OS Policy > Edit button (pencil icon) > Communications.
    8. Change the following options to match the compromised server:

      HTTP Port

      Default (4319)

      Server

      IP or Domain Name

      Trap Port

      Defaults (162, 10162, 20162)

      Community String

      Default (public)

      Override Agent Values

      No
    1. Click Save.
    2. It is not necessary to push the values. You are only changing the Default OS Policy to match what is already configured on the agents.

    3. If you have a backup copy of your database that is formatted to the same version of SRM Profiler that was running on the compromised server, proceed to step 2. If not, you will be forced to start with the blank database that is installed by default.
  2. Stop the database service on the DR server. This will also stop all 5 (Event Receiver, Maintenance, Poller, and Web) SRM Profiler Services.
  3. SRM Profiler versions 5.6 and newer use MariaDB. For versions prior to 5.6, substitute MySQL for MariaDB.

  4. If you have a backup copy of your database, rename or delete the default blank database and migrate your backup database to the DR server.
  5. The database backup must be formatted to the same version of SRM Profiler that is running on the DR server. If you do not have a properly formatted backup of the database or no backup database, you will be forced to start with the blank database that is installed by default.

    The default location for the database is in the storage folder:

    Windows: <installed drive>\Program Files\Solarwinds\Storage Manager Server\mariadb\data\

    Linux: /opt/Storage_Manager_Server/mariadb/data/

    Place the entire folder into the subdirectory on the DR server.

  6. Start the Database, Collector, Event Receiver, Maintenance, Poller, and Web Services.
  7. Log into the SRM Profiler website for the new server using your regular username, password and insert the license key obtained from your customer portal into SRM Profiler. If there is no key present in your customer portal, call customer service to get it reset. SRM Profiler runs in evaluation mode for 30 days without a key.
  8. Verify that SRM Profiler is communicating with the devices being monitored. This can be verified by viewing the main console website. If there are any communication issues, contact technical support for assistance.
 
Last modified

Tags

Classifications

Public