// Module included in the following assemblies:
//
// * backup_and_restore/application_backup_and_restore/oadp-advanced-topics/oadp-backing-up-data-one-cluster-restoring-another-cluster.adoc

:_mod-docs-content-type: CONCEPT
[id="oadp-pod-volume-backup_{context}"]
= About determining which pod volumes to back up

[role="_abstract"]
Before starting a File System Backup (FSB), you must specify which pod volumes to back up. Velero calls this process discovering volumes. You can use either the opt-in or opt-out approach to help Velero choose between an FSB, a volume snapshot, or a Data Mover backup.

* *Opt-in approach*: With the opt-in approach, volumes are backed up using snapshot or Data Mover by default. FSB is used on specific volumes that are opted-in by annotations.

* *Opt-out approach*: With the opt-out approach, volumes are backed up using FSB by default. Snapshots or Data Mover is used on specific volumes that are opted-out by annotations.


[id=pod-volume-limitations_{context}]
== Limitations

* FSB does not support backing up and restoring `hostpath` volumes. However, FSB does support backing up and restoring local volumes.
* Velero uses a static, common encryption key for all backup repositories it creates. *This static key means that anyone who can access your backup storage can also decrypt your backup data*. It is essential that you limit access to backup storage.
* For PVCs, every incremental backup chain is maintained across pod reschedules.
+
For pod volumes that are _not_ PVCs, such as `emptyDir` volumes, if
a pod is deleted or recreated, for example, by a `ReplicaSet` or a deployment, the next backup of those volumes will be a full backup and not an incremental backup. It is assumed that the lifecycle of a pod volume is defined by its pod.
* Even though backup data can be kept incrementally, backing up large files, such as a database, can take a long time. This is because FSB uses deduplication to find the difference that needs to be backed up.
* FSB reads and writes data from volumes by accessing the file system of the node on which the pod is running. For this reason, FSB can only back up volumes that are mounted from a pod and not directly from a PVC. Some Velero users have overcome this limitation by running a staging pod, such as a BusyBox or Alpine container with an infinite sleep, to mount these PVC and PV pairs before performing a Velero backup..
* FSB expects volumes to be mounted under `<hostPath>/<pod UID>`, with
`<hostPath>` being configurable. Some Kubernetes systems, for example,
vCluster, do not mount volumes under the `<pod UID>` subdirectory, and
VFSB does not work with them as expected.
