From 28d802df8c5ba169bd4bc2bfdc82bfc4ec931c80 Mon Sep 17 00:00:00 2001 From: Buggfix42 <121123137+Buggfix42@users.noreply.github.com> Date: Sat, 29 Aug 2026 19:47:29 +0200 Subject: [PATCH] [Documentation] A few minor improvements (#21998) --- doc/040_backup.rst | 8 ++++++++ doc/050_restore.rst | 9 ++++++--- 2 files changed, 14 insertions(+), 3 deletions(-) diff --git a/doc/040_backup.rst b/doc/040_backup.rst index 5459e88b3..1f664881a 100644 --- a/doc/040_backup.rst +++ b/doc/040_backup.rst @@ -497,6 +497,8 @@ By specifying the option ``--one-file-system`` you can instruct restic to only backup files from the file systems the initially specified files or directories reside on. In other words, it will prevent restic from crossing filesystem boundaries and subvolumes when performing a backup. +Internally, restic identifies a file's filesystem by the "device ID" +that is returned by calling lstat() on the file. For example, if you backup ``/`` with this option and you have external media mounted under ``/media/usb`` then restic will not back up ``/media/usb`` @@ -660,6 +662,12 @@ If there is a **bind-mount** below a directory that is to be saved, restic desce archived as a block device file and restored as such. This also means that the content of the corresponding disk is not read, at least not from the device file. +**Socket files** are not backed up because they represent active connections by running processes +and are only meaningful if created by those processes. + +**FIFO files** are backed up, but because their contents are volatile and never stored on disk, +only the file system entry and metadata will be backed up. + By default, restic does not save the access time (atime) for any files or other items, since it is not possible to reliably disable updating the access time by restic itself. This means that for each new backup a lot of metadata is diff --git a/doc/050_restore.rst b/doc/050_restore.rst index 2ab37e5ba..852c607a6 100644 --- a/doc/050_restore.rst +++ b/doc/050_restore.rst @@ -92,9 +92,12 @@ By default, restic does not restore files as sparse. Use ``restore --sparse`` to enable the creation of sparse files if supported by the filesystem. Then restic will restore long runs of zero bytes as holes in the corresponding files. Reading from a hole returns the original zero bytes, but it does not consume -disk space. Note that the exact location of the holes can differ from those in -the original file, as their location is determined while restoring and is not -stored explicitly. +disk space. Note that restic does not keep track of which files were originally +sparse or at what locations sparse holes were. When restoring, restic will create +a sparse hole (by seeking forward instead of writing data) for any range of zeros +at the start of a blob. This range can span the entire blob. Because large files +result in blobs much larger than file system blocks, restoring a large sparse file +with many holes may make it significantly larger than the original sparse file. Restoring extended file attributes ----------------------------------