Building for the Splunk Platform

Move Index Files from one system to another


We are planning to roll out an active/active solution in two data centers. Each DC splunk instance will only handle local logs. We are looking to put a plan in place should a failure of one site occur.

  1. What is the best mechanism/tools to handle this situation.
  2. What should be planned for e.g. use different index names in each site e.g. main_site1 and main_site2? Both sites will handle similar logs and peer to each other for searches.
Tags (2)
0 Karma

Super Champion

I'd suggest that you also checkout this question and answer:

There's a comment about the isReadOnly setting in indexes.conf which you may want to look into as well. The idea is to prevent accidental writing to a replicated index. It's possible that read-only file permissions may also be a good idea in this case. (BTW, I assuming that you aren't going to try to let both sites index data into both each others directories, because that will not work.)

It may be a good idea to work though a plan with splunk support for your specific setup.

0 Karma


Hi brainokelly

about moving an index find the docs here.

If you plan to move one site to another in case of a failure, then I would do as you wrote in question 2. Call them main_site1 and main_site2. This way you are able to move the index back to its original site and even keep the data collected while it was on the failure site.

hope you can follow me 🙂

Get Updates on the Splunk Community!

Announcing General Availability of Splunk Incident Intelligence!

Digital transformation is real! Across industries, companies big and small are going through rapid digital ...

Splunk Training for All: Meet Aspiring Cybersecurity Analyst, Marc Alicea

Splunk Education believes in the value of training and certification in today’s rapidly-changing data-driven ...

The Splunk Success Framework: Your Guide to Successful Splunk Implementations

Splunk Lantern is a customer success center that provides advice from Splunk experts on valuable data ...