<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/">
  <channel>
    <title>Backups on isoul.uk</title>
    <link>https://isoul.uk/tags/backups/</link>
    <description>Recent content in Backups on isoul.uk</description>
    <generator>Hugo</generator>
    <language>en-gb</language>
    <lastBuildDate>Mon, 14 Sep 2026 10:05:00 +0100</lastBuildDate>
    <atom:link href="https://isoul.uk/tags/backups/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Backup, synchronisation or preservation?</title>
      <link>https://isoul.uk/posts/backup-synchronisation-or-preservation/</link>
      <pubDate>Mon, 14 Sep 2026 10:05:00 +0100</pubDate>
      <guid>https://isoul.uk/posts/backup-synchronisation-or-preservation/</guid>
      <description>Three different jobs that are often confused in self-hosted setups.</description>
      <content:encoded><![CDATA[<p>A copy of a file is not automatically a backup, and a backup is not automatically a preservation system. Self-hosting becomes much easier to reason about when these three jobs are kept separate.</p>
<h2 id="synchronisation-keeps-copies-convenient">Synchronisation keeps copies convenient</h2>
<p>Synchronisation keeps data available on more than one device. Syncthing is useful for this kind of direct device synchronisation, and it makes working files available where I need them.</p>
<p>But synchronisation also copies mistakes. If a file is deleted, corrupted or encrypted, that change may travel to the other copy. Synchronisation improves availability; it does not replace a backup.</p>
<h2 id="a-backup-gives-you-a-recovery-point">A backup gives you a recovery point</h2>
<p>A backup is a separate copy that can take you back to an earlier state. It should be protected from the normal failure of the source and should be possible to restore without relying on memory.</p>
<p>For my homelab, that means thinking about:</p>
<ul>
<li>what data is included;</li>
<li>how often it is copied;</li>
<li>how long old versions are retained;</li>
<li>whether credentials are protected;</li>
<li>whether the backup is encrypted;</li>
<li>whether the restore procedure has been tested.</li>
</ul>
<p>Restic is useful for encrypted, verifiable backup jobs, but the tool alone does not create a complete backup strategy. The source paths, schedule, retention and restore test matter just as much.</p>
<h2 id="preservation-keeps-meaning-and-access">Preservation keeps meaning and access</h2>
<p>Preservation is a longer-term job. It is not only about keeping bytes. It also means retaining enough context to understand what the files are, checking that they have not silently changed, using formats that remain practical to read, and keeping more than one recovery path.</p>
<p>For web material, a saved URL is not preservation. The page may change or disappear. Tools such as <a href="https://github.com/ArchiveBox/ArchiveBox">ArchiveBox</a> can create local captures, while larger institutional workflows such as <a href="https://www.archivematica.org/en/">Archivematica</a> show how preservation involves ingest, processing, metadata and access.</p>
<h2 id="a-simple-test">A simple test</h2>
<p>For each important item, ask three questions:</p>
<ol>
<li><strong>Do I need it available on another device?</strong> That is synchronisation.</li>
<li><strong>Do I need to recover an older version after loss or damage?</strong> That is backup.</li>
<li><strong>Do I need to understand and access it years from now?</strong> That is preservation.</li>
</ol>
<p>The same file may need all three, but the design is different for each job.</p>
<h2 id="how-this-applies-to-my-lab">How this applies to my lab</h2>
<p>The live data on TrueNAS-Normandy is the working copy. Replication to another system can provide another local recovery path, but it should not be treated as the only backup. Restic configuration backups protect the information needed to rebuild services, while service data and databases need their own explicit inclusion and restore plans.</p>
<p>The most important question is not “Where is the copy?” It is:</p>
<blockquote>
<p>Can I prove that I can find, understand and restore the thing I care about?</p></blockquote>
<p>That is the difference between having copies and having a recovery system.</p>
]]></content:encoded>
    </item>
  </channel>
</rss>
