1<?xml version="1.0" encoding="UTF-8" standalone="no"?>
2<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
3<html xmlns="http://www.w3.org/1999/xhtml">
4  <head>
5    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
6    <title>Backup Procedures</title>
7    <link rel="stylesheet" href="gettingStarted.css" type="text/css" />
8    <meta name="generator" content="DocBook XSL Stylesheets V1.73.2" />
9    <link rel="start" href="index.html" title="Getting Started with Berkeley DB Transaction Processing" />
10    <link rel="up" href="filemanagement.html" title="Chapter��5.��Managing DB Files" />
11    <link rel="prev" href="filemanagement.html" title="Chapter��5.��Managing DB Files" />
12    <link rel="next" href="recovery.html" title="Recovery Procedures" />
13  </head>
14  <body>
15    <div class="navheader">
16      <table width="100%" summary="Navigation header">
17        <tr>
18          <th colspan="3" align="center">Backup Procedures</th>
19        </tr>
20        <tr>
21          <td width="20%" align="left"><a accesskey="p" href="filemanagement.html">Prev</a>��</td>
22          <th width="60%" align="center">Chapter��5.��Managing DB Files</th>
23          <td width="20%" align="right">��<a accesskey="n" href="recovery.html">Next</a></td>
24        </tr>
25      </table>
26      <hr />
27    </div>
28    <div class="sect1" lang="en" xml:lang="en">
29      <div class="titlepage">
30        <div>
31          <div>
32            <h2 class="title" style="clear: both"><a id="backuprestore"></a>Backup Procedures</h2>
33          </div>
34        </div>
35      </div>
36      <div class="toc">
37        <dl>
38          <dt>
39            <span class="sect2">
40              <a href="backuprestore.html#copyutilities">About Unix Copy Utilities</a>
41            </span>
42          </dt>
43          <dt>
44            <span class="sect2">
45              <a href="backuprestore.html#standardbackup">Offline Backups</a>
46            </span>
47          </dt>
48          <dt>
49            <span class="sect2">
50              <a href="backuprestore.html#hotbackup">Hot Backup</a>
51            </span>
52          </dt>
53          <dt>
54            <span class="sect2">
55              <a href="backuprestore.html#incrementalbackups">Incremental Backups</a>
56            </span>
57          </dt>
58        </dl>
59      </div>
60      <p>
61            <span class="emphasis"><em>Durability</em></span> is an important part of your
62            transactional guarantees. It means that once a transaction has been
63            successfully committed, your application will always see the results of that
64            transaction. 
65        </p>
66      <p>
67            Of course, no software algorithm can guarantee durability in the face of physical data loss.  Hard drives
68            can fail, and if you have not copied your data to locations other than your primary disk drives,
69            then you will lose data when those drives fail.  Therefore, in order to truly obtain a durability
70            guarantee, you need to ensure that any data stored on disk is backed up to secondary or alternative storage,
71            such as secondary disk drives, or offline tapes.
72        </p>
73      <p>
74            There are three different types of backups that you can
75            perform with DB databases and log files.  They are:
76        </p>
77      <div class="itemizedlist">
78        <ul type="disc">
79          <li>
80            <p>
81                    Offline backups
82                </p>
83            <p>
84                    This type of backup is perhaps the easiest to perform as it
85                    involves simply copying database and log files to an
86                    offline storage area. It also gives you a snapshot of the
87                    database at a fixed, known point in time. However, you
88                    cannot perform this type of a backup while you are performing 
89                    writes to the database.
90                </p>
91          </li>
92          <li>
93            <p>
94                    Hot backups
95                </p>
96            <p>
97                    This type of backup gives you a snapshot of your database.
98                    Since your application can be writing to the database at the time that the
99                    snapshot is being taken, you do not necessarily know what
100                    the exact state of the database is for that given snapshot.
101                </p>
102          </li>
103          <li>
104            <p>
105                    Incremental backups
106                </p>
107            <p>
108                    This type of backup refreshes a previously performed backup.
109                </p>
110          </li>
111        </ul>
112      </div>
113      <p>
114            Once you have performed a backup, you can
115            perform <span class="emphasis"><em>catastrophic recovery</em></span> to restore
116            your databases from the backup. See
117            <a class="xref" href="recovery.html#catastrophicrecovery" title="Catastrophic Recovery">Catastrophic Recovery</a>
118            for more information.
119        </p>
120      <p>
121            Note that you can also maintain a hot failover. See
122            <a class="xref" href="hotfailover.html" title="Using Hot Failovers">Using Hot Failovers</a>
123            for more information.
124        </p>
125      <div class="sect2" lang="en" xml:lang="en">
126        <div class="titlepage">
127          <div>
128            <div>
129              <h3 class="title"><a id="copyutilities"></a>About Unix Copy Utilities</h3>
130            </div>
131          </div>
132        </div>
133        <p>
134
135               If you are copying database files you must copy databases atomically, 
136               in multiples of the database page size. In other words, the reads made by
137               the copy program must not be interleaved with writes by
138               other threads of control, and the copy program must read the
139               databases in multiples of the underlying database page size.
140               Generally, this is not a problem because operating systems
141               already make this guarantee and system utilities normally
142               read in power-of-2 sized chunks, which are larger than the
143               largest possible Berkeley DB database page size. 
144            </p>
145        <p>
146                On some platforms (most notably, some releases of Solaris), the copy utility (<code class="literal">cp</code>) was
147                implemented using the <code class="function">mmap()</code> system call rather than the
148                <code class="function">read()</code> system call. Because <code class="function">mmap()</code> did not make the same
149                guarantee of read atomicity as did <code class="function">read()</code>, the <code class="literal">cp</code> utility
150                could create corrupted copies of the databases. 
151            </p>
152        <p>
153                Also, some platforms have implementations of the <code class="literal">tar</code> utility that performs 10KB block
154                reads by default. Even when an output block size is specified, the utility will still not read the
155                underlying databases in multiples of the specified block size. Again, the result can be a corrupted backup.
156            </p>
157        <p>
158                To fix these problems, use the <code class="literal">dd</code> utility instead of <code class="literal">cp</code> or
159                <code class="literal">tar</code>. When you use <code class="literal">dd</code>, make sure you specify a block size that is
160                equal to, or an even multiple of, your database page size. Finally, if you plan to use a system
161                utility to copy database files, you may want to use a system call trace utility (for example, 
162                <code class="literal">ktrace</code> or <code class="literal">truss</code>) to make sure you are not using a I/O size that is
163                smaller than your database page size. You can also use these utilities to make sure the system utility is
164                not using a system call other than <code class="function">read()</code>.
165            </p>
166      </div>
167      <div class="sect2" lang="en" xml:lang="en">
168        <div class="titlepage">
169          <div>
170            <div>
171              <h3 class="title"><a id="standardbackup"></a>Offline Backups</h3>
172            </div>
173          </div>
174        </div>
175        <p>
176                To create an offline backup:
177            </p>
178        <div class="orderedlist">
179          <ol type="1">
180            <li>
181              <p>
182                        Commit or abort all on-going transactions.
183                    </p>
184            </li>
185            <li>
186              <p>
187                        Pause all database writes.
188                    </p>
189            </li>
190            <li>
191              <p>
192                        Force a checkpoint. See 
193                            <a class="xref" href="filemanagement.html#checkpoints" title="Checkpoints">Checkpoints</a>
194                        for details.
195                    </p>
196            </li>
197            <li>
198              <p>
199                        Copy all your database files to the backup location. 
200                        <span>
201                            Note that you can simply copy all of the database
202                            files, or you can determine which database files
203                            have been written during the lifetime of the current
204                            logs. To do this, use either the
205                                <span>
206                                    <code class="methodname">DB_ENV-&gt;log_archive()</code>
207                                    
208                                    method with the <code class="literal">DB_ARCH_DATA</code>
209                                    option, 
210                                </span>
211                                
212
213                                or use the <span class="command"><strong>db_archive</strong></span>
214                                command with the <code class="literal">-s</code> option. 
215                        </span>
216                    </p>
217              <p>
218                        However, be aware that backing up just the modified databases only works if you have all of your
219                        log files. If you have been removing log files for any reason then using
220                                <span>
221                                    <code class="methodname">log_archive()</code>
222                                </span>
223                                
224
225                        can result in an
226                        unrecoverable backup because you might not be notified of a database file that was modified. 
227                    </p>
228            </li>
229            <li>
230              <p>
231                        Copy the <span class="emphasis"><em>last</em></span> log file to your backup location.
232                        Your log files are named
233                        <code class="literal">log.<span class="emphasis"><em>xxxxxxxxxx</em></span></code>,
234                        where <span class="emphasis"><em>xxxxxxxxxx</em></span> is a
235                        sequential number. The last log file is the file
236                        with the highest number.
237                    </p>
238            </li>
239          </ol>
240        </div>
241      </div>
242      <div class="sect2" lang="en" xml:lang="en">
243        <div class="titlepage">
244          <div>
245            <div>
246              <h3 class="title"><a id="hotbackup"></a>Hot Backup</h3>
247            </div>
248          </div>
249        </div>
250        <p>
251                To create a hot backup, you do not have to stop database
252                operations. Transactions may be on-going and you can be writing
253                to your database at the time of the backup. However, this means
254                that you do not know exactly what the state of your database is
255                at the time of the backup.
256            </p>
257        <p>
258                You can use the <span class="command"><strong>db_hotbackup</strong></span> command line utility to create a hot backup for you. This
259                utility will (optionally) run a checkpoint and the copy all necessary files to a target directory.
260            </p>
261        <p>
262                Alternatively, you can manually create a hot backup as follows:
263            </p>
264        <div class="orderedlist">
265          <ol type="1">
266            <li>
267              <p>
268                        Copy all your database files to the backup location. 
269                        <span>
270                            Note that you can simply copy all of the database
271                            files, or you can determine which database files
272                            have been written during the lifetime of the current
273                            logs. To do this, use either the
274                                <span>
275                                    <code class="methodname">DB_ENV-&gt;log_archive()</code>
276                                    
277                                    with the <code class="literal">DB_ARCH_DATA</code>
278                                    option, 
279                                </span>
280                                
281
282                                or use the <span class="command"><strong>db_archive</strong></span>
283                                command with the <code class="literal">-s</code> option. 
284                        </span>
285                    </p>
286            </li>
287            <li>
288              <p>
289                        Copy all logs to your backup location.
290                    </p>
291            </li>
292          </ol>
293        </div>
294        <div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
295          <h3 class="title">Note</h3>
296          <p>
297                    It is important to copy your database files <span class="emphasis"><em>and
298                    then</em></span> your logs. In this way, 
299                    you can complete or roll back any database operations that were only partially completed 
300                    when you copied the databases. 
301                </p>
302        </div>
303      </div>
304      <div class="sect2" lang="en" xml:lang="en">
305        <div class="titlepage">
306          <div>
307            <div>
308              <h3 class="title"><a id="incrementalbackups"></a>Incremental Backups</h3>
309            </div>
310          </div>
311        </div>
312        <p>
313                Once you have created a full backup (that is, either a
314                offline or hot backup), you can create incremental backups.  
315                To do this, simply copy all of your currently existing log
316                files to your backup location. 
317            </p>
318        <p>
319                Incremental backups do not require you to run a checkpoint
320                or to cease database write operations. 
321            </p>
322        <p>
323                When you are working with incremental backups, remember
324                that the greater the number of log files contained in 
325                your backup, the longer recovery will take.  
326                You should run full backups
327                on some interval, and then do incremental backups on a shorter interval.
328                How frequently you need to run a full backup
329                is determined by the rate at which your databases change and
330                how sensitive your application is to lengthy recoveries
331                (should one be required).
332              </p>
333        <p>
334                You can also shorten recovery time by running recovery against the backup as you take each incremental
335                backup.  Running recovery as you go means that there will be less work for DB to do if you should
336                ever need to restore your environment from the backup.
337            </p>
338      </div>
339    </div>
340    <div class="navfooter">
341      <hr />
342      <table width="100%" summary="Navigation footer">
343        <tr>
344          <td width="40%" align="left"><a accesskey="p" href="filemanagement.html">Prev</a>��</td>
345          <td width="20%" align="center">
346            <a accesskey="u" href="filemanagement.html">Up</a>
347          </td>
348          <td width="40%" align="right">��<a accesskey="n" href="recovery.html">Next</a></td>
349        </tr>
350        <tr>
351          <td width="40%" align="left" valign="top">Chapter��5.��Managing DB Files��</td>
352          <td width="20%" align="center">
353            <a accesskey="h" href="index.html">Home</a>
354          </td>
355          <td width="40%" align="right" valign="top">��Recovery Procedures</td>
356        </tr>
357      </table>
358    </div>
359  </body>
360</html>
361