Migrate a Splunk Enterprise instance
|Important: These migration instructions are for on-premises Splunk Enterprise instances only.|
|If you are a Splunk Cloud customer or want to migrate your data from Splunk Enterprise to Splunk Cloud, do not use these instructions. Contact Professional Services for assistance.|
You can migrate a Splunk Enterprise instance from one server, operating system, architecture, or filesystem to another, while maintaining the indexed data, configurations, and users. Migrating an instance of Splunk Enterprise different than upgrading one, which is merely installing a new version on top of an older one.
Do not attempt to migrate a Splunk Enterprise installation to Splunk Cloud using these instructions. Doing so could result in data loss. Speak with Professional Services or your Splunk Cloud representative for information and instructions.
When to migrate
There are a number of reasons to migrate a Splunk Enterprise install:
- Your Splunk Enterprise installation is on a host that you wish to retire or reuse for another purpose.
- Your Splunk Enterprise installation is on an operating system that either your organization or Splunk no longer supports, and you want to move it to an operating system that does have support.
- You want to switch operating systems (for example, from *nix to Windows or vice versa)
- You want to move your Splunk Enterprise installation to a different file system.
- Your Splunk Enterprise installation is on 32-bit architecture, and you want to move it to a 64-bit architecture for better performance.
- Your Splunk Enterprise installation is on a system architecture that you plan to stop supporting, and you want to move it to an architecture that you do support.
Considerations for migrating Splunk Enterprise
While migrating a Splunk Enterprise instance is simple in many cases, there are some important considerations to note when doing so. Depending on the type, version, and architecture of the systems involved in the migration, you might need to consider more than one of these items at a time.
When you migrate a Splunk Enterprise instance, note the following.
If you indexed data with a version of Splunk Enterprise earlier than 4.2, the index files that comprise that data are sensitive to operating system endianness, which is the way the system organizes the individual bytes of a binary file (or other data structure).
Some operating systems are big-endian (meaning they store the most significant byte of a word in computer memory first), and others are little-endian (meaning they store the least significant byte first). These operating systems create binary files of the same endianness. Index bucket files are binary, and thus, for versions of Splunk Enterprise earlier than 4.2, are the same endianness of the operating system that created them.
For a listing of processor architectures and the endianness they use, see the Endianness article on Wikipedia.
When you migrate a pre-4.2 Splunk Enterprise instance, in order for the destination system to be able to read the migrated data, you must transfer index files between systems with the same kind of endianness (for example, a NetBSD system running on a SPARC processor to a Linux system also running on a SPARC processor.)
If you can't move index between systems with the same endianness (for example, when you want to move from a system that is big-endian to a system that is little-endian), you can move the data by forwarding it from the big-endian system to the little-endian system. Then, after you have forwarded all the data, you can retire the big-endian system.
Index files that Splunk Enterprise versions 4.2 and later create are not sensitive to host endianness.
Differences in Windows and Unix path separators
The path separator (the character used to separate individual directory elements of a path) on *nix and Windows is different. When you move index files between these operating systems, you must confirm that the path separator you use is correct for the target operating system. You must also make sure that you update any Splunk configuration files (in particular,
indexes.conf) to use the correct path separator.
For more information about how path separators can impact Splunk Enterprise installations, see Differences between *nix and Windows in Splunk operations in the Admin manual.
When moving a Splunk Enterprise instance between Windows hosts, make sure that the destination host has the same rights assigned to it that the source host does. This includes but is not limited to the following:
- Ensure that the file system and share permissions on the target host are correct and allow access for the user that runs Splunk Enterprise.
- If Splunk Enterprise runs as an account other than the Local System user, that the user is a member of the local Administrators group and has the appropriate Local Security Policy or Domain Policy rights assigned to it by a Group Policy object
If you downgrade the architecture that your Splunk Enterprise instance runs on (for example, 64-bit to 32-bit), you might experience degraded search performance on the new host due to the larger files that the 64-bit operating system and Splunk Enterprise instance created.
Distributed and clustered Splunk environments
When you want to migrate data on a distributed Splunk instance (that is, an indexer that is part of a group of search peers, or a search head that has been configured to search indexers for data), you should remove the instance from the distributed environment before attempting to migrate it.
Bucket IDs and potential bucket collision
If you migrate a Splunk Enterprise instance to another Splunk instance that already has existing indexes with identical names, you must make sure that the individual buckets within those indexes have bucket IDs that do not collide. Splunk Enterprise does not start if it encounters indexes with buckets that have colliding bucket IDs. When you copy index data, you might need to rename the copied bucket files to prevent this condition.
How to migrate
When you migrate on *nix systems, you can extract the tar file you downloaded directly over the copied files on the new system, or use your package manager to upgrade using the downloaded package. On Windows systems, the installer updates the Splunk files automatically.
- Stop Splunk Enterprise on the host from which you want to migrate.
- Copy the entire contents of the $SPLUNK_HOME directory from the old host to the new host.
- Install the appropriate version of Splunk Enterprise for the target platform.
- Confirm that index configuration files (indexes.conf) contain the correct location and path specification for any non-default indexes.
- Start Splunk Enterprise on the new instance.
- Log into Splunk Enterprise with your existing credentials.
- After you log in, confirm that your data is intact by searching it.
How to move index buckets from one host to another
If you want to retire a Splunk Enterprise instance and immediately move the data to another instance, you can move individual buckets of an index between hosts, as long as:
- The source and target hosts have the same endianness.
- You do not restore a bucket created by a 4.2 or later version of Splunk Enterprise to a version less than 4.2.
Note: When you copy individual bucket files, you must make sure that no bucket IDs conflict on the new system. Otherwise, Splunk Enterprise does not start. You might need to rename individual bucket directories after you move them from the source system to the target system.
- Roll any hot buckets on the source host from hot to warm.
- Review indexes.conf on the old host to get a list of the indexes on that host.
- On the target host, create indexes that are identical to the ones on the source system.
- Copy the index buckets from the source host to the target host.
- Restart Splunk Enterprise.
Upgrade to 6.3 on Windows
Migrate to the new Splunk Enterprise licenser
This documentation applies to the following versions of Splunk® Enterprise: 6.3.0, 6.3.1, 6.3.2, 6.3.3, 6.3.4, 6.3.5, 6.3.6, 6.3.7, 6.3.8, 6.3.9, 6.3.10, 6.3.11, 6.3.12, 6.3.13, 6.3.14, 6.4.0, 6.4.1, 6.4.2, 6.4.3, 6.4.4, 6.4.5, 6.4.6, 6.4.7, 6.4.8, 6.4.9, 6.4.10, 6.4.11, 6.5.0, 6.5.1, 6.5.2, 6.5.3, 6.5.4, 6.5.5, 6.5.6, 6.5.7, 6.5.8, 6.5.9, 6.5.10, 6.6.0, 6.6.1, 6.6.2, 6.6.3, 6.6.4, 6.6.5, 6.6.6, 6.6.7, 6.6.8, 6.6.9, 6.6.10, 6.6.11, 6.6.12