<?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: Splunk Local Disaster Recovery Solution in Splunk Enterprise</title>
    <link>https://community.splunk.com/t5/Splunk-Enterprise/Splunk-Local-Disaster-Recovery-Solution/m-p/702054#M20525</link>
    <description>&lt;P&gt;The Splunk Validated Architectures manual should help.&amp;nbsp; You may be interested in the M3/M13 or M4/M14 models.&amp;nbsp; See &lt;A href="https://docs.splunk.com/Documentation/SVA/current/Architectures/M4M14" target="_blank"&gt;https://docs.splunk.com/Documentation/SVA/current/Architectures/M4M14&lt;/A&gt;&lt;/P&gt;</description>
    <pubDate>Wed, 16 Oct 2024 12:09:34 GMT</pubDate>
    <dc:creator>richgalloway</dc:creator>
    <dc:date>2024-10-16T12:09:34Z</dc:date>
    <item>
      <title>Splunk Local Disaster Recovery Solution</title>
      <link>https://community.splunk.com/t5/Splunk-Enterprise/Splunk-Local-Disaster-Recovery-Solution/m-p/702018#M20516</link>
      <description>Hello, we urgently need to obtain a Splunk local disaster recovery solution and hope to receive a best practice explanation. The existing Splunk consists of 3 search heads, 1 deployer, 1 master node, 1 DMC, 3 indexes, and 2 heavy forwarders. In this architecture, the search replication factors are all 2 and there is stock data available. The demand for local disaster recovery is: The host room where the existing data center's Xinchuang SIEM system is located has been shut down, and the data in the disaster recovery room can be queried normally. The closure of the newly built disaster recovery host room will not affect the use of the existing data center's SIEM system. RPO 0 cannot lose data, RTO can recover within 6 hours.</description>
      <pubDate>Wed, 16 Oct 2024 02:19:17 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Splunk-Enterprise/Splunk-Local-Disaster-Recovery-Solution/m-p/702018#M20516</guid>
      <dc:creator>jiaminyun</dc:creator>
      <dc:date>2024-10-16T02:19:17Z</dc:date>
    </item>
    <item>
      <title>Re: Splunk Local Disaster Recovery Solution</title>
      <link>https://community.splunk.com/t5/Splunk-Enterprise/Splunk-Local-Disaster-Recovery-Solution/m-p/702054#M20525</link>
      <description>&lt;P&gt;The Splunk Validated Architectures manual should help.&amp;nbsp; You may be interested in the M3/M13 or M4/M14 models.&amp;nbsp; See &lt;A href="https://docs.splunk.com/Documentation/SVA/current/Architectures/M4M14" target="_blank"&gt;https://docs.splunk.com/Documentation/SVA/current/Architectures/M4M14&lt;/A&gt;&lt;/P&gt;</description>
      <pubDate>Wed, 16 Oct 2024 12:09:34 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Splunk-Enterprise/Splunk-Local-Disaster-Recovery-Solution/m-p/702054#M20525</guid>
      <dc:creator>richgalloway</dc:creator>
      <dc:date>2024-10-16T12:09:34Z</dc:date>
    </item>
    <item>
      <title>Re: Splunk Local Disaster Recovery Solution</title>
      <link>https://community.splunk.com/t5/Splunk-Enterprise/Splunk-Local-Disaster-Recovery-Solution/m-p/702057#M20528</link>
      <description>&lt;P&gt;Well, it's actually _not_ a disaster recovery. It's a HA solution with some assumed level of fault tolerance.&lt;/P&gt;&lt;P&gt;&lt;a href="https://community.splunk.com/t5/user/viewprofilepage/user-id/231680"&gt;@jiaminyun&lt;/a&gt;There is no such thing as "0 RPO" unless you do make some boundary conditions and prepare accordingly. A HA infrastructure like the one from SVAs can protect you in case of some disasters but will not protect you from other ones (like misconfiguration or deliberate data destroying). If you're OK with that - be my guest. Just be aware of it.&lt;/P&gt;&lt;P&gt;RTO actually depends on your equipment, storage and resources (including personnel) you can allocate to the recovery task.&lt;/P&gt;</description>
      <pubDate>Wed, 16 Oct 2024 12:56:50 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Splunk-Enterprise/Splunk-Local-Disaster-Recovery-Solution/m-p/702057#M20528</guid>
      <dc:creator>PickleRick</dc:creator>
      <dc:date>2024-10-16T12:56:50Z</dc:date>
    </item>
    <item>
      <title>Re: Splunk Local Disaster Recovery Solution</title>
      <link>https://community.splunk.com/t5/Splunk-Enterprise/Splunk-Local-Disaster-Recovery-Solution/m-p/702489#M20583</link>
      <description>&lt;P&gt;Thank you for your response, We have achieved the final same city disaster recovery architecture by combining M3/M13 and UF clone dual writing!&lt;/P&gt;</description>
      <pubDate>Tue, 22 Oct 2024 10:42:11 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Splunk-Enterprise/Splunk-Local-Disaster-Recovery-Solution/m-p/702489#M20583</guid>
      <dc:creator>jiaminyun</dc:creator>
      <dc:date>2024-10-22T10:42:11Z</dc:date>
    </item>
    <item>
      <title>Re: Splunk Local Disaster Recovery Solution</title>
      <link>https://community.splunk.com/t5/Splunk-Enterprise/Splunk-Local-Disaster-Recovery-Solution/m-p/702490#M20584</link>
      <description>Thank you for your response, We have achieved the final same city disaster recovery architecture by combining M3/M13 and UF clone dual writing!</description>
      <pubDate>Tue, 22 Oct 2024 10:43:22 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Splunk-Enterprise/Splunk-Local-Disaster-Recovery-Solution/m-p/702490#M20584</guid>
      <dc:creator>jiaminyun</dc:creator>
      <dc:date>2024-10-22T10:43:22Z</dc:date>
    </item>
    <item>
      <title>Re: Splunk Local Disaster Recovery Solution</title>
      <link>https://community.splunk.com/t5/Splunk-Enterprise/Splunk-Local-Disaster-Recovery-Solution/m-p/703067#M20621</link>
      <description>After testing UF output cloning, it was found that it is impossible to achieve true same data distribution across multiple clusters! Is there any good solution for dual writing? most urgent!</description>
      <pubDate>Wed, 30 Oct 2024 06:40:39 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Splunk-Enterprise/Splunk-Local-Disaster-Recovery-Solution/m-p/703067#M20621</guid>
      <dc:creator>jiaminyun</dc:creator>
      <dc:date>2024-10-30T06:40:39Z</dc:date>
    </item>
    <item>
      <title>Re: Splunk Local Disaster Recovery Solution</title>
      <link>https://community.splunk.com/t5/Splunk-Enterprise/Splunk-Local-Disaster-Recovery-Solution/m-p/703068#M20622</link>
      <description>After testing UF output cloning, it was found that it is impossible to achieve true same data distribution across multiple clusters! Is there any good solution for dual writing? most urgent!</description>
      <pubDate>Wed, 30 Oct 2024 06:42:09 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Splunk-Enterprise/Splunk-Local-Disaster-Recovery-Solution/m-p/703068#M20622</guid>
      <dc:creator>jiaminyun</dc:creator>
      <dc:date>2024-10-30T06:42:09Z</dc:date>
    </item>
    <item>
      <title>Re: Splunk Local Disaster Recovery Solution</title>
      <link>https://community.splunk.com/t5/Splunk-Enterprise/Splunk-Local-Disaster-Recovery-Solution/m-p/703072#M20623</link>
      <description>&lt;P&gt;If you mean sending to two output groups from a single forwarder - that works until one of them gets blocked. Then both stop. It's by design.&lt;/P&gt;</description>
      <pubDate>Wed, 30 Oct 2024 07:17:45 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Splunk-Enterprise/Splunk-Local-Disaster-Recovery-Solution/m-p/703072#M20623</guid>
      <dc:creator>PickleRick</dc:creator>
      <dc:date>2024-10-30T07:17:45Z</dc:date>
    </item>
  </channel>
</rss>

