<?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: Justification for backup integrity in Tech Talk</title>
    <link>https://community.isc2.org/t5/Tech-Talk/Justification-for-backup-integrity/m-p/48867#M3395</link>
    <description>&lt;P&gt;&lt;a href="https://community.isc2.org/t5/user/viewprofilepage/user-id/715155969"&gt;@dcontesti&lt;/a&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp; A good case of not only protecting backup's due to human error or system error but also ransomware attacks as well.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Regards&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Caute_Cautim&lt;/P&gt;</description>
    <pubDate>Mon, 03 Jan 2022 23:07:22 GMT</pubDate>
    <dc:creator>Caute_cautim</dc:creator>
    <dc:date>2022-01-03T23:07:22Z</dc:date>
    <item>
      <title>Justification for backup integrity</title>
      <link>https://community.isc2.org/t5/Tech-Talk/Justification-for-backup-integrity/m-p/48821#M3392</link>
      <description>&lt;P&gt;&lt;SPAN&gt;Kyoto University in Japan has lost about 77TB of research data due to an error in the backup system.&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&lt;SPAN&gt;&lt;A href="https://bit.ly/3mLHwVc" target="_blank"&gt;https://bit.ly/3mLHwVc&lt;/A&gt;&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&lt;SPAN&gt;A good case to ensure that your teams are regularly testing the integrity of the backups and great information to show management.&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&lt;SPAN&gt;d&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Fri, 31 Dec 2021 07:36:50 GMT</pubDate>
      <guid>https://community.isc2.org/t5/Tech-Talk/Justification-for-backup-integrity/m-p/48821#M3392</guid>
      <dc:creator>dcontesti</dc:creator>
      <dc:date>2021-12-31T07:36:50Z</dc:date>
    </item>
    <item>
      <title>Re: Justification for backup integrity</title>
      <link>https://community.isc2.org/t5/Tech-Talk/Justification-for-backup-integrity/m-p/48823#M3393</link>
      <description>&lt;P&gt;I had worked at a company ages ago and we learned this the hard way. All backup ran perfectly with not a single error, or so we thought. When a certain backup was needed it was found there was a problem with the head on the tape drive leave all the backup unusable! It's things like this you live through once, learn the hard way and then make sure backups get tested!&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;John-&lt;/P&gt;</description>
      <pubDate>Fri, 31 Dec 2021 15:40:11 GMT</pubDate>
      <guid>https://community.isc2.org/t5/Tech-Talk/Justification-for-backup-integrity/m-p/48823#M3393</guid>
      <dc:creator>JKWiniger</dc:creator>
      <dc:date>2021-12-31T15:40:11Z</dc:date>
    </item>
    <item>
      <title>Re: Justification for backup integrity</title>
      <link>https://community.isc2.org/t5/Tech-Talk/Justification-for-backup-integrity/m-p/48830#M3394</link>
      <description>&lt;P&gt;I get the feeling that there is more to this story than they are &lt;A href="https://www.iimc.kyoto-u.ac.jp/en/whatsnew/trouble/detail/211216056978.html" target="_blank" rel="noopener"&gt;letting on&lt;/A&gt;&amp;nbsp;especially because the impact date range ("not updated since Dec 3rd") does not have a "start" date.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Most failures result in the loss of new files, not old files -- notably those created since the last incremental.&amp;nbsp; Did they get really lucky with their backup timing, or is there some sort of hierarchical storage in play?&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Also, since they were able to recover 10 of 14 affected groups, it seem more like a bad tape than a bad tape drive, in which case I would think the "November" backup would likely not be bad in the same spot and could reduce the loss window to&amp;nbsp; "updates made between Nov 3 and Dec 3".&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Sun, 02 Jan 2022 07:18:44 GMT</pubDate>
      <guid>https://community.isc2.org/t5/Tech-Talk/Justification-for-backup-integrity/m-p/48830#M3394</guid>
      <dc:creator>denbesten</dc:creator>
      <dc:date>2022-01-02T07:18:44Z</dc:date>
    </item>
    <item>
      <title>Re: Justification for backup integrity</title>
      <link>https://community.isc2.org/t5/Tech-Talk/Justification-for-backup-integrity/m-p/48867#M3395</link>
      <description>&lt;P&gt;&lt;a href="https://community.isc2.org/t5/user/viewprofilepage/user-id/715155969"&gt;@dcontesti&lt;/a&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp; A good case of not only protecting backup's due to human error or system error but also ransomware attacks as well.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Regards&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Caute_Cautim&lt;/P&gt;</description>
      <pubDate>Mon, 03 Jan 2022 23:07:22 GMT</pubDate>
      <guid>https://community.isc2.org/t5/Tech-Talk/Justification-for-backup-integrity/m-p/48867#M3395</guid>
      <dc:creator>Caute_cautim</dc:creator>
      <dc:date>2022-01-03T23:07:22Z</dc:date>
    </item>
  </channel>
</rss>

