]> git.proxmox.com Git - pve-docs.git/blobdiff - pct.adoc
pct: move backup and restore section
[pve-docs.git] / pct.adoc
index 05fd71363a28f92f5a7e0c53eb319a142d1508e8..40028b70f4b0796933ad342cc2bf186a7cd5aba5 100644 (file)
--- a/pct.adoc
+++ b/pct.adoc
@@ -59,7 +59,7 @@ Our primary goal is to offer an environment as one would get from a
 VM, but without the additional overhead. We call this "System
 Containers".
 
-NOTE: If you want to run micro-containers (with docker, rct, ...), it
+NOTE: If you want to run micro-containers (with docker, rkt, ...), it
 is best to run them inside a VM.
 
 
@@ -207,26 +207,26 @@ randomize crontab:: so that cron does not start at the same time on all containe
 
 Changes made by {PVE} are enclosed by comment markers:
 
- # --- BEGIN PVE ---
- <data>
- # --- END PVE ---
-
-If no such section is found it will be inserted at a reasonable location
-in the file.
+----
+# --- BEGIN PVE ---
+<data>
+# --- END PVE ---
+----
 
-If such a section already exists it will be updated in place and will not be
-moved.
+Those markers will be inserted at a reasonable location in the
+file. If such a section already exists, it will be updated in place
+and will not be moved.
 
-Modification of a file can be prevented by adding a `.pve-ignore.` file for it.
-For instance, if the file `/etc/.pve-ignore.hosts` exists then the
-`/etc/hosts` file will not be touched. (This can be a simple empty file creatd
-via:
+Modification of a file can be prevented by adding a `.pve-ignore.`
+file for it.  For instance, if the file `/etc/.pve-ignore.hosts`
+exists then the `/etc/hosts` file will not be touched. This can be a
+simple empty file creatd via:
 
  # touch /etc/.pve-ignore.hosts
 
-The above tasks are OS dependent and so they differ between different
-distributions. You can also disable all modifications entirely by manually
-setting the 'ostype' to 'unmanaged'.
+Most modifications are OS dependent, so they differ between different
+distributions and versions. You can completely disable modifications
+by manually setting the 'ostype' to 'unmanaged'.
 
 OS type detection is done by testing for certain files inside the
 container:
@@ -243,9 +243,16 @@ ArchLinux:: test /etc/arch-release
 
 Alpine:: test /etc/alpine-release
 
+Gentoo:: test /etc/gentoo-release
+
 NOTE: Container start fails if the configured 'ostype' differs from the auto
 detected type.
 
+Options
+~~~~~~~
+
+include::pct.conf.5-opts.adoc[]
+
 
 Container Images
 ----------------
@@ -347,10 +354,17 @@ also provide an easy way to share data between different containers.
 Mount Points
 ~~~~~~~~~~~~
 
-Beside the root directory the container can also have additional mount points.
+The root mount point is configured with the `rootfs` property, and you can
+configure up to 10 additional mount points. The corresponding options
+are called `mp0` to `mp9`, and they can contain the following setting:
+
+include::pct-mountpoint-opts.adoc[]
+
 Currently there are basically three types of mount points: storage backed
 mount points, bind mounts and device mounts.
 
+.Storage backed mount points
+
 Storage backed mount points are managed by the {pve} storage subsystem and come
 in three different flavors:
 
@@ -361,33 +375,41 @@ in three different flavors:
 - Directories: passing `size=0` triggers a special case where instead of a raw
   image a directory is created.
 
+.Bind mount points
+
 Bind mounts are considered to not be managed by the storage subsystem, so you
 cannot make snapshots or deal with quotas from inside the container, and with
 unprivileged containers you might run into permission problems caused by the
 user mapping, and cannot use ACLs from inside an unprivileged container.
 
-Similarly device mounts are not managed by the storage, but for these the
-`quota` and `acl` options will be honored.
+WARNING: For security reasons, bind mounts should only be established
+using source directories especially reserved for this purpose, e.g., a
+directory hierarchy under `/mnt/bindmounts`. Never bind mount system
+directories like `/`, `/var` or `/etc` into a container - this poses a
+great security risk. The bind mount source path must not contain any symlinks.
+
+.Device mount points
+
+Similar to bind mounts, device mounts are not managed by the storage, but for
+these the `quota` and `acl` options will be honored.
+
+.FUSE mounts
 
 WARNING: Because of existing issues in the Linux kernel's freezer
 subsystem the usage of FUSE mounts inside a container is strongly
 advised against, as containers need to be frozen for suspend or
-snapshot mode backups. If FUSE mounts cannot be replaced by other
-mounting mechanisms or storage technologies, it is possible to
-establish the FUSE mount on the Proxmox host and use a bind
-mount point to make it accessible inside the container.
+snapshot mode backups.
 
-The root mount point is configured with the 'rootfs' property, and you can
-configure up to 10 additional mount points. The corresponding options
-are called 'mp0' to 'mp9', and they can contain the following setting:
+If FUSE mounts cannot be replaced by other mounting mechanisms or storage
+technologies, it is possible to establish the FUSE mount on the Proxmox host
+and use a bind mount point to make it accessible inside the container.
 
-include::pct-mountpoint-opts.adoc[]
-
-.Typical Container 'rootfs' configuration
+.Typical Container `rootfs` configuration
 ----
 rootfs: thin1:base-100-disk-1,size=8G
 ----
 
+
 Using quotas inside containers
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -433,6 +455,13 @@ they can contain the following setting:
 include::pct-network-opts.adoc[]
 
 
+Backup and Restore
+------------------
+
+It is possible to use the 'vzdump' tool for container backup. Please
+refer to the 'vzdump' manual page for details.
+
+
 Managing Containers with 'pct'
 ------------------------------