README.md: reorganize.

README.md

@@ -13,6 +13,8 @@ coordinate many different backup utilities.
 
 # Features
 
+The key features of backupninja are:
+
  - easy to read ini style configuration files
  - you can drop in scripts to handle new types of backups
  - backup actions can be scheduled
@@ -23,7 +25,7 @@ coordinate many different backup utilities.
  - passwords are never sent via the command line to helper programs
  - works with [Linux-Vservers](http://linux-vserver.org/)
 
-# Backup types
+The following backup types are supported:
 
  - secure, remote, incremental filesytem backup (via rdiff-backup)
    incremental data is compressed. permissions are retained even
@@ -85,9 +87,11 @@ To add an additional 'wizard' to ninjahelper, follow these steps:
    would think, try to make your helper as simple as possible. Walk like a cat,
    become your shadow, don't let your senses betray you.
 
+Configuration
+=============
 
 Configuration files
-===================
+-------------------
 
 The general configuration file is `/etc/backupninja.conf`. In this file
 you can set the log level and change the default directory locations.
@@ -143,7 +147,7 @@ The [example configuration files](examples) document all options
 supported by the handlers shipped with backupninja.
 
 Scheduling
-==========
+----------
 
 By default, each configuration file is processed everyday at 01:00 (1
 AM). This can be changed by specifying the 'when' option in a config
@@ -179,36 +183,8 @@ These values for `when` are invalid:
         when = tuesday at 2
         when = tues at 02
 
-
-Real world usage
-================
-
-Backupninja can be used to implement whatever backup strategy you
-choose. It is intended, however, to be used like so:
-
-1. First, databases are safely copied or exported to `/var/backups`.
-   Typically, you cannot make a file backup of a database while it
-   is in use, hence the need to use special tools to make a safe copy
-   or export into `/var/backups`.
-
-2. Then, vital parts of the file system, including `/var/backups`, are
-   nightly pushed to a remote, off-site, hard disk (using
-   rdiff-backup). The local user is root, but the remote user is not
-   priviledged. Hopefully, the remote filesystem is encrypted.
-
-There are many different backup strategies out there, including "pull
-style", magnetic tape, rsync + hard links, etc. We believe that the
-strategy outlined above is the way to go because:
-
-1. hard disks are very cheap these days;
-2. pull style backups are no good, because then the backup server must
-   have root on the production server;
-3. rdiff-backup is more space efficient and featureful than using
-   rsync + hard links.
-
-
 SSH keys
-========
+--------
 
 In order for rdiff-backup to sync files over ssh unattended, you must
 create ssh keys on the source server and copy the public key to the
@@ -228,7 +204,7 @@ an rdiff-backup configuration, and will set up the ssh keys for you.
 
 
 Amazon Simple Storage Service (S3)
-==================================
+----------------------------------
 
 Duplicity can store backups on Amazon S3 buckets, taking care of encryption.
 Since it performs incremental backups it minimizes the number of request per
@@ -237,7 +213,7 @@ Web Services is needed to use duplicity with S3 (Debian package: `python-boto`).
 
 
 Vservers
-========
+--------
 
 If you are using [Linux-Vservers](http://linux-vserver.org/) there are some
 special capabilities that different handlers have to make vserver
@@ -255,7 +231,7 @@ but they probably don't need to be changed:
  - `VROOTDIR` (default: `$VSERVERINFO info SYSINFO |grep vserver-Rootdir | awk '{print $2}'`)
 
 .sh configuration files
-=======================
+-----------------------
 
 Shell jobs may use the following features:
 
@@ -273,3 +249,29 @@ Shell jobs may use the following features:
 
   * The `$BACKUPNINJA_DEBUG` environment variable is set when
     backupninja is invoked with the `-d` option.
+
+Real world usage
+================
+
+Backupninja can be used to implement whatever backup strategy you
+choose. It is intended, however, to be used like so:
+
+1. First, databases are safely copied or exported to `/var/backups`.
+   Typically, you cannot make a file backup of a database while it
+   is in use, hence the need to use special tools to make a safe copy
+   or export into `/var/backups`.
+
+2. Then, vital parts of the file system, including `/var/backups`, are
+   nightly pushed to a remote, off-site, hard disk (using
+   rdiff-backup). The local user is root, but the remote user is not
+   priviledged. Hopefully, the remote filesystem is encrypted.
+
+There are many different backup strategies out there, including "pull
+style", magnetic tape, rsync + hard links, etc. We believe that the
+strategy outlined above is the way to go because:
+
+1. hard disks are very cheap these days;
+2. pull style backups are no good, because then the backup server must
+   have root on the production server;
+3. rdiff-backup is more space efficient and featureful than using
+   rsync + hard links.