2
0
Эх сурвалжийг харах

Clarify FAQ regarding backup of virtual machines (#1672)

enkore 8 жил өмнө
parent
commit
ce72d24825
1 өөрчлөгдсөн 33 нэмэгдсэн , 0 устгасан
  1. 33 0
      docs/faq.rst

+ 33 - 0
docs/faq.rst

@@ -12,6 +12,39 @@ Yes, the `deduplication`_ technique used by
 |project_name| makes sure only the modified parts of the file are stored.
 Also, we have optional simple sparse file support for extract.
 
+If you use non-snapshotting backup tools like Borg to back up virtual machines,
+then these should be turned off for doing so. Backing up live VMs this way can (and will)
+result in corrupted or inconsistent backup contents: a VM image is just a regular file to
+Borg with the same issues as regular files when it comes to concurrent reading and writing from
+the same file.
+
+For backing up live VMs use file system snapshots on the VM host, which establishes
+crash-consistency for the VM images. This means that with most file systems
+(that are journaling) the FS will always be fine in the backup (but may need a
+journal replay to become accessible).
+
+Usually this does not mean that file *contents* on the VM are consistent, since file
+contents are normally not journaled. Notable exceptions are ext4 in data=journal mode,
+ZFS and btrfs (unless nodatacow is used).
+
+Applications designed with crash-consistency in mind (most relational databases
+like PostgreSQL, SQLite etc. but also for example Borg repositories) should always
+be able to recover to a consistent state from a backup created with
+crash-consistent snapshots (even on ext4 with data=writeback or XFS).
+
+Hypervisor snapshots capturing most of the VM's state can also be used for backups
+and can be a better alternative to pure file system based snapshots of the VM's disk,
+since no state is lost. Depending on the application this can be the easiest and most
+reliable way to create application-consistent backups.
+
+Other applications may require a lot of work to reach application-consistency:
+It's a broad and complex issue that cannot be explained in entirety here.
+
+Borg doesn't intend to address these issues due to their huge complexity
+and platform/software dependency. Combining Borg with the mechanisms provided
+by the platform (snapshots, hypervisor features) will be the best approach
+to start tackling them.
+
 Can I backup from multiple servers into a single repository?
 ------------------------------------------------------------