Scratch storage
Choose, size, monitor, and troubleshoot the temporary persistent volumes used by restore Jobs.
Loading documentation…
Powered by heyo
Every restore Job receives its own dynamically provisioned PersistentVolumeClaim (PVC). The volume holds the downloaded backup, its decoded or unpacked contents, and the restored database data.
The PVC is a generic ephemeral volume owned by the restore Pod. Kubernetes removes it with the Pod after RestoreTrust approves cleanup of that execution's terminal evidence.
| Property | Required behavior |
|---|---|
| Provisioning | Dynamic |
| Access mode | ReadWriteOnce |
| Volume mode | Filesystem |
| Reclaim policy | Delete |
| Topology | WaitForFirstConsumer for zonal or topology-bound storage |
| Permissions | CSI driver applies fsGroup so non-root containers can write |
| Capacity | At least one attachable volume per concurrent restore Job |
| Encryption | At rest when required by your data policy |
A StorageClass with Retain leaves the backing disk and restored customer
data behind after the PVC is removed. Use a dedicated class with
reclaimPolicy: Delete unless your security policy explicitly requires manual
retention and cleanup.
Every schedule sets its own scratch size in whole GiB, from 1 to 9313 GiB (10 TB). The field is required, and the agent requests exactly that size for each restore of the schedule. The worker has no size settings: its Deployment only chooses the StorageClass.
A schedule saved before the size became required has none. Its checks fail with "schedule has no scratch size" until you set one.
Size each schedule for the largest expected combination of:
Compressed backup size alone is not a safe estimate. Allow headroom for decompression, database structures, and restore-time amplification.
Select a class that meets the table above. Leaving the field empty uses the cluster's default StorageClass.
Enter the scratch size when you create a schedule, or change it on the schedule's Project worker page.
Use a backup near the upper end of your expected size. Monitor the PVC, Pod, and node while the run is active.
Anyone who can edit a schedule decides how large its PVCs are. A ResourceQuota in the job namespace is the cluster's own limit on the number and total size of temporary PVCs. Set the count to at least Max parallel jobs, and storage to at least:
Max parallel jobs × largest schedule scratch size
For a worker with four parallel Jobs whose largest schedule uses 100 GiB:
Finished Jobs can briefly continue to count against quota until their result is acknowledged and the Pod is removed. A PVC the quota refuses keeps its Pod Pending until the check fails as insufficient storage. Increase the quota before increasing parallel capacity or a schedule's scratch size.
| Symptom | Likely cause | Action |
|---|---|---|
| Pod remains Pending with an unbound PVC | Missing/default StorageClass, quota, topology, or provisioning failure | Describe the Pod and PVC; fix the class, quota, or topology |
| Pod reports a volume attach limit | Too many volumes on the node | Add nodes, reduce parallel jobs, or use a driver with suitable limits |
| Restore reports insufficient scratch storage | PVC filled or Pod was evicted | Increase the schedule's scratch size and check node pressure |
| Pod times out while mounting | CSI attach or mount failure | Inspect Pod events and the CSI driver; RestoreTrust cannot see storage-system events through its restricted RBAC |
| Disks remain after completed runs | Retain, retained Pods, or manual debugging | Identify ownership before deleting; correct the reclaim policy |
Do not retain completed Jobs for routine operation. Retained Jobs keep their Pods, PVCs, and restored data until you delete them manually.
Deleting a PVC, Pod, or Job during a restore destroys the in-progress workspace and fails the check. Confirm the check is finished and identify the owning Job before manual cleanup.