https://bugs.dragonflybsd.org/https://bugs.dragonflybsd.org/favicon.ico?16293952082011-08-30T08:22:32ZDragonFlyBSD bugtrackerDragonFlyBSD - Bug #2123: hammer is losing fileshttps://bugs.dragonflybsd.org/issues/2123?journal_id=100742011-08-30T08:22:32Zdillon
<ul></ul><p>:<br />:I'm trying to use dragonflybsd as a backup server. I'm rsyncing from<br />:multiple remote systems to a dragonfly master. Running ls <del>la in one<br />:of the synced directories in a snapshot gives me "No such file or<br />:directory errors":<br />:<br />:,---</del><br />:| muni# pwd<br />:|<br />:/backup/sync/@@0x000000010fae19c0/wodka-v/pediapress.com/rootfs/usr/share/zoneinfo/posix/Etc<br />:| muni# ls -la<br />:| ls: GMT: No such file or directory<br />:| ls: GMT+0: No such file or directory<br />:| ls: GMT-0: No such file or directory</p>
<pre><code>Where are you getting the transaction id (the @@ id) from? Is it<br /> coming from an official snapshot softlink generated with one of<br /> the hammer snapshot commands?</code></pre>
<pre><code>The fine-grained history can catch inodes and file data out of sync,<br /> but the official snapshots shouldn't.</code></pre>
<pre><code>'hammer snapls &lt;fs&gt;' will list all official snapshots. They should<br /> coinside with the snapshot softlinks placed in /var/hammer (by default).</code></pre>
<pre><code>-Matt<br /> Matthew Dillon <br /> &lt;<a class="email" href="mailto:dillon@backplane.com">dillon@backplane.com</a>&gt;</code></pre> DragonFlyBSD - Bug #2123: hammer is losing fileshttps://bugs.dragonflybsd.org/issues/2123?journal_id=100752011-08-30T08:50:28Zschmir
<ul></ul><p>"Matthew Dillon (via DragonFly issue tracker)" <br /><<a class="email" href="mailto:bugs@crater.dragonflybsd.org">bugs@crater.dragonflybsd.org</a>> writes:</p>
<blockquote>
<p>Matthew Dillon <<a class="email" href="mailto:dillon@apollo.backplane.com">dillon@apollo.backplane.com</a>> added the comment:<br />:<br />:,----<br />:| muni# pwd<br />:|<br />:/backup/sync/@@0x000000010fae19c0/wodka-v/pediapress.com/rootfs/usr/share/zoneinfo/posix/Etc<br />:| muni# ls -la<br />:| ls: GMT: No such file or directory<br />:| ls: GMT+0: No such file or directory<br />:| ls: GMT-0: No such file or directory</p>
<p>Where are you getting the transaction id (the @@ id) from? Is it<br />coming from an official snapshot softlink generated with one of<br />the hammer snapshot commands?</p>
<p>The fine-grained history can catch inodes and file data out of sync,<br />but the official snapshots shouldn't.</p>
<p>'hammer snapls <fs>' will list all official snapshots. They should<br />coinside with the snapshot softlinks placed in /var/hammer (by default).</p>
</blockquote>
<p>The snapshot in question has been created via the daily periodic<br />scripts. It's symlinked in /var/hammer/backup/sync and appears in the<br />hammer snapls output:</p>
<p>`----</p> DragonFlyBSD - Bug #2123: hammer is losing fileshttps://bugs.dragonflybsd.org/issues/2123?journal_id=100792011-08-30T23:46:58Zdillon
<ul></ul><p>:<br />:The snapshot in question has been created via the daily periodic<br />:scripts. It's symlinked in /var/hammer/backup/sync and appears in the<br />:hammer snapls output:</p>
<pre><code>It could have caught the rsync in the middle, though it isn't supposed<br /> to break inode<->file linkages. rsync might be re-creating the hardlinks<br /> on every pass.</code></pre>
<pre><code>Are the other snapshots ok?</code></pre>
<pre><code>The most reliable way is to create a manual snapshot as part of your<br /> rsync script so the snapshot occurs on a quiescent filesystem. Something<br /> like this:</code></pre>
<pre><code>do rsync stuff<br /> sync; sleep 5; sync; sleep 5; sync; sleep 5<br /> hammer snapshot /backup/sync /var/hammer/backup/sync "rsync snapshot" </code></pre>
<pre><code>-Matt<br /> Matthew Dillon <br /> &lt;<a class="email" href="mailto:dillon@backplane.com">dillon@backplane.com</a>&gt;</code></pre> DragonFlyBSD - Bug #2123: hammer is losing fileshttps://bugs.dragonflybsd.org/issues/2123?journal_id=100812011-08-31T02:56:37Zschmir
<ul></ul><p>Matthew Dillon <<a class="email" href="mailto:dillon@apollo.backplane.com">dillon@apollo.backplane.com</a>> writes:</p>
<blockquote>
<p>It could have caught the rsync in the middle, though it isn't supposed<br />to break inode<->file linkages. rsync might be re-creating the hardlinks<br />on every pass.</p>
</blockquote>
<p>rsync is running right before the snapshots are being created, so rsync<br />itself had already exited (however it didn't sync or sleep in betweeen)</p>
<blockquote>
<p>Are the other snapshots ok?</p>
</blockquote>
<p>they are fine.</p>
<blockquote>
<p>The most reliable way is to create a manual snapshot as part of your<br />rsync script so the snapshot occurs on a quiescent filesystem. Something<br />like this:</p>
<p>do rsync stuff<br />sync; sleep 5; sync; sleep 5; sync; sleep 5<br />hammer snapshot /backup/sync /var/hammer/backup/sync "rsync snapshot"</p>
</blockquote>
<p>I do that now and will watch for similar problems.</p>
<p>Thanks for your help.</p>