<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: rawdata restore possible? in Getting Data In</title>
    <link>https://community.splunk.com/t5/Getting-Data-In/rawdata-restore-possible/m-p/35731#M96675</link>
    <description>&lt;P&gt;Found this question whilst searching for the same answer - thought I'd give the answer now I've worked it out.&lt;/P&gt;

&lt;P&gt;In my case I had a journal.gz but had no idea where it came from originally.&lt;/P&gt;

&lt;P&gt;i)  Create a directory for the bucket:&lt;/P&gt;

&lt;UL&gt;
&lt;LI&gt;mkdir /tmp/newBucket&lt;/LI&gt;
&lt;LI&gt;mkdir /tmp/newBucket/rawdata&lt;/LI&gt;
&lt;/UL&gt;

&lt;P&gt;ii) Copy in the journal.gz&lt;/P&gt;

&lt;UL&gt;
&lt;LI&gt;cp journal.gz /tmp/newBucket/rawdata/&lt;/LI&gt;
&lt;/UL&gt;

&lt;P&gt;iii)  Now run rebuild&lt;/P&gt;

&lt;UL&gt;
&lt;LI&gt;./splunk rebuild /tmp/newBucket&lt;/LI&gt;
&lt;/UL&gt;

&lt;P&gt;iv)  Determine the bucket name.  We can get this from the tsidx files.&lt;/P&gt;

&lt;UL&gt;
&lt;LI&gt;ls /tmp/newBucket/*.tsidx&lt;/LI&gt;
&lt;/UL&gt;

&lt;P&gt;Gives&lt;/P&gt;

&lt;UL&gt;
&lt;LI&gt;1351216920-1351213200-1612246429890249572.tsidx&lt;/LI&gt;
&lt;LI&gt;1353460020-1351213200-999025018140623716.tsidx&lt;/LI&gt;
&lt;/UL&gt;

&lt;P&gt;The format is db_max_min_uniqid where&lt;/P&gt;

&lt;UL&gt;
&lt;LI&gt;max is the highest of the first number in the tsidx file - in this case 1353460020&lt;/LI&gt;
&lt;LI&gt;min is the lowest of the second number in the tsidx filename - in this case 1351213200&lt;/LI&gt;
&lt;LI&gt;uniqid is a unique integer that is not currently used in my target index.  I used 1.&lt;/LI&gt;
&lt;/UL&gt;

&lt;P&gt;Thus we get:&lt;/P&gt;

&lt;UL&gt;
&lt;LI&gt;mv /tmp/newBucket /tmp/db_1353460020_1351213200_1&lt;/LI&gt;
&lt;/UL&gt;

&lt;P&gt;v)   Copy this directory into the target indexes thaweddb directory.  I created an index called recovered so:&lt;/P&gt;

&lt;UL&gt;
&lt;LI&gt;mv /tmp/db_1353460020_1351213200_1 /Applications/splunk/var/lib/splunk/recovered/thaweddb/&lt;/LI&gt;
&lt;/UL&gt;

&lt;P&gt;vi)  Run:&lt;/P&gt;

&lt;UL&gt;
&lt;LI&gt;./splunk _internal call /data/indexes/main/rebuild-metadata-and-manifests&lt;/LI&gt;
&lt;/UL&gt;

&lt;P&gt;Wait a short while and then run a search on your new index.&lt;/P&gt;</description>
    <pubDate>Wed, 28 Nov 2012 17:27:40 GMT</pubDate>
    <dc:creator>ahattrell_splun</dc:creator>
    <dc:date>2012-11-28T17:27:40Z</dc:date>
    <item>
      <title>rawdata restore possible?</title>
      <link>https://community.splunk.com/t5/Getting-Data-In/rawdata-restore-possible/m-p/35730#M96674</link>
      <description>&lt;P&gt;I am attempting to recover from a hard crash, through no fault of Splunk's.  Is it possible to unzip /rawdata/journal.gz and import that raw data back into a new index?  I had multiple indexes, so there are are multiple folders with rawdata/journal.gz in them.  Just looking to unzip them all into 1 index.&lt;/P&gt;</description>
      <pubDate>Wed, 15 Aug 2012 15:53:49 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Getting-Data-In/rawdata-restore-possible/m-p/35730#M96674</guid>
      <dc:creator>gregwilliams</dc:creator>
      <dc:date>2012-08-15T15:53:49Z</dc:date>
    </item>
    <item>
      <title>Re: rawdata restore possible?</title>
      <link>https://community.splunk.com/t5/Getting-Data-In/rawdata-restore-possible/m-p/35731#M96675</link>
      <description>&lt;P&gt;Found this question whilst searching for the same answer - thought I'd give the answer now I've worked it out.&lt;/P&gt;

&lt;P&gt;In my case I had a journal.gz but had no idea where it came from originally.&lt;/P&gt;

&lt;P&gt;i)  Create a directory for the bucket:&lt;/P&gt;

&lt;UL&gt;
&lt;LI&gt;mkdir /tmp/newBucket&lt;/LI&gt;
&lt;LI&gt;mkdir /tmp/newBucket/rawdata&lt;/LI&gt;
&lt;/UL&gt;

&lt;P&gt;ii) Copy in the journal.gz&lt;/P&gt;

&lt;UL&gt;
&lt;LI&gt;cp journal.gz /tmp/newBucket/rawdata/&lt;/LI&gt;
&lt;/UL&gt;

&lt;P&gt;iii)  Now run rebuild&lt;/P&gt;

&lt;UL&gt;
&lt;LI&gt;./splunk rebuild /tmp/newBucket&lt;/LI&gt;
&lt;/UL&gt;

&lt;P&gt;iv)  Determine the bucket name.  We can get this from the tsidx files.&lt;/P&gt;

&lt;UL&gt;
&lt;LI&gt;ls /tmp/newBucket/*.tsidx&lt;/LI&gt;
&lt;/UL&gt;

&lt;P&gt;Gives&lt;/P&gt;

&lt;UL&gt;
&lt;LI&gt;1351216920-1351213200-1612246429890249572.tsidx&lt;/LI&gt;
&lt;LI&gt;1353460020-1351213200-999025018140623716.tsidx&lt;/LI&gt;
&lt;/UL&gt;

&lt;P&gt;The format is db_max_min_uniqid where&lt;/P&gt;

&lt;UL&gt;
&lt;LI&gt;max is the highest of the first number in the tsidx file - in this case 1353460020&lt;/LI&gt;
&lt;LI&gt;min is the lowest of the second number in the tsidx filename - in this case 1351213200&lt;/LI&gt;
&lt;LI&gt;uniqid is a unique integer that is not currently used in my target index.  I used 1.&lt;/LI&gt;
&lt;/UL&gt;

&lt;P&gt;Thus we get:&lt;/P&gt;

&lt;UL&gt;
&lt;LI&gt;mv /tmp/newBucket /tmp/db_1353460020_1351213200_1&lt;/LI&gt;
&lt;/UL&gt;

&lt;P&gt;v)   Copy this directory into the target indexes thaweddb directory.  I created an index called recovered so:&lt;/P&gt;

&lt;UL&gt;
&lt;LI&gt;mv /tmp/db_1353460020_1351213200_1 /Applications/splunk/var/lib/splunk/recovered/thaweddb/&lt;/LI&gt;
&lt;/UL&gt;

&lt;P&gt;vi)  Run:&lt;/P&gt;

&lt;UL&gt;
&lt;LI&gt;./splunk _internal call /data/indexes/main/rebuild-metadata-and-manifests&lt;/LI&gt;
&lt;/UL&gt;

&lt;P&gt;Wait a short while and then run a search on your new index.&lt;/P&gt;</description>
      <pubDate>Wed, 28 Nov 2012 17:27:40 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Getting-Data-In/rawdata-restore-possible/m-p/35731#M96675</guid>
      <dc:creator>ahattrell_splun</dc:creator>
      <dc:date>2012-11-28T17:27:40Z</dc:date>
    </item>
    <item>
      <title>Re: rawdata restore possible?</title>
      <link>https://community.splunk.com/t5/Getting-Data-In/rawdata-restore-possible/m-p/35732#M96676</link>
      <description>&lt;P&gt;Adam has the good answer here, but to be explicit: you cannot uncompress journal.gz and re-compress it sanely.  slices.dat and journal.gz must agree and both must exist.&lt;/P&gt;

&lt;P&gt;If you somehow encounter a corruption mid-journal.gz and need to perform partial recovery because it's hugely important data and you have no backups (!!) and are willing to spend many hours on the problem, get in touch directly (username) or via support. &lt;/P&gt;

&lt;P&gt;Generally Splunk shouldn't be capable of generating such a problem as we don't modify these files, so any such problem would have to be OS or hardware faults.&lt;/P&gt;</description>
      <pubDate>Wed, 24 Jul 2013 00:49:30 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Getting-Data-In/rawdata-restore-possible/m-p/35732#M96676</guid>
      <dc:creator>jrodman</dc:creator>
      <dc:date>2013-07-24T00:49:30Z</dc:date>
    </item>
    <item>
      <title>Re: rawdata restore possible?</title>
      <link>https://community.splunk.com/t5/Getting-Data-In/rawdata-restore-possible/m-p/35733#M96677</link>
      <description>&lt;P&gt;I was trying to follow this step with Splunk6.0.2, but it did not work. Any chance since this question answered?&lt;/P&gt;</description>
      <pubDate>Wed, 02 Apr 2014 09:49:18 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Getting-Data-In/rawdata-restore-possible/m-p/35733#M96677</guid>
      <dc:creator>melonman</dc:creator>
      <dc:date>2014-04-02T09:49:18Z</dc:date>
    </item>
  </channel>
</rss>

