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