<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>On 12-Nov-18 14:39, Marcus Frenkel asked about backing up slave
zone files & bind's update mechanism:</p>
<p>I believe you're asking the wrong questions and are likely to run
into complications. You don't know when BIND will merge the
journal, or that rsync will atomically snapshot the zone file and
the journal. So you will get a coherent copy of the the zone file
- but it may be stale. The journal may be earlier or later than
the zone file, or it may be incomplete. This means that a restore
may have the slave serve stale data - until it queries the master
for any updates & if necessary, fixes the journal file. If
the master happens to be down, this is especially suboptimal.<br>
</p>
<p>So I would exclude both files from rsync, and use another
approach to save a coherent copy of the zone file(s) in my backup
procedure.</p>
<p>One approach is to axfr the zone (from the slave, or any other
server) to your backup server.<br>
</p>
<p>You can do that directly with dig, or using a library (e.g.
Perl's Net::DNS). Recent versions of BIND write slave zone files
in a binary format by default. Just pipe the data through
named-compilezone -F when writing the file. This has the
advantage that it doesn't have to run on the slave. (You can pull
the data to your backup server, or push it from a machine other
than the slave.)<br>
</p>
<p>If you are dealing with very large files and/or a slow network
link, you may prefer to use named-compilezone -j to merge the zone
& any journal file into a temporary snapshot & back that
up with rsync. I'm not sure how BIND's binary format interacts
with rsync - it's possible that outputting text format would be
more efficient. You'd have to benchmark to decide.<br>
</p>
<p>If you restore from such a backup, you'll want to delete the
journal file to save named some work when it loads the zone. And,
of course, make sure that named isn't running :-) If you backup
the zone in text format, you can compile it only during restore to
save time at the cost of space. (Backups should be frequent;
restores rare.)<br>
</p>
<p>This assumes that your recovery strategy depends on being able to
restore the slave with the master down.</p>
<p>If you can assume that the master will be up (or restored first),
by far the simplest approach is not backup the zone data (file or
journal) on the slaves at all. This is often the case, since
restoring a master tends to be higher priority than restoring
slaves. To restore, simply start named. If you are restoring
over existing files, delete both zone and journal files first.
Named will notice that it has no data, and will do the axfr(s)
& create the files in fairly short order. Named will spread
the transfers of multiple zones out over time, but you'll want to
do some math to determine if the restore time and impact on your
network are acceptable.<br>
</p>
<p>Although you asked about slaves, note that masters have similar
issues & solutions. Masters will also have journal files if
they do dynamic updates (including for DNSSEC).</p>
<p>For servers which are masters for some zones and slaves for
others, the strategy should be determined per-zone, not per
server.<br>
</p>
<p>The bottom line: backups of databases (and DNS is a distributed
database) are complicated. The best approach depends on the
details of your operational environment -- and not on the minutiae
of BINDs implementation.<br>
</p>
<pre class="moz-signature" cols="72">Timothe Litt
ACM Distinguished Engineer
--------------------------
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed.
</pre>
<div class="moz-cite-prefix">On 12-Nov-18 14:39, Marcus Frenkel
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:%3CCA+X58h7qrNjTufX-gKoMYU11WENM2qijO53DOBS1LSw=Vipj6A@mail.gmail.com%3E">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">Thank you for the quick reply Tony!
<div><br>
</div>
<div>Follow-up questions just to be sure:</div>
<div>1. The new zone file is renamed in the placed of
the old one, only after all changes to the new file
are written?</div>
<div>2. Is the zone file atomically replaced during
the renaming process, in a sense that there is no
window in which the file is empty or non-existent?</div>
<div><br>
</div>
<div>I'm running BIND on Debian 9. Based on <a
href="http://man7.org/linux/man-pages/man2/rename.2.html"
target="_blank" moz-do-not-send="true">this</a>
Linux man page, the rename function should be
atomic. I would not imagine that BIND does it in
different way, like the worst case scenario to first
remove the current file and then move the new one to
the same path. I know I'm too cautious, I'm just
trying to avoid any chance for rsync to transfer
incomplete or empty zone file, or maybe delete the
file at the destination if it does not exist at the
source for a short moment.<br>
</div>
<div><br>
</div>
<div>Marcus</div>
<div><br>
<div class="gmail_quote">
<div dir="ltr">On Mon, Nov 12, 2018 at 7:19 PM
Tony Finch <<a href="mailto:dot@dotat.at"
target="_blank" moz-do-not-send="true">dot@dotat.at</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px
0px 0px 0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">Marcus
Frenkel <<a
href="mailto:marcus.frenkel@gmail.com"
target="_blank" moz-do-not-send="true">marcus.frenkel@gmail.com</a>>
wrote:<br>
><br>
> I need to know how BIND writes to slave
zone files after zone has been<br>
> updated. Does it modify the file in place
or it replaces the file with<br>
> new one at once?<br>
<br>
Changes are written to a journal append-only
style. Every so often the<br>
master file is rewritten to incorporate the
contents of the journal; this<br>
is done by writing to a new file and renaming it
in place of the old one.<br>
<br>
Tony.<br>
-- <br>
f.anthony.n.finch <<a
href="mailto:dot@dotat.at" target="_blank"
moz-do-not-send="true">dot@dotat.at</a>> <a
href="http://dotat.at/" rel="noreferrer"
target="_blank" moz-do-not-send="true">http://dotat.at/</a><br>
sovereignty rests with the people and authority<br>
in a democracy derives from the people<br>
</blockquote>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</body>
</html>