Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
software:files [2024/04/19 15:03]
cyril
software:files [2024/04/22 00:04] (current)
cyril [Tools]
Line 145: Line 145:
     * Periodic TRIM, i.e. explicitly notifying the free blocks periodically.     * Periodic TRIM, i.e. explicitly notifying the free blocks periodically.
       * Using the ''fstrim'' utils from the util-linux package.       * Using the ''fstrim'' utils from the util-linux package.
-      * Manually: run ''fstrim --verbose <fs-volume>'' for a single volume, or ''fstrim --verbose -A'' for all mounted filesystems listed in ''/etc/fstab'' and the root filesystem inferred from the kernel command line.+      * Manually: run ''fstrim --verbose <mount-point>'' for a single volume, or ''fstrim --verbose -A'' for all mounted filesystems listed in ''/etc/fstab'' and the root filesystem inferred from the kernel command line.
       * Weekly: enable the timer ''systemctl start fstrim.timer''       * Weekly: enable the timer ''systemctl start fstrim.timer''
  
Line 171: Line 171:
 === Borg Backup === === Borg Backup ===
  
-  * Create a Borg repository in the current folder: <code>borg init -e <encryption> [--append-only]</code>+  * Create a Borg repository in the current folder: <code>borg init -e <encryption> [--append-only] .</code>
     * ''<encryption>'' can be:     * ''<encryption>'' can be:
       * ''none'' to disable it, for instance on an already encrypted volume       * ''none'' to disable it, for instance on an already encrypted volume
Line 178: Line 178:
     * ''--append-only'' means that no data can be removed with borg, archives can only be added. It can be used to protect an online repository against malware.     * ''--append-only'' means that no data can be removed with borg, archives can only be added. It can be used to protect an online repository against malware.
   * Create archives: <code>borg create <repo>::<!archive> <path> --stats --progress   * Create archives: <code>borg create <repo>::<!archive> <path> --stats --progress
-    --compression auto,zstd,12 --chunker-params 15,23,19,4095 --noatime --noctime -x --exclude-caches</code>+    --compression auto,zstd,12 --chunker-params 15,23,19,4095 --noctime -x --exclude-caches</code>
     * ''--compression'': it can make sense to adjust the compression level depending on your computer speed and your storage speed, so that compression does not slow down the backup, but still save as much space as possible under this constraint. However it is not always easy to find an universal value (data that compress very well are mostly limited by the input storage speed, while data that compress less well are mostly limited by the output storage speed). You have roughly the choice between LZ4 (very quick), LZMA (very high compression ratio), and ZSTD (wide-range) in between.     * ''--compression'': it can make sense to adjust the compression level depending on your computer speed and your storage speed, so that compression does not slow down the backup, but still save as much space as possible under this constraint. However it is not always easy to find an universal value (data that compress very well are mostly limited by the input storage speed, while data that compress less well are mostly limited by the output storage speed). You have roughly the choice between LZ4 (very quick), LZMA (very high compression ratio), and ZSTD (wide-range) in between.
     * ''--chunker-params'': this is also an important but a bit complicated tuning. Originally default value was creating small chunks causing huge cache and memory usage, so they switched to much larger chunks, but which can be too large for some applications (for instance when modifying only metadata of an image file, we want to deduplicate the data), so I came with this compromise ''15,23,19,4095''.     * ''--chunker-params'': this is also an important but a bit complicated tuning. Originally default value was creating small chunks causing huge cache and memory usage, so they switched to much larger chunks, but which can be too large for some applications (for instance when modifying only metadata of an image file, we want to deduplicate the data), so I came with this compromise ''15,23,19,4095''.
Line 186: Line 186:
  
 === Restic === === Restic ===
 +
 +  * Create a Restic repository in the current folder: <code>restic init --repo .</code>
 +    * Note that encryption **and** password are mandatory, [[https://github.com/restic/restic/issues/4326|because]]. However you can store the password in a file in the repository, or use the a password file with ''--password-file''.
 +  * Create snapshots: <code>restic --repo <repo> --verbose --compression auto --ignore-ctime backup <path></code>
 +    * The chunker cannot be configured, contrary to Borg. It is equivalent to [[https://restic.readthedocs.io/en/stable/100_references.html#backups-and-deduplication|19,23]],[[https://restic.net/blog/2015-09-12/restic-foundation1-cdc/|21,512]], similarly to Borg's default [[https://borgbackup.readthedocs.io/en/stable/internals/data-structures.html#buzhash-chunker|19,23,21,4095]], but unlike my chosen values.
 +    * ''--compression'': unlike Borg, there is only choicies ''auto'', ''max'' and ''off''
 +
  
 === BTRFS snapshots === === BTRFS snapshots ===
software/files.1713539016.txt.gz ยท Last modified: 2024/04/19 15:03 by cyril
CC Attribution-Share Alike 4.0 International
Driven by DokuWiki Recent changes RSS feed Valid CSS Valid XHTML 1.0