File: Tutorial.html

package info (click to toggle)
dar 2.8.1-3
links: PTS, VCS
area: main
in suites: forky, sid
size: 12,024 kB
sloc: cpp: 86,219; sh: 6,978; ansic: 895; makefile: 489; python: 242; csh: 115; perl: 43; sed: 16
file content (1180 lines) | stat: -rw-r--r-- 47,795 bytes
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <link href="style.css" rel="stylesheet">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <meta content="text/html; charset=ISO-8859-1" http-equiv="content-type">
    <title>DAR - Tutorial</title>
  </head>
  <body>

    <div class=top>
      <img alt="Dar Documentation" src="dar_s_doc.jpg" style="float:left;">
      <h1>Tutorial</h1>
    </div>

    <h2>Introduction</h2>

    <p>
      This tutorial shows you <u>how to backup</u>
      your file system (partially or
      totally) on USB key (thing works the same with harddisks or cloud
      storage), but we will keep USB keys for simplicity. Most important, we
      will also see <u>how to restore</u>
      your system from scratch in case of hard disk failure (or other cataclysms).
    </p>

    <i>
      <dl>
	<dt class=void>Note:</dt><dd>
	  This document has been initially written circa 2003, so don't pay
	  attention to the usage of old hardware it mentions, the dar usage stay
	  the same with modern removable media or cloud storage, and the document
	  has been updated with recent features as if those old stuffs were still
	  of actuality :-)
	</dd>
      </dl>
    </i>

    <p>
      In the following, for each feature we will use, you will find the description of
      what it does followed by the way to activate it both using its
      <code>the long options</code> and its <code>the short option</code>.
      Of course, that's up to you to use <u>either</u> the short or the
      long opton (but not both at the same time for a particular feature).
      Short option begin by a single dash (-) and have only a single letter to identify them
      like <code>-s</code>. Long option begins with two dashes (--) and usually
      have a descriptive word to identify them: <code>--slice</code>.
    </p>
    <p>
      Short and long option may have <b>no argument</b> (<code>-D</code>),
      may have a <b>mandatory argument</b> which is the word following the option (<code>-s 1M</code>)
      and some rare ones may have an <b>optional argument</b>, leading the option to either
      be alone <code>-z</code> or sticked with its optional argument <code>-zlz4</code>, which
      for long option is done by mean of the equal signe (=): <code>--compression=lz4</code>
    </p>

    <h2>The FULL backup</h2>

    <p>
      We need first to make a full backup, let's go:
    </p>
    <ul>
      <li>
	<p>
	  Let's assume the size of the usb keys is 100 MiB, we ask dar to
	  split the backup in many files (also known as <i>slices</i>) of 100 MiB:
	  <b><code> --slice 100M</code> or <code>-s 100M</code></b>.
	</p>
      </li>
      <li>
	<p>
	  On your first usb key drive we want to copy the dar binary outside the
	  backup to be able to restore it in case of hard disk failure, for
	  example.
	</p>
	<dl>
	  <dt class=void>IMPORTANT:</dt><dd>
	    dar binary relies on several libraries which must also be available in
	    the rescue system or copied with the dar binary. But, if you don't want
	    to worry about needed libraries, there is a static version of dar which
	    only difference is that it has all required library included in it
	    (thus it is a larger binary). Its name is <b>dar_static</b>,
	    and its main reason of existence is to be placed beside backups in case
	    something goes wrong in your system. Note that <i>dar_static</i> is useless
	    for windows, you will always need the <a href="http://cygwin.com/">Cygwin</a>
	    dll.
	  </dd>
	</dl>
	<p>
	  You can also add man pages or a copy of this tutorial, if you are scared
	  not to be able to
	  remember all the many feature of dar ;-) while find the <code>-h</code> or
	  <code>--help</code> option too
	  sparse. Note that all the dar documentation is available on the web. OK
	  you need an Internet access to read it.
	</p>
	<p>
	  This make the free space on the first usb key a bit smaller, I let
	  you make the substraction because this is subject to change from system
	  to system, but let's assume dar_static is less than 5 MiB, thus the
	  initial slice should not exceed 95 MB:
	  <b><code>--first-slice 95M</code> or <code>-S 95M</code></b>.
	  (Note that '-s' is lowercase for all the slices, and '-S' is UPPERCASE
	  meaning the initial slice only).
	</p>
      </li>
      <li>
	<p>
	  We need to pause between slices to change the usb key when it is
	  full: <b><code>--pause</code> or <code>-p</code></b>
	</p>
      </li>
      <li>
	<p>
	  As we don't want to stick in front of the screen during the backup,
	  we ask dar to to ring the terminal bell when user action is needed:
	  <b><code>--beep</code> or <code>-b</code></b>
	</p>
      </li>
      <li>
	<p>
	  We will compress data inside the backup:
	  <b><code>--compression</code> or <code>-z</code></b>.
	</p>
	<p>
	  by default <code>-z</code> option uses gzip compression algorithm
	  (gzip, bzip2, lzo, xz, lz4, zstd, and some others are
	  also available). Optionally, if speed is more important than archive
	  size, you can degrade compression specifying the compression level:
	  <code>-z1</code> for example for gzip, or <code>-zxz:5</code> for
	  compression level 5 with xz algorithm.
	  By default the maximum compression is used (<code>-z</code>
	  is equivalent to <code>-zgzip:9</code>)
	</p>
      </li>
      <li>
	<p>
	  Now, we want to backup the whole file system.
	  <b><code>--fs-root /</code> or <code>-R /</code></b>
	</p>
	<p>
	  This tells dar that no files out of the provided directory tree will be
	  saved. Here, it means that no files will be excluded from the backup,
	  if no filter is specified, see below)
	</p>
      </li>
      <li>
	<p>
	  There are some files you probably don't want to save, like backup files
	  generated by emacs <code>"*~"</code> and <code>".*~"</code>:
	  <b><code>--exclude "*~" --exclude ".~*"</code> or <code>-X "*~" -X ".*~"</code></b>
	</p>
	<p>
	  Note that you have to quote the mask for it not to be interpreted by
	  the shell, the <code>-X</code> options do not apply to directories,
	  nor to path, they just apply to filenames. See also the opposite
	  <code>-I</code> option (<code>--include</code>) in man page for more information.
	</p>
      </li>
      <li>
	<p>
	  Among these files are several sub-trees you must not save: the <code>/proc</code>
	  file system for example, as well as the <code>/dev</code> and <code>/sys</code>.
	  These are virtual filesystems, saving them would only make your backup bigger filled
	  with useless stuff:
	  <b><code>--prune dev --prune proc --prune sys</code> or <code>-P dev -P proc -P sys</code></b>
	</p>
	<p>
	  Note that path must be relative to <code>-R</code> option (thus no leading '/' must
	  be used) Unlike the -X/-I options, the -P option applies to full file path+names. If
	  a directory matches -P option, all its subdirectory will also be
	  excluded. note also that -P can receive wildcards, and they must be
	  quoted not to be interpreted by the shell: <code>-P "home/*/.mozilla/cache"</code>
	  for example. Lastly, -P can also be used to exclude a plain file (if
	  you don't want to exclude all files of a given name using -X option):
	  <code>-P home/joe/.bashrc</code> for example would only exclude joe's .bashrc file
	  not any other file, while <code>-X .bashrc</code> would exclude any file of that name
	  including joe's file. See also <code>-g</code>, <code>-[</code> and <code>-]</code>
	  options in man page for more, as well as the "file selection in brief" paragraph
	</p>
      </li>
      <li>
	<p>
	  More importantly we must not save the backup itself:
	  <b><code>--prune mnt/usr</code> or <code>-P mnt/usb</code></b>
	</p>
	<p>
	  assuming that your usb key is mounted under /mnt/usb. We could also have
	  excluded all files of extension "dar" which are backup generated by
	  dar using <code>-X "*.*.dar"</code>, but this would have also exclude
	  other dar archive from the backup, which may not always fit your need.
	</p>
      </li>
      <li>
	<p>
	  Now, as we previously excluded the /dev/pts /proc and /mnt/usb directories, we
	  would have to create these directory mount-points by hand at recovery
	  time to be able to mount the corresponding filesystems. But we can
	  better use the -D option: it changes dar's behavior by not totally
	  ignoring excluded directories (whatever is the feature used to exclude them)
	  but rather storing them as empty directory in the backup:
	  <b><code>--empty-dir</code> or <code>-D</code></b>
	</p>
	<p>
	  Thus at recovery time excluded directories will be generated automatically
	  as an empty directories
	</p>
      </li>
      <li>
	<p>
	  Last, we have to give a name to this full backup. Let's call it
	  "linux_full" and as it is supposed to take place on the usb key, its path
	  will be /mnt/usb/linux_full:
	  <b><code>--create /mnt/usb/linux_full</code> or <code>-c /mnt/usb/linux_full</code></b>
	</p>
	<p>
	  Note that <i>linux_full</i> is not a complete filename, it is a "basename", on
	  which dar will add a number and the ".dar" extension, this way the first
	  slice will be a file of name <i>linux_full.1.dar</i> located in /mnt/usb
	</p>
      </li>
    </ul>
    <p>
      Now, as we will have to mount and umount the /mnt/usb file system, we
      must not have any process using it, in particular, dar current
      directory must no be /mnt/usb so we change to / for example.
    </p>
    <p>
      All together we follow this procedure for our example:
    </p>
    <ul>
      <li>
	<p>
	  Plug an empty usb key and mount it according to your /etc/fstab file.
	</p>
	<code class=block>
	  mount /mnt/usb
	</code>
      </li>
      <li>
	<p>
	  Copy the dar binary to the first usb key (to be able to restore in case of
	  big problem, like a hard disk failure) and eventually man pages and/or
	  this tutorial.
	</p>
	<code class=block>
	  cp `which dar_static` /mnt/usb
	</code>
      </li>
      <li>
	<p>
	  then, type the following:
	</p>
	<code class=block>
	  cd /
	  dar -c /mnt/usb/linux_full -s 100M -S 95M -p -b -z -R / -X "*~" -X ".*~" -P dev/pts -P sys -P proc -P mnt/usb -D
	</code>
	<p>
	  Note that option order has no importance. Some options may be used
	  several times (-X, -I, -P) some others cannot (see man page for more).
	</p>
      </li>
      <li>
	<p>
	  When the first slice will be done, DAR will pause, ring the terminal bell and display a
	  message. You will have to unmount the usb key:
	</p>
	<code class=block>
	  umount /mnt/usb
	</code>
      </li>
      <li>
	<p>
	  and replace it by an empty new one and mount it:
	</p>
	<code class=block>
	  mount /mnt/usb
	</code>
      </li>
    </ul>
    <p>
      To be able to do that, you can swap to another virtual console pressing
      ALT+F? keys (if under Linux), or open another xterm if under X-Windows, or suspend dar
      by typing CTRL-Z and reactivating it after mounting/unmounting by
      typing `fg' (without the quotes).
    </p>
    <p>
      Then proceed with dar for the next slice, pressing the &lt;enter&gt; key.
      Dar will label slices this way:
    </p>
    <ul>
      <li>slice 1: linux_full.1.dar</li>
      <li>slice 2: linux_full.2.dar</li>
      <li>and so on.</li>
    </ul>
    <p>
      <b>That's it! We have finished the first step: the backup</b>,
      it may take a long time depending on the size of the data to backup.
      The following step
      (differential backup) however can be done often, and it will stay fast
      every time (OK, except if a big part of your system has changed, in
      that case you can consider making another full backup).
    </p>

    <h2>Test your Backups!</h2>
    <p>
      There is so many reason a backup can be useless, it may be human error,
      saturated disk, lack of permission, and so on. The best test is to
      restore the data at least once. But there are some more quick way (though
      less exhaustive) to test a backup:
    </p>
    <h3>Check the backup content</h3>
    <p>
      This one is usually quick, you know the backup is readable but have to
      verify that all expected files are present in the output:
    </p>
    <code class=block>
      dar -l /mnt/usb/linux_full
    </code>
    <h3>Testing the backup</h3>
    <p>
      One step further you can let dar try to restore everything without effectively
      restoring anything, (this mimics the <code>cat > /dev/null</code> paradigm).
      Doing so you validate the data and metadata of all files is not corrupted.
      This is usually a good thing to add in your backup script (or more generally your
      backup process):
    </p>
    <code class=block>
      dar -t /mnt/usb/linux_full
    </code>
    <p>
      If using removable media of poor quality, it is
      recommended to first unmount and remount removable disk, this to flush
      the system cache. Else you may read data from cache (in memory) and do not detect
      an error on you disk. <code>dar -t</code> cannot check a single slice, it checks
      all the archive. If you need to check a single slice, (for example after
      burning it on DVD-RW, you can use the diff command: for example, you
      have burnt the last completed slices on DVD-RW, but have just enough free space to
      store one slice on disk. You can thus check the slice typing something
      like this:
    </p>
    <code class=block>
      diff /mnt/cdrom/linux_full.132.dar /tmp/linux_full.132.dar
    </code>
    <p>
      You can also add the <code>--hash</code> command when you create the
      backup (for example <code>--hash md5</code>),
      it will produce for each slice a small hash file named after the slice name
      "linux_full.1.dar.md5", "linux_full.2.dar.md5", etc. Then using the
      unix standard command "md5sum" you can check the integrity of the slice:
    </p>
    <code class=block>
      md5sum -c linux_full.1.dar.md5
    </code>
    <p>
      If all is ok for the slice on target medium (diff does not complain
      or md5sum returns "OK"), you can continue for dar to proceed with the
      next slice.
    </p>
    <h3>Compare the backup content with filesystem</h3>
    <p>
      instead of testing the whole archive you could also compare it with the
      just saved system:
    </p>
    <code class=block>
      dar -d /mnt/usb key/linux_full -R /
    </code>
    <p>
      This will compare the archive with filesystem tree located at / .
      Same remark as previously, it is recommended to first unmount and
      mount the removable media to flush the system cache.
    </p>
    <p>
      If you backup a live filesystem, you may prefer 'testing' an archive as
      it will not issue errors about files that changed since the backup was
      made, but if you are archiving files, diffing is probably a better idea
      as you really compare the content of the files and you should not
      experiment file changes on data you are archiving as most of the time
      such data about to be archived is old steady data that is not likely to
      change.
    </p>

    <h2>Differential backups</h2>

    <p>
      The only thing to add is the base name of the backup we take as reference:
      <b><code>--ref /mnt/usb/linux_full</code> or <code>-A /mnt/usb/linux_full</code></b>
    </p>
    <p>
      Of course, we have to choose another name for that new backup, let's call
      it <i>linux_diff1</i>:
      <b><code>--create /mnt/usb/linux_diff1</code> or <code>-c /mnt/usb/linux_diff1</code></b>
    </p>
    <p>
      Last point: if you want to put the new backup at the end of the full
      backup, you will have to change the <code>-S</code> option according to the
      remaining space on the last usb key. suppose the last slice of linux_full takes 34MB
      you have 76MB available for the first slice of the differential backup
      (and always 100MB for the following ones):
      <b><code>--first-slice 76M</code> or <code>-S 76M</code></b>
    </p>
    <p>
      but if you want to put the backup on a new usb key, just forget the -S
      option.
    </p>
    <p>
      here we also want to produce a hash file to test each slice integrity before
      removing it from hard disk (md5, sha1, sh512 are the available hash algorithm today):
      <b><code>--hash md5</code> or <code>-3 md5</code></b>
    </p>
    <p>
      All together we get:
    </p>
    <code class=block>
      dar -c /mnt/usb/linux_diff1 -A /mnt/usb key/linux_full -s 100M -S 76M -p -b -z -R / -X "*~" -X ".*~" -P dev/pts -P proc -P mnt/usb key -P sys -D --hash md5
    </code>
    <p>
      The only new point is that, just before effectively starting
      to backup, dar will ask for the last slice of the
      archive of reference (linux_full), then dar will pause (thanks to the
      -p option) for you to change the disk if necessary and put the one where you want to
      write the new backup's first slice, then pause again for you to change
      the disk for the second slice and so on.
    </p>

    <h3>Endless Differential Backups</h3>
    <p>
      You can make another differential backup, taking linux_diff1 as reference
      (which is called an <b>incremental backup</b>, while a <b>differential backup</b>
      has always the a full backup as reference).
      In this case you would change only the following:
      <code>-c /mnt/usb/linux_diff2 -A /mnt/usb key/linux_diff1</code>
    </p>
    <p>
      You could also decide to change of device, taking 4,4 GiB DVD-RAM...
      or maybe rather something more recent and bigger if you
      want, this would not cause any problem at all.
    </p>
    <p>
      After some time
      when you get many incremental backups for a single full backup, you will
      have to make a new full backup, depending on your available time for
      doing it, or on your patient if one day you have to recover the whole
      data after a disk crash: You would then have to restore the full
      backup, then all the following incremental backup up to the most
      recent one. This requires more user intervention than restoring a
      single full backup, all is a matter of balance, between the time it
      takes to backup and the time it takes to restore.
    </p>
    <p>
      Note, that starting with release 1.2.0 a new command appeared that helps
      restoring a few files from a lot a differential backup.
      Its name is <b>dar_manager</b>.
      See at the end of this tutorial and the associated man page for
      more.
    </p>
    <p>
      Another solution, is when you have too much incremental backup, is to
      make the next backup a <b>differential backup</b> taking the last full_backup
      as reference, instead of the last differential backup done. This way, it
      will take less time than doing a full backup, and you will not have to
      restore all intermediate differential backup.
    </p>
    <p>
      For dar, there is not difference in structure between a <i>differential backup</i>
      (having a full backup as reference) and an <i>incremental backup</i> (having a
      differential or another incremental backup as reference). This is just the
      way you chose the backup of reference that let you use two different words naming
      differently what dar considers of the the kind.
    </p>
    <p>
      Of course, a given backup can be used as reference for several
      differential backup, there is no limitation in number nor in nature
      (the reference can be a full of differential backup).
    </p>
    <p>
      Yet another solution is to setup <b>decremental backups</b>,
      this is let you have the full backup as the most recent one and the older ones as
      difference from the backup done just after them... but nothing is
      perfect, doing so takes much more time than doing full backup at each
      step but as less storage space as doing incremental backups and restoration
      time is as simple as restoring a full backup. here too all is
      a matter of choice, taste and use case.
    </p>

    <h2>Recovering after a disk crash</h2>

    <p>
      Sorry, it arrived, your old disk has
      crashed. OK, you are happy because you have now a good argument to buy
      the very fast and very enormous very lastest hard disk available. Usually,
      you also cry because you have lost data and you will have to reinstall
      all your system, that was working&nbsp; so well and for so long!
    </p>
    <p>
      If however the last backup you made is recent, then keep smiling! OK,
      you have installed your new hard disk and configured you BIOS to it
      (well at ancient time it was necessary to manually setup the BIOS with the new disk,
      today you can forget it).
    </p>
    <ol>
      <li>
	<p>
	  You first need to boot your new computer with the empty disk in
	  order to restore your data onto it. For that I would advise using
	  <a href="http://www.knoppix.org/">Knoppix</a> or better
	  <a href="http://www.system-rescue-cd.org/">system rescue CD</a>
	  that let you boot from CD or USB key. You don't
	  need to install something on your brand-new disk, just make partitions
	  and format them as you want (we will detail that below). You may even
	  change the partition layout add new ones or merge several ones into a single one:
	  what is important is that you setup each one with enough space to hold
	  the data to be restored in them: We suppose your new disk is /dev/sda
	  and /dev/sdb is your removable media drive (USB key, DVD device, ...)
	  For clarity, in the following we will keep assuming it to be a set of USB keys,
	  it could be CD, DVD, or other disk you would do slightly the same.
	</p>
      </li>
      <li>
	<p>
	  Create the partition table as you wish, using
	  <code>fdisk /dev/sda</code> or <code>gdisk /dev/sda</code> for a
	  more versatil and modern partition table.
	</p>
      </li>
      <li>
	<p>
	  Format the partition which will receive your data, dar is filesystem
	  independent, you can use ext2 (as here in the example), ext3, ext4,
	  ReiserFS, Minix, UFS, HFS Plus, XFS, whatever is the Unix-like
	  filesystem you want, even if the backed up data did not reside on such
	  filesystem at backup time!
	  <code>mke2fs /dev/sda1</code>
	</p>
      </li>
      <li>
	<p>
	  copy and record in a temporary file the UUID of the generated filesystem if
	  the /etc/fstab we will restore in the next steps rely in that instead
	  of fixed path (like /dev/sda1 or /dev/mapper/...). You can also
	  retrieve the UUID calling <code>blkid</code>
	</p>
      </li>
      <li>
	<p>
	  Additionally if you have created it, format the swap partition
	  and also record the generated UUID if necessary:
	  <code>mkswap -c /dev/sda2</code>
	</p>
      </li>
      <li>
	<p>
	  If you have a lot of file to restore, you can activate the swap
	  on the partition of your new hard drive:
	  <code>swapon /dev/sda2</code>
	</p>
      </li>
      <li>
	<p>
	  Now we must mount the hard disk
	</p>
	<code class=block>
	  cd /
	  mkdir disk
	  mount -t ext2 /dev/hda1 /disk
	</code>
      </li>
      <li>
	<p>
	  As an alternative, If you want to restore your system over several partitions like
	  /usr /var /home and / , you must create the partitions, format them as seen above and then
	  create the directories that will be used as mounting point an mount the
	  partitions on these directories. For example if you have / , /usr ,
	  /var and /home partitions this would look like this:
	</p>
	<code class=block>
	  mkdir /disk/usr /disk/var /disk/home
	  mount /dev/sda2 /disk/usr
	  mount /dev/sda3 /disk/var
	  mount /dev/sda4 /disk/home
	</code>
      <li>
      <li>
	<p>
	  If the boot system used does not already include dar/libdar (unlike
	  system rescue CD and Knoppix for example) we need to copy the <i>dar</i>
	  binary from a removable medium to your disk: insert the USB key&nbsp;
	  containing the <i>dar_static</i> binary to be able to freely change of key
	  later on:
	</p>
	<code class=block>
	  cd /
	  mkdir /usb_key
	  mount /dev/sdb /usb_key
	  cp /usb_key/dar_static /disk
	</code>
	<p>
	  where <code>/dev/sdb</code> points to your usb_key drive
	  (run "dmesg" just after plugging the key to know which device to
	  use in place of the fancy /dev/sdb). We
	  will remove dar_static from your new hard drive at the end of
	  restoration.
	</p>
      </li>
      <li>
	<p>
	  All the restored data has to go in /disk subdirectory:
	  <code>-R /disk</code>
	</p>
      </li>
      <li>
	<p>
	  The process may be long, thus it might be useful to be noticed when
	  a user action is required by dar: <code>-b</code>
	  note that <i>-p</i> option is not required here because if a slice is missing
	  dar will pause and ask you its number (If slice "0" is requested by dar, it
	  means the "last" slice of the backup is requested).
	</p>
      </li>
      <li>
	<p>
	  OK, now we have seen all the options, let's go restoring!
	</p>
	<code class=block>
	  /disk/dar_static -x /usb_key/linux_full -R /disk -b
	</code>
      </li>
      <p>
	...and when the next USB key is needed:
      </p>
      <code class=block>
	umount /usb_key
      </code>
      <p>
	...then unplug the key, plug the next one and mount it:
      </p>
      <code class=block>
	mount /dev/sdb /usb_key
      </code>
      <p>
	As previously, to do that either use an second
	<i>xterm</i> virtual console or suspend dar
	by CTRL-Z and awake it back by the 'fg'
	command. Then press &lt;enter&gt; to proceed with dar
      </p>
      </li>
      <li>
	<p>
	  Once finished with the restoration of linux_full, we have to do the
	  same with any following differential/incremental backup. However, doing
	  so will warn you any time dar restores a more recent file (file
	  overwriting) or any time a file
	  that has been removed since the backup of reference, has to be removed
	  from file system (suppression). If you don't want to press the
	  &lt;enter&gt; key several thousand times: <code>-w</code> option
	  (don't warn). All file will be overwritten without warning, and this is not
	  an issue as be restore more recent data over older one.
	</p>
      </li>
      <li>
	<p>
	  All together for each potential differential backups, we have to call:
	</p>
	<code class=block>
	  /disk/dar_static -x /usb_key/linux_diff1 -R /disk -b -w
	  /disk/dar_static -x /usb_key/linux_diff2 -R /disk -b -w
	  /disk/dar_static -x /usb_key/linux...... -R /disk -b -w
	</code>
      </li>
      <li>
	<p>
	  Finally, remove the dar binary from the disk:
	</p>
	<code class=block>
	  rm /disk/dar_static
	</code>
      </li>
      <li>
	<p>
	  and we have to modify the <i>/etc/fstab</i> with the new UUID you have recorded
	  (use the <code>blkid</code> command to get them listed and modify <i>/etc/fstab</i>
	  if necessary)
	<p>
      </li>
      <li>
	<p>
	  Last, reinstall you original boot loader from the restored data:
	</p>
	<p>
	  If you still use lilo type: <code>lilo -r /disk</code>
	</p>
	<p>
	  If your boot loader is grub/grub2 type:
	</p>
	<code class=block>
	  update-initramfs -u
	  update-grub
	  grub-install /dev/sda
	</code>
      </li>
      <li>
	<p>
	  You can reboot you machine and be happy with you brand-new hard
	  disk with your old precious data on it:
	</p>
	<code class=block>
	  shutdown -r now
	</code>
      </li>
    </ol>
    <p>
      In this operation dar in particular restored sparse files and hard
      linked inodes, thus you will have no drawback and even possibly better
      space usage than the original filesystem as dar can even transparently
      convert big plain files into smaller sparse files without any impact
    </p>
    <p>
      The <a href="restoration-with-dar.html">Flexibly Restoring a whole system with dar</a>
      document goes one step further in this direction by illustrating many use cases
      like, the use of LVM, LUKS encrypted filesystems, even the full restoration
      of a <i>Proxmox Virtual Environment</i> system with all its <i>Virtual Machines</i>
    </p>

    <h2>Recover only some files</h2>

    <p>
      Gosh, you have remove a important
      file by error. Thus, you just need to restore it, not the rest of the
      full and differential backups.
    </p>

    <h3>First method:</h3>

    <p>
      We could as previously, try all
      archive starting from the full backup up to the most recent
      differential backup, and restore just the file if it is present in the
      archive:
    </p>
    <code class=block>
      dar -R / -x /usb/linux_full -g home/denis/my_precious_file
    </code>

    <p>
      This would restore only the file /home/denis/my_precious_file from the
      full backup.
    </p>

    <p>
      OK, now we would also have to restore from all differential backup the
      same way we did. Of course, this file may have changed since the full
      backup.
    </p>
    <code class=block>
      dar -R / -x /usb/linux_diff1 -g home/denis/my_precious_file
    </code>
    <p>
      and so on, up to the last differential archive.
    </p>
    <code class=block>
      dar -R / -x /usb/linux_diff29 -g home/denis/my_precious_file
    </code>

    <h3>Second method (more efficient):</h3>
    <p>
      We will restore our lost file,
      starting from the most recent differential backup and *maybe* up to the
      full backup. Our file may or may not be present in the a
      differential archive as it may have changed or not since the previous
      version, thus we have to check if our file is restored, using the -v
      option (verbose):
    </p>
    <code class=block>
      dar -R / -x /usb/linux_diff29 -v -g home/denis/my_precious_file
    </code>
    <p>
      If we can see a line like this:
    </p>
    <code class=block>
      restoring file: /home/denis/my_precious_file
    </code>
    <p>
      Then we are good. We can stops here, because we got the most recent backup version of our
      lost file. Otherwise we have to continue with the previous
      differential backup, up to the full backup if necessary. This
      method has an advantage over the first one, which is not to have *in all
      case* the need to use all the backup done since the full backup.
    </p>

    <p>
      OK, now you have two files to restore. No problem, just do the second
      method but add -r option not to override any more recent file already
      restored in a previous step:
    </p>
    <code class=block>
      dar -x /usb key/linux_diff29 -R / -r -v -g home/denis/my_precious_file -g etc/fstab
    </code>
    <p>
      Check the output to see if one or both of your files got restored. If
      not, continue with the previous backup, up to the time you have seen
      for each file a line indicating it has been restored. Note that the most
      recent version of each files may not be located in the same archive,
      thus you might get /etc/fstab restored from linux_diff28, and
      /home/denis/my_precious_file restored at linux_diff27. In the case
      /etc/fstab is also present in linux_diff27 it would not have been
      overwritten by an older version, thanks to the -r option.
    </p>
    <p>
      This option is very important when restoring more than one file using
      the second method. Instead, in the first method is used (restoring first from
      the full backup, then from all the following differential backups), -r
      option is not so important because if overwriting occurs when you restore
      lost files, you would only overwrite an older version by a newer.<br>
    </p>

    <h3>Third method (for the lay guys like me)</h3>

    <p>
      If you are lazy (as I am) have a look at dar_manager (at the
      end of the tutorial), it relies on a database that compile the content
      of all of your backups. You can then ask <i>dar_manager</i> a particular
      file, files or even directories, it will look in which backup to fetch
      them from and will invoke <i>dar</i> for you on the correct backup
      and file set.
    </p>

    <h2>Isolating a "catalogue"</h2>

    <p>
      We have seen previously how to do differential backups. Doing
      so, dar asks the last slice of the archive of reference. This operation
      is required to read the table of contents (also known as "catalogue"
      [this is a French word that means "catalog" in English, I will keep
      this French word in the following because it is also the name of the
      C++ class used in libdar]) which is located at the end of the archive
      (thus on the last slice(s)). You have the possibility to isolate
      (that's it to extract) a copy of this table of content to a small file.
      This small file is quite exactly the same as a differential archive
      that holds no data in it. Let's take an example with the full backup we
      did previously to see how to extract a catalogue:
    </p>

    <code class=block>
      dar -C /root/CAT_linux_full -A /mnt/usb/linux_full -z
    </code>

    <p>
      Note here that we used the UPPERCASE 'C' letter, by opposition the the
      lowercase 'c' which is used for archive creation, here we just created
      an isolated catalogue, which is usually a small archive. In addition,
      you can use -z option to have it compressed, -s and -S option to have
      it split in slices, -p option, -b option, but for an isolated catalogue
      this is not often necessary as it is usually rather small. The only
      thing we have seen for backup that you will not be able to do for
      isolation is to filter files (-X, -I, -g, -P, -[ and -] option are not
      available for that operation).
    </p>
    <p>
      So what, now we have our extracted catalogue, what can we do with it?
      Two things:
    </p>
    <dl>
      <dt class=void>First</dt><dd>
	<p>
	  we can use the extracted catalogue in place of the archive, as
	  reference for a differential backup. No need to manipulate the old usb
	  key, you can store the last's backup isolated catalogue on your hard
	  disk instead and use it as reference for the next backup. If we had
	  used an isolated catalogue in the previous
	  examples, we would have built our first differential backup this way
	  (note that here we have chose to use the CAT_ prefix to indicate that
	  the archive is an isolated catalogue, but the choice is yours to label
	  isolated catalogue the way you want):
	</p>
	<code class=block>
	  dar -c linux_diff1 -A /root/CAT_linux_full ... (other options seen above stay the same)
	</code>
      </dd>
      <dt class=void>Second</dt><dd>
	<p>
	  we can use the isolated catalogue as backup of the internal catalogue
	  if it get corrupted. Well to face to data corruption the best solution
	  ever invented is <a href="usage_notes.html#Parchive">Parchive</a>,
	  an autonomous program that builds parity
	  file (same mechanism as the one used for RAID disks) for a given file.
	  Here we can use Parchive to create a parity file for each slice. So,
	  assuming you lack Parchive, and that you failed reading the full backup
	  because the usb key is corrupted in the part used to store the internal
	  catalogue, you can use an isolated catalogue as rescue:
	</p>
	<code class=block>
	  dar -x linux_full -A /root/CAT_linux_full ...
	  dar -d linux_full -A /root/CAT_linux_full ...
	  dar -t linux_full -A /root/CAT_linux_full ...
	  dar -l /root/CAT_linux_full
	</code>
      </dd>
    </dl>

    <p>
      An isolated catalogue can be built for any type of archive (full,
      differential or incremental archive, even for an already isolated
      catalogue, which I admit is rather useless). You can also create an
      isolated catalogue at the same time you do a backup, thanks to the
      <b>-@ option</b>:
    </p>
    <code class=block>
      dar -c linux_diff1 -A /mnt/usb key/linux_full -@ CAT_linux_diff1 ... (other options...)
      dar -c linux_full -@ CAT_linux_full ... (other options see above stay the same for backup)
    </code>
    <p>
      This is know as "on-fly" isolation.
    </p>


    <h2>Dar_manager tutorial</h2>

    <h3>Setting up a Database</h3>

    <p>
      <i>dar_manager</i>
      builds a database of all
      your backup contents (full, incremental or differential, but not decremental ones),
      to automatically restore the latest versions of
      a given set of files or directories.
    </p>
    <p> Since release 2.8.0 you can use dar_manager databases directly with dar to restore
      efficiently a whole filesystem (or just some files), in either the latest saved state, or the
      state before a given date. Note also that dar_mananger database supports binary delta,
      which else may be complicated to restore as you have to restore the latest full version, then
      all subsequent patches for they update the file on filesystem.
    </p>
    <p>
      But first let's create a database:
    </p>
    <code class=block>
      dar_manager -C my_base.dmd
    </code>

    <p>
      This created a file "my_base.dmd" where dmd stands for Dar Manager
      Database, but you are free to use any other extension.
    </p>
    <p>
      This database is created empty. Each time you make a backup, may it be
      full, differential or incremental, with or without binary deltas, you will have to add its
      table of contents (aka "catalogue") to this database using the&nbsp; following command:
    </p>

    <code class=block>
      dar_manager -B my_base.dmd -A /mnt/usb/linux_full
    </code>
    <p>
      This will add ("A" stands for "add") the archive contents to the base.
      In some cases you may not have the archive available but its extracted
      catalogue instead. Of course, you can use the extracted catalogue in
      place of the archive!
    </p>
    <code class=block>
      dar_manager -B my_base.dmd -A ~/Catalogues/CAT_linux_full
    </code>
    <p>
      The problem however is that when dar_manager will need to recover a
      file located in this archive it will try to open the
      archive ~/Catalogue/CAT_linux_full for restoration, which does not contain any
      data because it is just the catalogue of the archive.
    </p>
    <p>
      No problem in that case, thanks to the -b option we can
      change afterward the basename of the archive, and thanks to the -p option you can
      change afterward the path at any time. Let's now list the database
      contents:
    </p>
    <code class=block>
      dar_manager -B my_base.dmd -l
    </code>
    <p>
      It shows the following:
    </p>

    <code class=block>
      dar path         :
      dar options      :
      database version : 6
      compression used : gzip
      compression level: 9

      archive #   |    path      |    basename
      ------------+--------------+---------------
      &nbsp;     1       /home/denis/Catalogues      CAT_linux_full
    </code>

    <p>
      We should change the path of archive number 1 for dar_manager looks on
      the usb key drive:
    </p>
    <code class=block>
      dar_manager -B my_base.dmd -p 1 /mnt/usb
    </code>

    <p>
      ...and also replace the name of the extracted catalogue by the real
      archive name
    </p>
    <code class=block>
      dar_manager -B my_base.dmd -b 1 linux_full
    </code>

    <p>
      Now we have exactly the same database as if we had use the real archive
      instead of its catalogue:
    </p>
    <code class=block>
      dar_manager -B my_base.dmd -l

      dar path         :
      dar options      :
      database version : 6
      compression used : gzip
      compression level: 9

      archive #   |    path      |    basename
      ------------+--------------+---------------
      &nbsp;     1       /mnt/usb      linux_full
    </code>

    <p>
      In place of using -b and -p options, you can also tell the path and the
      name of the real archive to use at restoration time, when you add the catalogue to the database:
    </p>

    <code class=block>
      dar_manager -B my_base.dmd -A ~/Catalogues/CAT_linux_full <b>/mnt/usb/linux_full</b>
    </code>
    <p>
      This is done adding an optional argument. The first ~/Catalogue... is
      the archive where to read the catalogue from, and the second /mnt/usb/... is the name to keep for
      it. No access is done to this second archive at the time of the addition, thus it may stay unavailable at
      the time the command is typed.
    </p>

    <p>
      You can add up to 65534 archives to a given database, and have as much
      base as you want.
    </p>
    <code class=block>
      dar_manager -B my_base.dmd -A ~/Catalogues/linux_fullA
      dar_manager -B my_base.dmd -A ~/Catalogues/linux diffA1
      dar_manager -B my_base.dmd -A ~/Catalogues/linux_incrA1_1
      dar_manager -B my_base.dmd -A ~/Catalogues/linux_incrA1_2
      dar_manager -B my_base.dmd -A ~/Catalogues/linux_incrA1_3
      dar_manager -B my_base.dmd -A ~/Catalogues/linux_diffA2
      dar_manager -B my_base.dmd -A ~/Catalogues/linux_incrA2_1
      dar_manager -B my_base.dmd -A ~/Catalogues/linux_incrA1_2
      dar_manager -B my_base.dmd -A ~/Catalogues/linux_fullB
      dar_manager -B my_base.dmd -A ~/Catalogues/linux_diffB1
      ...
    </code>
    <h3>using a database for efficient restoration</h3>
    <p>
      When you have many full backups interleaved with differential and incremental ones, it may become
      a nightmare (and I like to sleep well, where from dar_manager) to find the archive where is located
      the latest version. This is worse if you plan to restore a directory (or even worse the whole
      backup content), as not all files may have changed at the same time and their latest version may end
      in different backups... And the nightmare turns to horror when considering binary delta where the latest
      status of a file is spread between several backups!
    </p>
    <p>
      Before release 2.8.0, only dar_manager program was able to leverage a dar_manager
      database. When came the time to restore something through it, the user had to call
      dar_manager with its <code>-r</code> option, which drove dar_manager to select the proper
      archive/backup set from the database with for each backup the correct set of file to restore and
      each time spawning a new dar process to proceed to this restoration step.
      This explains why you could see the <code>dar options</code> and <code>dar path</code> above
      in header of a database content listing. But this method is over now
      and will tend to be deprecated in the future.
    </p>
    <p>
      Today, if you want to restore a file, a directory, a directory tree or even the whole
      backup content, just call <b>dar</b> (an not dar_manager!) but give it the dar_manager database
      instead of a backup. But for <em>dar</em> to know this is a database, add the <code>-aefd</code>
      option, which long version is <code>--alter=extract-from-database</code>.
    </p>
    <p>
      Let's suppose we want to restore our /home/denis/my/precious/file:
    </p>
    <code class=block>
      dar -aefd -x my_base.dmd -R / -g home/denis/my/precious/file
    </code>
    <p>
      <i>dar</i> will find the proper archive(s) to restore this file. As you can see, you can use
      any of the filtering mechanism we say previously with dar <code>-X/-I/-P/-g/-[/-]....</code>.
      But of course you can also avoid any filtering option, in that case the whole backup set will
      be restored.
    </p>
    <p>
      OK, but what if I do not want to restore my files/directories/filesystems in the latest availabe
      state (for example the filesystem/disk corrupted some files and I only noticed that 3 months after)?
    <p>
      For that we use the <code>-A</code> option with <code>-x</code> option. We already saw -A option
      at creation time to give the archive of reference. This option can receive not only a dar backup
      (the reference), but also a date, a '+' to create a snapshot, and more. To use a date we have to
      add the <code>-af</code> option (which long version is <code>--alter=fixed-date</code>). When used with a
      dar_manager database, this instructs <u>dar</u> to ignore any information more recent than this date.
      The result leads dar to restore files and directories to the most recent known state they have
      at the specified time:
    </p>
    <code class=block>
      dar -aefd -x my_base.dmd -R / -g home/denis/my/precious/file -af -A 2025/08/01-20:43:48
    </code>
    <p>
      The restoration is the only operation where you use <em>dar</em> instead of <em>dar_manager</em> with
      a dar_manager database. What is described below relies on <b>dar_manager</b>.

    </p>

    <h3>Managing a database over time</h3>
    <p>
      Once an archive become obsolete you can delete it from the database
      thanks to the <code>-D</code> option, you can also change archive order (<code>-m</code> option),
      get a list in which is located a given file (<code>-f</code> option), get the list
      of most recent files in a given archive (<code>-u</code> option), and get overall
      statistics per archive (<code>-s</code> option).
    </p>
    <p>
      A new feature for those that are really very lazy (still as I am myself):
      dar_manager has an <b>interactive mode</b>, it gives you access to all dar_manager features,
      just remember to prefer <em>dar</em> for restoration, it is much more efficient.
      So you don't have to remeber all these command-line switches except one: <code><e>-i</e></code>
    </p>
    <code class=block>
      dar_manager -B my_base.dmd <e>-i</e>
    </code>

    <h2>To go further with dar/libdar</h2>
    <p>
      Well, we have reached the end of this tutorial, but dar/libdar has still a lot of features to be discovered:
    </p>
    <ul>
      <li>strong encryption</li>
      <li>archive merging</li>
      <li>decremental backup</li>
      <li>dar command-line files (DCF)</li>
      <li>user commands between slices (and DUC files)</li>
      <li>Extended Attribute manipulations</li>
      <li>hard links</li>
      <li>Sparse files</li>
      <li>remote backup over ssh</li>
      <li>suspending/resuming a database from dar before/after backing it up</li>
      <li>using regex in place of glob expressions in masks</li>
      <li>using dar with tape thanks to the sequential reading mode</li>
      <li>having dar adding padded zeros to slice numbers</li>
      <li>excluding some files from compression</li>
      <li>asking dar to retry saving a file if it changes a the time of the backup</li>
      <li>what is a "dirty" files in a dar archive</li>
      <li>listing an archive contents under XML format</li>
      <li>using conditional syntax in DCF files</li>
      <li>using user targets</li>
      <li>adding user comments in dar archive</li>
      <li>using DAR_DCF_PATH and DAR_DUC_PATH environment variables</li>
      <li>truncated archive repairing</li>
    </ul>

    <p>
      all this is described in much details in the following documents:
      <ul>
	<li><a href="FAQ.html">FAQ</a></li>
	<li><a href="mini-howto/index.html">mini-howto</a></li>
	<li><a href="usage_notes.html">command-line usage notes</a></li>
	<li><a href="man/index.html">man pages</a>.</li>
	<li><a href="restoration-with-dar.html">restoration with dar</a></li>
      </ul>

    <p>
      You can also find document starting from the feature point of view using
      the <a href="Features.html">feature description page</a>.
      However if you find something unclear, feel free to report or ask for
      help on<a href="https://lists.sourceforge.net/lists/listinfo/dar-support">dar-support mailing-list</a>.
  </body>
</html>