update

Encryption.md

@@ -3,9 +3,9 @@
 In normal operation, datasets are transferred unaltered:
 
 * Source datasets that are encrypted will be send over as such and stay encrypted at the target side. (In ZFS this is called raw-mode) You dont need keys at the target side if you dont want to access the data.
-* Source datasets that are plain will stay that way on the target. (Even if the specified target-path IS encrypted.) 
+* Source datasets that are plain will stay that way on the target. (Even if the specified target-path IS encrypted.)
 
-Basically you dont have to do anything or worry about anything. 
+Basically you dont have to do anything or worry about anything.
 
 ## Decrypting/encrypting
 
@@ -21,8 +21,6 @@ Note 2: Decide what you want at an early stage: If you change the --encrypt or -
 
 ## Some common errors while using zfs encryption
 
-```
-cannot receive incremental stream: kernel modules must be upgraded to receive this stream.
-```
+> cannot receive incremental stream: kernel modules must be upgraded to receive this stream.
 
-This happens if you forget to use --encrypt, while the target datasets are already encrypted. (Very strange error message indeed)
+This happens if you forget to use `--encrypt`, while the target datasets are already encrypted. A very strange error message indeed.

PrePost.md

@@ -2,13 +2,20 @@
 
 You can run commands before and after the snapshot to freeze databases for example, to make the on-disk data consistent before snapshotting.
 
-Note: a ZFS snapshot is atomic, so most of the time freezing isnt really needed. If you restore a snapshot, the application will just think the server (or application) had a regular crash. Most modern databases can handle this fine.
+## When is this needed?
 
+ZFS snapshots are atomic per pool. There wont be any corruption if something tries to write during the making of a snapshot. 
+
+If you restore a snapshot, the application will just think the server (or application) had a regular crash.
+
+Most modern databases and applications can handle this fine, so usually freezing isnt needed in that case. 
+
+Note that if you use multiple pools, the snapshots are not atomic. 
 ## Method 1: Use snapshot mode
 
 Its possible to use zfs-autobackup in snapshot-only mode. This way you can just create a script that contains the pre and post steps:
-```console
 
+```console
 #freeze stuff
 some-freeze-command
 
@@ -20,8 +27,6 @@ some-unfreeze-command
 
 #make backup
 zfs-autobackup backup1 --no-snapshot --ssh-target backupserver backups/db1
-
-
 ```
 
 This has the disadvantage that you might have to do the error handling yourself. Also if the source is remote, you have to use the correct ssh command and escaping as well.
@@ -40,6 +45,7 @@ zfs-autobackup \
 ```
 
 The way this works:
+
 * The pre and post commands are always executed on the source side. (via ssh if needed)
 * If a pre-command fails, it will immediately execute the post-commands and exit with an error code.
 * All post-commands are always executed. Even if the pre-commands or actual snapshot have failed. This way you can be sure that stuff is always cleaned up and unfreezed.