|
@@ -12,6 +12,39 @@ Yes, the `deduplication`_ technique used by
|
|
|
|project_name| makes sure only the modified parts of the file are stored.
|
|
|project_name| makes sure only the modified parts of the file are stored.
|
|
|
Also, we have optional simple sparse file support for extract.
|
|
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?
|
|
Can I backup from multiple servers into a single repository?
|
|
|
------------------------------------------------------------
|
|
------------------------------------------------------------
|
|
|
|
|
|
enkore