Files
ProxMenux/web/messages/en/docs/post-install/storage.json
T
MacRimi 5ca3463bf6 complete i18n migration to /[locale]/ with EN+ES content
Full rewrite of the docs site under app/[locale]/ with next-intl
in localePrefix:"always" mode. Every page now exists at both
/en/<path> and /es/<path>; the root / shows a meta-refresh + JS
redirect to /<defaultLocale>/ so GitHub Pages serves something
on the apex URL.

Highlights:
- 107 doc pages migrated to file-per-page JSON namespaces under
  messages/en/ and messages/es/. Spanish content is fully
  translated (no copy-of-English placeholders).
- New documentation for the Active Suppressions section in the
  Settings tab and the per-event Dismiss dropdown in the Health
  Monitor modal.
- New screenshots: dismiss-duration-dropdown.png and an updated
  health-suppression-settings.png.
- Pagefind integrated for client-side search; index is built on
  every CI deploy (not committed).
- RSS feeds: per-locale at /<locale>/rss.xml plus root /rss.xml
  for backward compat.
- Removed the dead app/[locale]/guides/[slug]/ route — every
  guide now has its own static page and no markdown source
  remains.
- Fixed orphan link /guides/nvidia -> /guides/nvidia-manual in
  docs/hardware/nvidia-host.
- Removed obsolete components (footer2, calendar, drawer).

Verified locally with `npm ci && npm run build`: 2804 files in
out/, 231 pages indexed by pagefind, root redirect intact, both
locale roots and the new Active Suppressions docs render OK.
2026-05-31 12:41:10 +02:00

159 lines
11 KiB
JSON
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
{
"meta": {
"title": "Post-Install: Storage | ProxMenux Documentation",
"description": "Storage optimizations in the ProxMenux Customizable post-install script: ZFS ARC sizing based on host RAM, zfs-auto-snapshot for periodic snapshots, and vzdump backup speed limits removal."
},
"header": {
"title": "Post-Install: Storage",
"section": "Settings post-install Proxmox"
},
"intro": {
"title": "What this category covers",
"body": "Three storage-related optimizations: tune the <strong>ZFS ARC</strong> cache size to a sensible fraction of host RAM, install and schedule <strong>ZFS auto-snapshots</strong>, and remove throttles from <strong>vzdump</strong> so backups run at full speed. All three are independent — pick the ones that match your setup."
},
"notTrackedTitle": "None of these are in the Uninstall menu",
"notTrackedBody": "Unlike most post-install optimizations, the three Storage options are <strong>not currently tracked</strong> in the Uninstall Optimizations flow. If you apply them and later want to revert, you'll have to do it by hand. The manual rollback commands are shown below each section.",
"arc": {
"heading": "Optimize ZFS ARC size",
"intro": "The <strong>Adaptive Replacement Cache (ARC)</strong> is ZFS's in-memory read cache. Without explicit tuning, ZFS happily grabs up to half the host RAM for itself, which is excessive on a Proxmox host that also needs memory for VMs and LXCs. This option caps ARC to a sane fraction of total RAM based on the size of the machine.",
"sizingTitle": "Sizing rules",
"headerRam": "Host RAM",
"headerMin": "ARC min",
"headerMax": "ARC max",
"rows": [
{
"ram": "≤ 16 GB",
"min": "512 MB",
"max": "512 MB"
},
{
"ram": "17 32 GB",
"min": "1 GB",
"max": "1 GB"
},
{
"ram": "> 32 GB",
"min": "RAM / 16",
"max": "RAM / 8"
}
],
"after": "On a 64 GB host, that means 4 GB min / 8 GB max for ARC. The config is written to <code>/etc/modprobe.d/99-zfsarc.conf</code> and enables a few extra ZFS tunables (L2ARC prefetch on, L2ARC write max at 500 MB, longer TXG timeout).",
"rebootTitle": "Requires a reboot to take effect",
"rebootBody": "ARC settings are read when the <code>zfs</code> kernel module loads. They do <strong>not</strong> apply on a live system — you'll need to reboot the host for the cap to kick in. The script sets the \"reboot required\" flag automatically.",
"safeTitle": "Safe on non-ZFS hosts",
"safeBody": "The function checks for the <code>zfs</code> command before touching anything. On ext4 / LVM-only Proxmox hosts, ticking this option is a no-op — nothing gets written.",
"verifyTitle": "Verification and manual rollback"
},
"autoSnap": {
"heading": "Install ZFS auto-snapshot",
"intro": "Installs the <a>zfs-auto-snapshot</a> package and rewrites its cron schedules so snapshots are taken automatically at several intervals. A great no-effort safety net on top of your regular vzdump backups.",
"cadenceTitle": "Snapshot cadence ProxMenux configures",
"headerLabel": "Label",
"headerRuns": "Runs",
"headerKept": "Snapshots kept",
"rows": [
{
"label": "frequent",
"runs": "every 15 min",
"kept": "4"
},
{
"label": "hourly",
"runs": "every hour",
"kept": "1"
},
{
"label": "daily",
"runs": "once a day",
"kept": "1"
},
{
"label": "weekly",
"runs": "once a week",
"kept": "1"
},
{
"label": "monthly",
"runs": "once a month",
"kept": "1"
}
],
"conservativeTitle": "Conservative keep counts",
"conservativeBody": "ProxMenux ships with conservative retention (just 4 frequent + 1 of each longer interval) so ZFS snapshot storage doesn't balloon. If you want longer retention, edit the numbers in <code>/etc/cron.d/zfs-auto-snapshot</code>, <code>/etc/cron.hourly/zfs-auto-snapshot</code>, etc. after the script runs.",
"onlyZfsTitle": "Only useful on ZFS pools",
"onlyZfsBody": "Installing the package on an ext4-only host is harmless but pointless — there are no ZFS datasets for it to snapshot. Skip this option if you don't use ZFS.",
"verifyTitle": "Verification and manual rollback"
},
"autotrim": {
"heading": "Enable ZFS autotrim (SSD/NVMe pools)",
"intro": "Enables the <code>autotrim</code> property on every ZFS pool that is backed exclusively by SSDs or NVMe drives with TRIM support. Pools that include a single HDD vdev are skipped automatically — TRIM on rotational drives is meaningless and ZFS will refuse it. Pools that were already set to <code>autotrim=on</code> are left as they are.",
"trimTitle": "What TRIM does, and why it matters on ZFS",
"trimBody1": "SSDs / NVMe drives manage internal storage in fixed-size erase blocks that are much larger than the logical sectors the filesystem talks to. When a filesystem deletes a file, the drive doesn't know — it still thinks those sectors are in use, so its internal garbage collector keeps shuffling stale data around to free new erase blocks. <strong>TRIM</strong> is the standard command the OS uses to tell the drive \"these sectors are now free, you can erase them ahead of time\".",
"trimBody2": "Without TRIM, SSD performance degrades over time as the drive runs out of pre-erased blocks and has to do erase-on-write, and write amplification increases — both shortening the drive's useful life. With TRIM enabled, the drive can keep a healthy pool of empty blocks ready to write into.",
"trimBody3": "On ZFS, <code>autotrim=on</code> is the modern equivalent of the periodic <code>zpool trim &lt;pool&gt;</code> command — instead of having to remember to run a trim manually (or schedule one), the pool issues TRIM commands automatically and continuously as blocks become free. It's low-overhead and the recommended setting for SSD-backed pools.",
"practicalTitle": "Why is this practical to enable?",
"practicalItems": [
"<strong>Sustained write performance.</strong> SSDs that never see TRIM commands slow down measurably over months. Autotrim keeps the controller's job easier.",
"<strong>Drive longevity.</strong> Lower write amplification means fewer total NAND writes for the same amount of data — measurable in years of useful life for the disk.",
"<strong>No scheduled cron job to remember.</strong> Unlike a periodic <code>zpool trim</code>, autotrim is fire-and-forget — the pool handles it on its own."
],
"whenTitle": "When is this necessary?",
"whenIntro1": "<strong>You should enable it</strong> on any ZFS pool whose vdevs are all SSD or NVMe with TRIM support — the typical Proxmox install on consumer or enterprise SSDs.",
"whenIntro2": "<strong>The script skips it automatically</strong> on:",
"whenSkipItems": [
"Pools containing any HDD (rotational) vdev — TRIM is meaningless there.",
"Drives without <code>discard_granularity</code> exposed in sysfs — usually old SSDs without TRIM, or pass-through paths where the OS can't see the underlying device.",
"Pools where ZFS itself reports the property unsupported (rare; very old pools).",
"Pools already set to <code>autotrim=on</code> (no-op)."
],
"whenIntro3": "<strong>Not relevant on ext4-only hosts</strong> — there's nothing for ZFS to trim. The function exits with a friendly message in that case.",
"recordedTitle": "Why only the pools ProxMenux changed are recorded",
"recordedBody": "The function only writes a pool to its internal state file (<code>/usr/local/share/proxmenux/zfs_autotrim_pools</code>) when it actively flipped that pool from <code>off</code> to <code>on</code>. Pools you had on autotrim before running the script are left out of the list, so a future Uninstall doesn't turn off settings you configured yourself — only ProxMenux's own changes are reverted.",
"manualTitle": "Manual equivalent (run on your server)",
"manualIntro": "The full sequence the script runs against each pool is replicable by hand. This is what you would type if you wanted to do the same thing on a single pool without ProxMenux:",
"verifyTitle": "Verification and manual rollback",
"oneShotTitle": "Need a one-shot trim instead of continuous?",
"oneShotBody": "Some operators prefer a manual trim during off-peak hours rather than continuous trim activity. Disable autotrim and schedule a cron job that runs <code>zpool trim &lt;pool&gt;</code> — same end goal, different cadence."
},
"vzdump": {
"heading": "Increase vzdump backup speed",
"intro": "By default, Proxmox vzdump throttles backups to protect running VMs/CTs from IO starvation. On many setups that throttle is more conservative than needed. This option removes the bandwidth cap and lowers the I/O priority so vzdump can saturate the storage path during backup windows.",
"changedTitle": "What gets changed in /etc/vzdump.conf",
"noBackupTitle": "No backup of vzdump.conf",
"noBackupBody": "The script <strong>edits <code>/etc/vzdump.conf</code> in place</strong> without creating a <code>.bak</code> first. If you had custom values there (bwlimit, ionice, compress, pigz, tmpdir, exclude-path, etc.), the changes to <em>those two lines</em> are made with <code>sed</code> — surrounding config is preserved — but there's no \"undo\" snapshot. Make a manual backup if your config is non-trivial: <code>cp /etc/vzdump.conf /etc/vzdump.conf.pre-proxmenux</code>.",
"skipTitle": "When to skip this",
"skipBody": "On a host with slow local storage and VMs that are latency-sensitive, removing the bandwidth cap can cause noticeable slowdowns during backups. If you've previously set a specific <code>bwlimit</code> for that reason, keep it — skip this option.",
"verifyTitle": "Verification and manual rollback"
},
"related": {
"heading": "Related",
"items": [
{
"label": "ZFS Management commands",
"href": "/docs/help-info/zfs-commands",
"tail": " — zpool / zfs reference for ARC, snapshots, scrub."
},
{
"label": "Storage and Disks commands",
"href": "/docs/help-info/storage-commands",
"tail": " — generic block-device and Proxmox storage reference."
},
{
"label": "Backup and Restore commands",
"href": "/docs/help-info/backup-commands",
"tail": " — vzdump CLI reference (now without the legacy bwlimit / ionice caps)."
},
{
"label": "Uninstall Optimizations",
"href": "/docs/post-install/uninstall",
"tail": " — revert ARC / vzdump changes."
},
{
"label": "Customizable Post-Install",
"href": "/docs/post-install/customizable",
"tail": " — back to the parent menu."
}
]
}
}