docs: review backup and restore documentation in all seven translations

web/messages/sv/docs/backup-restore/creating-backups.json

@@ -0,0 +1,220 @@
+{
+  "meta": {
+    "title": "Skapa säkerhetskopior — interaktivt säkerhetskopieringsflöde | ProxMenux",
+    "description": "Det interaktiva säkerhetskopieringsflödet i ProxMenux: två ingångspunkter (Scripts TUI-meny och Monitors webbgränssnitt), tre destinationer, två profillägen, ett gemensamt steg för tillfällig förberedelse och en bekräftelsedialog. Sidan beskriver matrisen med sex alternativ, standardprofilen och den anpassade profilen samt vad användaren ser från valet av säkerhetskopia tills arkivet sparas på destinationen.",
+    "ogTitle": "ProxMenux Backup - skapa backup",
+    "ogDescription": "Det interaktiva säkerhetskopieringsflödet med tre destinationer, två profiler och ett gemensamt steg för tillfällig förberedelse.",
+    "twitterTitle": "Skapa backups | ProxMenux",
+    "twitterDescription": "Interaktivt backupflöde med tre destinationer och två profillägen."
+  },
+  "header": {
+    "title": "Skapa backups",
+    "description": "Det interaktiva säkerhetskopieringsflödet: välj en destination och en profil, granska bekräftelsen och följ hur arkivet sparas. De två ingångspunkterna använder samma backend och skapar identiska arkiv.",
+    "section": "Säkerhetskopiering och återställning"
+  },
+  "intro": {
+    "title": "Två ingångspunkter, identisk funktionalitet",
+    "body": "Scripts TUI och Monitors webbgränssnitt erbjuder <strong>exakt samma funktioner</strong>. Varje säkerhetskopia — manuell eller schemalagd — går genom samma valmatris (tre destinationer × två profiler) och anropar samma backendfunktion per cell (<code>_bk_pbs</code>, <code>_bk_borg</code> eller <code>_bk_local</code>). Arkiven som skapas via de två ingångspunkterna är identiska. Valet beror på vad man föredrar: TUI passar för SSH och skript; Monitor erbjuder musklick tillsammans med vyerna för aviseringar och löpande loggutdata."
+  },
+  "entryPoints": {
+    "heading": "De två ingångspunkterna",
+    "rows": [
+      {
+        "entry": "ProxMenux Scripts (TUI)",
+        "path": "menu → Utilities → Host Config Backup",
+        "detail": "Dialogbaserat flöde, SSH-vänligt. Huvudmenyn presenterar de sex alternativen direkt. Använder <code>backup_menu</code> i <code>backup_host.sh</code>."
+      },
+      {
+        "entry": "ProxMenux Monitor (Webb UI)",
+        "path": "Backups tab → Create backup",
+        "detail": "Guidebaserat flöde. Samma sex alternativ visas i ett formulär med två steg (destination → profil). Samma backendfunktioner anropas via Flask-API:et."
+      }
+    ]
+  },
+  "modes": {
+    "heading": "Manuella och schemalagda säkerhetskopior",
+    "body": "Säkerhetskopior kan produceras i två lägen: <strong>manuellt</strong> (det interaktiva flöde som beskrivs på denna sida - användaren plockar en destination och en profil från en meny och följer hur arkivet sparas) eller <strong>schemalagt</strong> (ett obevakat jobb som körs på en timer i cron-stil och tillämpar bevarandeinställningarna för jobbet). Båda lägena stöder samma tre destinationer och samma två profiler, och båda är tillgängliga från båda ingångspunkterna - Scripts TUI-meny och Monitors Backups-flik. Planerade jobb använder samma backendfunktioner som manuellt flöde genom <code>run_scheduled_backup.sh</code>; de arkiv som produceras är oskiljbara.",
+    "seeAlso": "Sidan schemalagda jobb täcker hela flödet, inklusive hur man skapar ett jobb, bifogar det till en befintlig PVE vzdump timer och konfigurerar retentionsvärdena.",
+    "monitorAlt": "ProxMenux Monitor Backups-fliken som visar den nya schemalagda backup-dialogen med destination, profil, schema och fält för bevarande.",
+    "monitorCaption": "Schemalagd säkerhetskopia — ProxMenux Monitor. Samma guidedialog som skapar en manuell säkerhetskopia har fält för schema och bevarande längst ner för obevakad körning."
+  },
+  "matrix": {
+    "heading": "Matrisen med sex alternativ",
+    "intro": "Valet avgör både vilken backend som körs och vilken strategi för sökvägsval som används. Se sidorna för respektive destination för konfigurationsdetaljer om varje cell.",
+    "rows": [
+      {
+        "combo": "1",
+        "destination": "PBS",
+        "profile": "Standard",
+        "action": "Laddar upp standardprofilen och de beständiga tilläggen till ett konfigurerat PBS-arkiv."
+      },
+      {
+        "combo": "2",
+        "destination": "Borg",
+        "profile": "Standard",
+        "action": "Skapar ett arkiv med standardprofilen plus beständiga tillägg i det valda Borg-förvaret."
+      },
+      {
+        "combo": "3",
+        "destination": "Lokal",
+        "profile": "Standard",
+        "action": "Skriver ett <code>.tar.zst</code>-arkiv med standardprofilen plus beständiga tillägg till det konfigurerade lokala målet."
+      },
+      {
+        "combo": "4",
+        "destination": "PBS",
+        "profile": "Anpassad",
+        "action": "Öppnar sökvägsväljaren före uppladdningen till PBS; användaren markerar sökvägar och kan lägga till nya."
+      },
+      {
+        "combo": "5",
+        "destination": "Borg",
+        "profile": "Anpassad",
+        "action": "Öppnar sökvägsväljaren innan Borg-arkivet skapas."
+      },
+      {
+        "combo": "6",
+        "destination": "Lokal",
+        "profile": "Anpassad",
+        "action": "Öppnar sökvägsväljaren innan det lokala <code>.tar.zst</code>-arkivet skrivs."
+      }
+    ]
+  },
+  "profiles": {
+    "heading": "Standard vs anpassad profil",
+    "defaultTitle": "Standardprofil",
+    "defaultBody": "Standardprofilen är den kurerade listan från <code>hb_default_profile_paths</code> (dokumenterad i <em>Hur det fungerar</em> under <em>Sökvägskategorier</em>) plus varje post i den filen med beständiga tillägg <code>/usr/local/share/proxmenux/backup-extra-paths.txt</code>. Användaren bekräftar destinationen och krypteringsalternativen och backupen fortsätter utan ytterligare sökvägsval.",
+    "customTitle": "Anpassad profil",
+    "customBody": "Den anpassade profilen öppnar en checklista med alla sökvägar i standardprofilen (omarkerade) och alla beständiga tillägg (förmarkerade, med prefixet <code>[+]</code>). Användaren markerar sökvägarna för denna körning och kan trycka på <em>Lägg till anpassad sökväg</em> för att lägga till en ny absolut sökväg. Sökvägar som läggs till här sparas i <code>backup-extra-paths.txt</code> så att framtida säkerhetskopior tar med dem automatiskt. Att avmarkera ett beständigt tillägg utesluter det från denna körning men tar inte bort det ur filen — borttagning görs separat via <em>Hantera anpassade sökvägar</em>, utanför säkerhetskopieringsflödet.",
+    "customPickerAlt": "Checklista för anpassad profil med standardprofilens sökvägar (omarkerade) och beständiga tillägg (förmarkerade med prefixet [+]), samt knappar för att lägga till en sökväg eller bekräfta valet.",
+    "customPickerCaption": "Anpassad profil — sökvägsväljaren. Standardprofilens sökvägar är omarkerade; beständiga tillägg är förmarkerade med prefixet [+]. Användaren markerar sökvägarna för denna körning.",
+    "manageCustomAlt": "Menyn för att hantera anpassade sökvägar med listan över beständiga tillägg och alternativ för att lägga till, ta bort eller redigera dem.",
+    "manageCustomCaption": "Hantera anpassade sökvägar — platsen där beständiga tillägg läggs till eller tas bort. Varje sökväg här ingår automatiskt i säkerhetskopior med standardprofilen utan att den anpassade sökvägsväljaren behöver öppnas."
+  },
+  "commonPipeline": {
+    "heading": "Vad som går oavsett destination",
+    "intro": "När profilen har fastställts kör varje backend samma tillfälliga förberedelsesteg innan den går vidare till sin egen uppladdningsmetod. <code>hb_prepare_staging</code> bygger arkivträdet i <code>/tmp/proxmenux-DESTINATION-stage.XXXXXX</code> och fyller vart och ett av de tre datablocken.",
+    "steps": [
+      {
+        "step": "1",
+        "name": "Sammanställning av rootfs",
+        "detail": "Kör <code>rsync -a</code> för varje vald sökväg till <code>staging_root/rootfs/</code>. Databasen pmxcfs i <code>/var/lib/pve-cluster/config.db</code> sparas separat via <code>sqlite3 .backup</code> för att få en konsekvent ögonblicksbild utan att stoppa klustret; hjälpfilerna <code>.db-wal</code> / <code>.db-shm</code> utesluts från rsync. Om <code>sqlite3</code> saknas sparas i stället en fil <code>config.db.raw-fallback</code>, som återställningen använder som databas vid importen. Flyktiga undersökvägar (bash-historik, cache, papperskorg) utesluts från <code>/root/</code>. Sökvägar som saknas i källan registreras i <code>metadata/missing_paths.txt</code> utan att säkerhetskopieringen avbryts."
+      },
+      {
+        "step": "2",
+        "name": "Manifestgenerering",
+        "detail": "<code>build_manifest.sh</code> samordnar de sex insamlingsmodulerna och skriver <code>manifest.json</code> i roten av den tillfälliga katalogen. Om en modul misslyckas får det berörda avsnittet ett dokumenterat tomt standardvärde; manifestet är fortfarande giltigt."
+      },
+      {
+        "step": "3",
+        "name": "Paketinventering",
+        "detail": "<code>apt-mark showmanual</code> fångas verbatim i <code>metadata/packages.manual.list</code>. Komponentstatus är redan inne i det återställda rootfs (<code>components_status.json</code>) eftersom <code>/usr/local/share/proxmenux/</code> är en del av standardprofilen."
+      },
+      {
+        "step": "4",
+        "name": "Information om körningen",
+        "detail": "<code>metadata/run_info.env</code> registrerar säkerhetskopieringens identitet - värdnamn, tidsstämpel, kärnversion - som används av återställningens kompatibilitetskontroll för att bestämma riktningen mellan kärnversionerna."
+      },
+      {
+        "step": "5",
+        "name": "Avisering (start)",
+        "detail": "<code>hb_notify_lifecycle \"start\"</code> utlöses. Om aviseringar är konfigurerade i Monitor skickas händelsen <em>Säkerhetskopiering av värden startad</em> till användaren. Inget skickas om inga kanaler har konfigurerats."
+      }
+    ]
+  },
+  "included": {
+    "heading": "Vad går in och vad stannar ut",
+    "intro": "Varje sökväg i den fastställda profilen (standard + beständiga tillägg + val i anpassat läge) kopieras med <code>rsync -aAXH --numeric-ids</code>. En delad uteslutningslista gäller för varje sökväg, och två kataloger har ytterligare sökvägsspecifika uteslutningar.",
+    "globalTitle": "Globala uteslutningar (tillämpas varje väg)",
+    "globalItems": [
+      "<code>images/</code> - bilddumpar.",
+      "<code>dump/</code> — utdata från vzdump.",
+      "<code>tmp/</code> - tillfälliga filer.",
+      "<code>*.log</code> loggfiler."
+    ],
+    "rootTitle": "<code>/root/</code>-uteslutningar",
+    "rootBody": "<code>/root/</code> ingår i standardprofilen så att användarens skript och konfiguration sparas i arkivet. Flyktiga undersökvägar utesluts:",
+    "rootItems": [
+      "<code>.bash_history</code>",
+      "<code>.cache/</code>",
+      "<code>tmp/</code>",
+      "<code>.local/share/Trash/</code>"
+    ],
+    "proxmenuxTitle": "<code>/usr/local/share/proxmenux/</code>-uteslutningar",
+    "proxmenuxBody": "Denna katalog skickar användarstatus endast - <code>components_status.json</code>, preferenser, post-install cache. Kod som destinationen redan har från sin egen ProxMenux-installation utesluts så att en återställning inte överskriver målets nuvarande binärer med äldre:",
+    "proxmenuxItems": [
+      "<code>restore-pending/</code>, <code>scripts/</code>, <code>web/</code>",
+      "<code>monitor-app/</code>, <code>monitor-app.*/</code>, <code>AppImage/</code>",
+      "<code>images/</code>, <code>json/</code>",
+      "<code>utils.sh</code>, <code>helpers_cache.json</code>",
+      "<code>ProxMenux-Monitor.AppImage*</code>, <code>install_proxmenux*.sh</code>"
+    ],
+    "notInProfileTitle": "Vägar utanför profilen",
+    "notInProfileBody": "Allt som inte anges i <code>hb_default_profile_paths</code> och inte läggs till som en anpassad eller ihållande extra är inte en del av backupen. Anmärkningsvärda exempel:",
+    "notInProfileItems": [
+      "<strong>VM- och LXC-diskar</strong> - hanteras av <code>vzdump</code>, inte av denna funktion. Gästkonfigurationsfiler under <code>/etc/pve/nodes/*/qemu-server/*.conf</code> och <code>lxc/*.conf</code> fångas (de lever under <code>/etc/pve</code>) så återställningen reproducerar inventeringen; diskarna själva är återanslutna från en befintlig vzdump / PBS backup.",
+      "<strong><code>/boot</code> och <code>/boot/efi</code></strong> - kärnbinärer, initramfs och UEFI ESP-partitionen regenereras av målets egen <code>update-initramfs</code>, <code>update-grub</code> eller <code>proxmox-boot-tool refresh</code> efter återställningen. Starthanteraren kopieras aldrig ordagrant.",
+      "<strong>Filsystem för kärnan och systemets körning</strong> — <code>/proc</code>, <code>/sys</code>, <code>/dev</code> och <code>/run</code> är pseudofilsystem som skapas av kärnan och udev; de lagras inte beständigt någonstans.",
+      "<strong>Paketbinärer under <code>/usr/bin</code>, <code>/usr/lib</code>, <code>/lib</code>, <code>/sbin</code></strong> - ominstallerad av målets APT från <code>packages.manual.list</code>.",
+      "<strong><code>/var/log/</code>, <code>/var/tmp/</code>, <code>/var/cache/</code></strong> - per-värd runtime tillstånd, inte återställd.",
+      "<strong><code>/home/USER</code></strong> - inte i standardprofilen. Lägg till det som en anpassad väg när ett system bär hemkataloger som måste överleva en återställning."
+    ],
+    "customPathsTitle": "Hur anpassade vägar hanteras",
+    "customPathsBody": "En anpassad väg som läggs till i anpassat läge eller kvarstår i <code>backup-extra-paths.txt</code> går igenom samma <code>rsync</code>-pipeline som standardprofilvägar. Globala uteslutningar gäller. Om den anpassade vägen råkar vara under <code>/root/</code> eller <code>/usr/local/share/proxmenux/</code> gäller fortfarande de vägspecifika uteslutningarna ovan. Varje arkiverad väg - standard eller anpassad - registreras i <code>metadata/paths_archived.txt</code>. Sökvägar som inte finns på källan registreras i <code>metadata/missing_paths.txt</code> utan att stoppa backupen."
+  },
+  "archiveStructure": {
+    "heading": "Arkivstruktur",
+    "intro": "Den tillfälliga katalog som varje backend skapar har samma struktur oavsett destination. Tar-arkivet, PBS-arkivet <code>.pxar</code> eller Borg-arkivet lagrar detta träd oförändrat.",
+    "tree": "backup-[timestamp]/\n├── manifest.json                  # structured host state (kernel_params, hardware, storage, guests, components, source_host)\n├── metadata/\n│   ├── packages.manual.list       # output of apt-mark showmanual\n│   ├── run_info.env               # hostname, timestamp, kernel version, pmxcfs method\n│   ├── paths_archived.txt         # exact list of paths that reached rootfs/\n│   └── missing_paths.txt          # paths from the profile absent on source\n└── rootfs/\n    ├── etc/                       # /etc/pve, /etc/network, /etc/systemd/network, /etc/ssh, /etc/apt, ...\n    ├── root/                      # /root without volatile subpaths\n    ├── usr/local/                 # /usr/local/bin, /usr/local/sbin, /usr/local/share/proxmenux (state only)\n    └── var/                       # /var/lib/pve-cluster (config.db via sqlite3 .backup), /var/spool/cron/crontabs"
+  },
+  "confirmation": {
+    "heading": "Sammanfattning för bekräftelse",
+    "body": "Innan backend skriver något till destinationen visar ProxMenux en sammanfattande dialog med destinationen, backup-ID eller arkivnamn, krypteringstillstånd och listan över vägar som kopieras. Avbokning här avbryter backupen rent - staging katalogen tas bort av <code>trap</code> kroken på backend funktionen och ingen partiell data når destinationen."
+  },
+  "writing": {
+    "heading": "Skriva till destinationen",
+    "intro": "Efter bekräftelsen kör varje backend sitt eget skrivsteg. Sidorna för destinationerna beskriver hur det fungerar; de gemensamma delarna är loggen, sidofilen och aviseringen om slutförande.",
+    "rows": [
+      {
+        "topic": "Loggfil",
+        "detail": "Varje backend skriver sin fullständiga utdata till <code>/tmp/proxmenux-DESTINATION-backup-YYYYMMDD_HHMMSS.log</code> och, på misslyckande, erbjuder att öppna den i en rullande dialog. Loggsökvägen visas i sammanfattningen endast när filen har innehåll."
+      },
+      {
+        "topic": "Sidecar (endast lokal)",
+        "detail": "<code>hb_write_archive_sidecar</code> släpper en <code>*.proxmenux.json</code> bredvid det lokala arkivet så att Monitor identifierar det som en ProxMenux-värdbackup även efter flytt eller namnbyte."
+      },
+      {
+        "topic": "Avisering (slutförd/misslyckad)",
+        "detail": "<code>hb_notify_lifecycle \"complete\"</code> eller <code>\"fail\"</code> utlöses med varaktighet, arkivstorlek och — vid fel — den sista loggraden som ser ut att beskriva ett fel."
+      }
+    ]
+  },
+  "finishedScreens": {
+    "heading": "Vad en färdig backup ser ut",
+    "intro": "Samma slutförandehändelse uppträder av båda ingångspunkterna. TUI skriver ett sammanfattande block till terminalen; Monitor's Backups-fliken visar körningen i arkivlistan med storlek, varaktighet och statusmärken.",
+    "scriptsAlt": "ProxMenux Scripts TUI visar en färdig värd backup — destination, backup ID, snapshot väg, data storlek, varaktighet och kryptering tillstånd.",
+    "scriptsCaption": "Avslutad backup - ProxMenux Scripts (TUI). Slutförande blocket trycker destinationen, backup-ID, vilket resulterar i snapshot eller arkivnamn, datastorlek, varaktighet och krypteringstillstånd.",
+    "monitorAlt": "ProxMenux Monitor Backups-fliken som visar en färdig värdbackuppost med storlek, varaktighet, metodmärke och krypteringsindikator.",
+    "monitorCaption": "Avslutad backup - ProxMenux Monitor Backups-fliken. Den nya säkerhetskopian visas i arkivlistan med destinationsmetodens märke, storlek, varaktighet och - när det är tillämpligt - krypteringslåsindikatorn."
+  },
+  "whereNext": {
+    "heading": "Nästa steg",
+    "items": [
+      {
+        "label": "Destinationer",
+        "href": "/docs/backup-restore/destinations",
+        "tail": " - konfigurationsdetaljer för Local, PBS och Borg."
+      },
+      {
+        "label": "Planerade jobb",
+        "href": "/docs/backup-restore/scheduled-jobs",
+        "tail": " - kör samma backup obevakad på ett schema istället för interaktivt."
+      },
+      {
+        "label": "Återställande",
+        "href": "/docs/backup-restore/restoring",
+        "tail": " — flödet som förbrukar vad denna sida producerar."
+      }
+    ]
+  }
+}

web/messages/sv/docs/backup-restore/cross-kernel.json

@@ -0,0 +1,170 @@
+{
+  "meta": {
+    "title": "Återställning mellan kärnversioner — riktning, säkert urval och komplettering | ProxMenux",
+    "description": "Hur ProxMenux återställer en värdbackup på ett mål som kör en annan stor kärnversion. Dokument hur riktningen av felmatchen detekteras, det säkra subsetfiltret som hoppar över boot-kritiska vägar när målet kör en nyare kärna än backupen, och den fyrfasiga kärnan-agnostiska hydrering som återanvänder användarjustering som IOMMU, VFIO IDs och anpassade cmdline tokens utan att kopiera kernel-tied filer verbatim.",
+    "ogTitle": "ProxMenux Backup - cross-kernel restaurering och hydrering",
+    "ogDescription": "Återställning mellan kärnversioner med riktningskontroll, säkert urval och kärnoberoende komplettering.",
+    "twitterTitle": "Cross-kernel återställning | ProxMenux",
+    "twitterDescription": "Hur ProxMenux hanterar en återställning när målkärnan skiljer sig från säkerhetskopiorna."
+  },
+  "header": {
+    "title": "Återställning mellan kärnversioner",
+    "description": "Hur ProxMenux hanterar en återställning när målvärden kör en annan kärna från den som spelas in i backupen - särskilt när målet kör en nyare kärna. Dokument hur skillnaden upptäcks, hur startkritiska vägar som kan bryta målet filtreras, och hur användarens egen konfiguration återanvänds utan att kopiera kärnbundna filer verbatim.",
+    "section": "Säkerhetskopiering och återställning"
+  },
+  "intro": {
+    "title": "Varje kärnhopp hanteras annorlunda",
+    "body": "En Proxmox värd kärna identifieras av en version sträng som <code>6.17.13-2-pve</code>. De två första siffrorna (<strong>6.17</strong> i det här exemplet) definierar den stora versionen: när de ändras kan vissa konfigurationsfiler skrivna för den tidigare kärnan inte vara giltiga på den nya. När återställningen upptäcker att backupen och målet har olika stora kärnversioner, flödesgrenarna baserat på hoppets riktning - oavsett om backupen är äldre eller nyare än målet - eftersom de två fallen har motsatta fellägen. Säkerhetskopior nyare än målet återställs rent as-is (bänk-verifierad över flera kärnhopp). Säkerhetskopior äldre än målet behöver ett filter för att undvika att bryta målets start med konfiguration skriven för en kärna som sedan dess har ändrats."
+  },
+  "directionCheck": {
+    "heading": "Riktningskontroll",
+    "intro": "Under kompatibilitetskontrollen jämför <code>hb_compat_check</code> kärnan registrerad i backupens manifest mot målets nuvarande kärna (<code>uname -r</code>) och klassificerar återställningen i ett av tre fall, lagrad i den interna variabla <code>HB_COMPAT_KERNEL_DIRECTION</code>:",
+    "rows": [
+      {
+        "direction": "same",
+        "condition": "Den stora kärnversionen matchar mellan backup och mål.",
+        "behavior": "Det fullständiga återställningsflödet går oförändrat. Inget extra filter, ingen hydrering, inget särskilt meddelande i UI."
+      },
+      {
+        "direction": "bk_newer",
+        "condition": "Säkerhetskopians kärna är NYARE än målets (exempel: säkerhetskopian gjordes på 7.0 och målet kör 6.17).",
+        "behavior": "Hela återställningsflödet körs oförändrat som vid <code>same</code>, utan filter. Rapporterade tester visade ominstallation av drivrutiner för målkärnan, fungerande IOMMU-konfiguration och start av VM:ar med GPU-genomkoppling."
+      },
+      {
+        "direction": "bk_older",
+        "condition": "Säkerhetskopians kärna är ÄLDRE än målets (exempel: säkerhetskopian gjordes på 6.17 och målet kör 7.0).",
+        "behavior": "Det säkra filtret och fyrfasens hydrering nedan aktiveras. Återställningen fortsätter - målet reproducerar källan, men startkritiska filer kopieras inte."
+      }
+    ]
+  },
+  "whyBkNewerIsSafe": {
+    "heading": "Varför en backup med en nyare kärna än målet återställer oförändrad",
+    "body": "När återställningen går mot ett mål med en <em>äldre</em>-kärna än den som spelas in i backupen, är varje mekanism som återställningen beror på oberoende av kärnversionen. GPU-drivrutininstallatörer och andra PCI-enhetsinstallatörer upptäcker körkärnan med <code>uname -r</code> och sammanställer DKMS mot vad målet har. APT-paketet installerar binärer byggda för målets distribution. IOMMU cmdline tokens som <code>intel_iommu=on</code> är stabila över stora kärnversioner. Backupen bär vägar skrivna under en nyare kärna, men de vägar (modul svartlistor, GRUB standarder, initramfs config) är fortfarande giltig syntax på den äldre - kärnor ignorerar tokens de inte känner igen i stället för att misslyckas. Detta fall är likvärdigt i praktiken med en återställning av samma kärna, och ProxMenux behandlar det som sådant."
+  },
+  "safeSubsetFilter": {
+    "heading": "Det säkra filtret (endast när målkärnan är nyare)",
+    "intro": "När målkärnan är nyare än backupen, tillägger kompatibilitetskontrollen 16 boot-kritiska vägar från <code>hb_unsafe_paths_cross_version</code> till <code>RS_SKIP_PATHS</code>. Dessa vägar är uteslutna från återställningen eftersom att skriva en version av dem från en äldre kärna över ett mål som kör en nyare har orsakat kärnpaniker i bänkprov. Vägarna täcker fem kategorier:",
+    "categoryRows": [
+      {
+        "category": "Starthanterare",
+        "paths": "<code>/etc/default/grub</code>, <code>/etc/kernel</code>",
+        "reason": "GRUB standarder knutna till den tidigare kärnordern, och proxmox-boot-tool tillstånd (cmdline, ESP UUID, krokar) som refererar vägar och identifierare från den äldre installationen."
+      },
+      {
+        "category": "Kernel moduler och boot artefakter",
+        "paths": "<code>/etc/modules-load.d</code>, <code>/etc/modprobe.d</code>, <code>/etc/initramfs-tools</code>",
+        "reason": "Autoload listor som kan referera moduler döpt mellan kärn majors, modulalternativ som kanske inte gäller, initramfs krokar skrivna för den äldre kärnan."
+      },
+      {
+        "category": "Lagring stack och filsystem identitet",
+        "paths": "<code>/etc/fstab</code>, <code>/etc/multipath</code>, <code>/etc/iscsi</code>, <code>/etc/udev/rules.d</code>, <code>/etc/zfs</code>",
+        "reason": "UUID som kanske inte finns på denna installation, multipath drivrutiner som ändras mellan kärnor, iSCSI parametrar som utvecklas, udev regler som kan binda till icke-existerande delsystem, ZFS tillstånd (<code>zpool.cache</code> + <code>hostid</code>) som kan låsa poolen som främmande."
+      },
+      {
+        "category": "APT-källor",
+        "paths": "<code>/etc/apt</code>",
+        "reason": "APT-källor kan utlösa en nedgradering av kritiska paket på nästa uppgradering."
+      },
+      {
+        "category": "systemd",
+        "paths": "<code>/etc/systemd/system</code>, <code>/etc/systemd/journald.conf</code>, <code>/etc/systemd/logind.conf</code>, <code>/etc/systemd/system.conf</code>, <code>/etc/systemd/user.conf</code>",
+        "reason": "Enhetsåsidosättningar och .wants-länkar bundna till en äldre huvudversion av systemd samt inställningsnycklar som kanske inte kan tolkas av en nyare version."
+      }
+    ],
+    "outroBody": "Filtret kör FÖRE bekräftelsedialogen så att användaren ser den exakta listan över vägar som kommer att hoppas, kategoriseras av förnuftet. Återställningen fortsätter fortfarande - allt annat (VM-/LXC-konfiguration, nätverk, /etc/pve, användare, cron, ProxMenux tillstånd, paket, drivrutiner, /root) återställs normalt."
+  },
+  "hydration": {
+    "heading": "Kernel-agnostisk hydrering",
+    "intro": "Filtret utelämnar startkritiska filer, så kompletteringen återställer utvalda inställningar: IOMMU-parametrar, VFIO-ID:n, eget <code>GRUB_TIMEOUT</code> och nvidia-spärrlistor. Den körs när målkärnan är nyare. Cmdline-nycklar på målet bevaras och saknade moduler läggs till. Tillåtna GRUB-värden och användarfiler kan ersätta avvikande målinnehåll. Upprepning med samma indata är idempotent.",
+    "phaseRows": [
+      {
+        "phase": "1a - GRUB väg",
+        "detail": "För GRUB-värdar (ext4/lvm). <code>_rs_hyd_grub</code> sammanfogar parametrar från säkerhetskopians <code>manifest.kernel_params.cmdline_extra</code> i målets <code>GRUB_CMDLINE_LINUX_DEFAULT</code> och hoppar över nycklar som redan finns. Därefter återställs tillåtna <code>GRUB_*</code>-nycklar (<code>GRUB_TIMEOUT</code>, <code>GRUB_TIMEOUT_STYLE</code>, <code>GRUB_DEFAULT</code>, <code>GRUB_TERMINAL</code>, <code>GRUB_DISABLE_OS_PROBER</code>, <code>GRUB_SERIAL_COMMAND</code>, <code>GRUB_GFXMODE</code>, <code>GRUB_GFXPAYLOAD_LINUX</code>) från säkerhetskopians <code>/etc/default/grub</code> när värdena skiljer sig från målets."
+      },
+      {
+        "phase": "1b — systemd-boot / ZFS",
+        "detail": "För systemd-boot (vanligen ZFS på roten). <code>_rs_hyd_kernel_cmdline</code> sammanfogar användarparametrar från <code>cmdline_extra</code> i målets <code>/etc/kernel/cmdline</code> och bevarar målets startparametrar <code>root=</code>, <code>boot=</code> och <code>rootflags=</code>."
+      },
+      {
+        "phase": "2 — /etc/modules Sammanslagning",
+        "detail": "<code>_rs_hyd_modules</code> Lägger till moduler från <code>manifest.kernel_params.modules_loaded_at_boot</code> som finns i den vita listan (<code>vfio</code>, <code>vfio_pci</code>, <code>vfio_iommu_type1</code>, <code>vfio_virqfd</code>, <code>kvm</code>, <code>kvm_intel</code>, <code>kvm_amd</code>, <code>nvidia</code>, <code>nvidia_drm</code>, <code>nvidia_modeset</code>, <code>nvidia_uvm</code>, <code>i915</code>, <code>xe</code>) och inte redan närvarande i målets mål <code>/etc/modules</code>."
+      },
+      {
+        "phase": "3 — Kopiera tillåtna filer",
+        "detail": "<code>_rs_hyd_files</code> kopierar användarskrivna filer från staging rootfs till det levande målet när innehållet skiljer sig. Whitelist täcker VFIO/nvidia/blacklist-filer under <code>/etc/modprobe.d</code>, <code>/etc/modules-load.d</code> och ProxMenux VFIO bind regel + nvidia udev regler under <code>/etc/udev/rules.d</code>. Distro-ägda filer (<code>pve-blacklist.conf</code>, <code>mdadm.conf</code>, <code>nvme.conf</code>) är avsiktligt uteslutna - deras innehåll utvecklas mellan releaser."
+      },
+      {
+        "phase": "4 — Framtvinga ombyggnad efter uppstart",
+        "detail": "De fyra faserna skriver direkt till det levande målet UTANFÖR den normala återställningsledningen. För att göra de sammanslagna tokens/modulerna/filerna träder i kraft vid nästa start, <code>HB_HYDRATION_APPLIED=1</code> förökar genom <code>plan.env</code> för att <code>apply_pending_restore.sh</code>, som tvingar <code>NEEDS_INITRAMFS=1</code> och <code>NEEDS_GRUB=1</code> Oavsett vad som fanns i appliceringslistan. Post-boot dispatcher regenererar sedan initramfs och uppdaterar bootloader."
+      }
+    ]
+  },
+  "planCommit": {
+    "heading": "Plan och commit — användaren ser först en förhandsvisning",
+    "body": "Kompletteringen körs i två lägen. Innan bekräftelsedialogen kör ProxMenux <code>_rs_apply_bk_older_hydration</code> i <code>plan</code>-läge: det beräknar exakt vad som skulle slås samman, fyller <code>RS_HYDRATION_SUMMARY</code> med ett grönt block som listar varje åtgärd och returnerar utan att skriva. Bekräftelsedialogen visar att grönt block tillsammans med den gula listan över uteslutna sökvägar, så användaren ser I FÖRVÄG vad som kommer att återanvändas automatiskt. När användaren bekräftar, ProxMenux kör samma hjälpare i <code>commit</code> läge - samma faser, samma logik, men denna gång varje fas skriver till levande mål. Annullera bekräftelsedialogen lämnar målet orört."
+  },
+  "flowDiagram": {
+    "heading": "Flödet när målkärnan är nyare än backupens",
+    "intro": "Stegen som läggs till när målkärnan är nyare sitter inuti det normala återställningsflödet. Allt annat - varmt applicera, i väntan på förberedelse, paketinstallation, post-boot dispatcher - körs identiskt till en same-kernel restaurering.",
+    "diagram": "  ┌────────────────────────────────────────────────────────────┐\n  │ hb_compat_check                                             │\n  │   HB_COMPAT_KERNEL_DIRECTION = bk_older                     │\n  └───────────────────────────┬────────────────────────────────┘\n                              │\n                              ▼\n  ┌────────────────────────────────────────────────────────────┐\n  │ Add 16 boot-critical paths to RS_SKIP_PATHS                 │\n  │   /etc/default/grub, /etc/kernel, /etc/modules-load.d, ...  │\n  └───────────────────────────┬────────────────────────────────┘\n                              │\n                              ▼\n  ┌────────────────────────────────────────────────────────────┐\n  │ _rs_apply_bk_older_hydration \"plan\"                         │\n  │   Compute what would be merged                              │\n  │   Populate RS_HYDRATION_SUMMARY (green block)               │\n  │   No writes                                                 │\n  └───────────────────────────┬────────────────────────────────┘\n                              │\n                              ▼\n  ┌────────────────────────────────────────────────────────────┐\n  │ Confirmation dialog                                         │\n  │   Amber: paths skipped by safe-subset filter                │\n  │   Green: tokens/files reapplied by hydration                │\n  │   User accepts or cancels                                   │\n  └───────────────────────────┬────────────────────────────────┘\n                              │ (accepted)\n                              ▼\n  ┌────────────────────────────────────────────────────────────┐\n  │ _rs_apply_bk_older_hydration \"commit\"                       │\n  │   Phase 1a/1b: merge cmdline tokens + GRUB keys             │\n  │   Phase 2: append modules to /etc/modules                   │\n  │   Phase 3: copy whitelisted vfio/nvidia files               │\n  │   Set HB_HYDRATION_APPLIED=1                                │\n  └───────────────────────────┬────────────────────────────────┘\n                              │\n                              ▼\n  ┌────────────────────────────────────────────────────────────┐\n  │ Rest of the restore runs normally                           │\n  │   _rs_apply hot (skips RS_SKIP_PATHS)                       │\n  │   _rs_prepare_pending_restore (writes plan.env with         │\n  │     HB_HYDRATION_APPLIED=1)                                 │\n  │   packages.manual.list install                              │\n  │   Reboot                                                    │\n  │   apply_pending_restore.sh (forces NEEDS_INITRAMFS=1,       │\n  │     NEEDS_GRUB=1 because of the hydration flag)             │\n  │   apply_cluster_postboot.sh                                 │\n  │     update-initramfs -u -k all                              │\n  │     update-grub / proxmox-boot-tool refresh                 │\n  │     component --auto-reinstall                              │\n  └────────────────────────────────────────────────────────────┘"
+  },
+  "concreteExamples": {
+    "heading": "Konkreta exempel",
+    "intro": "Kompletteringen är inte abstrakt - det ger observerbara, korrekta resultat för vanliga scenarier. Två exempel som hydrering hanterar automatiskt:",
+    "rows": [
+      {
+        "scenario": "GPU-genomkoppling (VFIO)",
+        "detail": "Källan hade <code>intel_iommu=on iommu=pt</code> i cmdline, <code>vfio</code>/<code>vfio_pci</code>/<code>vfio_iommu_type1</code> i <code>/etc/modules</code>, en <code>/etc/modprobe.d/vfio.conf</code> med <code>options vfio-pci ids=10de:2216</code> och en <code>/etc/modprobe.d/blacklist-nvidia.conf</code>. Hydration sammanfogar cmdline-tokens i målets GRUB eller kernel cmdline, appends vfio-modulerna till <code>/etc/modules</code> och kopierar de två användarskrivna modprobe-filerna. På nästa start är IOMMU aktiv, VFIO-moduler laddas, GPU är bunden till vfio-pci och VM kommer upp med genomgående arbete."
+      },
+      {
+        "scenario": "Anpassade GRUB standarder",
+        "detail": "Källan hade <code>GRUB_TIMEOUT=1</code> och <code>GRUB_DISABLE_OS_PROBER=true</code>. Hydration läser båda nycklarna från säkerhetskopieringens <code>/etc/default/grub</code>, ser att de skiljer sig från den färska installationens standarder och skriver om de två linjerna i målets fil (som lämnar allt annat, inklusive <code>GRUB_DISTRIBUTOR</code>, orörd)."
+      }
+    ]
+  },
+  "callout": {
+    "warningTitle": "Vad kompletteringen utelämnar när målkärnan är nyare",
+    "warningBody": "Hydration återanvänder endast konfigurationen ProxMenux vet att vara säker över kärnversioner: IOMMU-tokens, VFIO-ID, vitlistade GRUB-nycklar och moduler från en fast lista (<code>vfio*</code>, <code>nvidia*</code>, <code>i915</code>, <code>xe</code>, <code>kvm*</code>). Allt utanför den uppsättningen - anpassade initramfs krokar under <code>/etc/initramfs-tools/hooks/</code>, icke-vitlistade filer under <code>/etc/modprobe.d/</code>, användarskrivna systemd-enhetsåsidosättningar - förblir uteslutna. Anledningen är konkret: dessa filer kan ringa kärnintern gränssnitt (modul API, <code>/sys</code> layout, <code>udev</code> krokar) som ändras mellan stora versioner och tillämpar dem verbatim över den nyare kärnan kan förhindra att målet startar. När exakt reproduktion av startkedjan krävs måste återställningen köras på en värd med samma stora kärnversion som backup."
+  },
+  "codeReference": {
+    "heading": "Där mekanismerna lever",
+    "intro": "För utvecklare som vill spåra eller förlänga cross-kernel beteende:",
+    "rows": [
+      {
+        "component": "Direktionsdetektering",
+        "location": "<code>hb_compat_check</code> i <code>lib_host_backup_common.sh</code>. Sätter <code>HB_COMPAT_KERNEL_DIRECTION</code>."
+      },
+      {
+        "component": "Sökvägslista för säkert urval",
+        "location": "<code>hb_unsafe_paths_cross_version</code> i <code>lib_host_backup_common.sh</code>. Ger <code>path\\treason</code>-linjer som används av både CLI-filtret och Web endpoint <code>/api/host-backups/restore/prepare</code>."
+      },
+      {
+        "component": "Hydrationsfaser",
+        "location": "<code>_rs_hyd_grub</code>, <code>_rs_hyd_kernel_cmdline</code>, <code>_rs_hyd_modules</code>, <code>_rs_hyd_files</code> i <code>backup_host.sh</code>. Orkestrerad av <code>_rs_apply_bk_older_hydration</code>."
+      },
+      {
+        "component": "Framtvingad ombyggnad efter uppstart",
+        "location": "<code>apply_pending_restore.sh</code> läser <code>HB_HYDRATION_APPLIED</code> från <code>plan.env</code> och tvingar <code>NEEDS_INITRAMFS=1</code>/<code>NEEDS_GRUB=1</code>."
+      },
+      {
+        "component": "Web Preview",
+        "location": "<code>/api/host-backups/restore/prepare</code> i <code>flask_server.py</code>. Läser in hjälpbiblioteket, kör <code>_rs_apply_bk_older_hydration</code> i planläge, returnerar åtgärderna till webbmodalen."
+      }
+    ]
+  },
+  "whereNext": {
+    "heading": "Vart ska man gå nästa",
+    "items": [
+      {
+        "label": "Återställande",
+        "href": "/docs/backup-restore/restoring",
+        "tail": " — Den fullständiga återställningspipeline denna sidas mekanismer ansluter till."
+      },
+      {
+        "label": "Hur det fungerar",
+        "href": "/docs/backup-restore/how-it-works",
+        "tail": " — manifestet och insamlingsrutinerna som skapar blocket <code>kernel_params</code> som kompletteringen läser."
+      }
+    ]
+  }
+}

web/messages/sv/docs/backup-restore/destinations/borg.json

@@ -0,0 +1,234 @@
+{
+  "meta": {
+    "title": "Borg-mål — förvarstyper, SSH-autentisering, kryptering | ProxMenux",
+    "description": "Borg-målet lagrar ProxMenux värdsäkerhetskopior i ett lokalt förvar, på en monterad extern disk eller på en fjärrserver via SSH. Beskriver sökordningen för borg-programmet, de fyra inledande SSH-nyckelalternativen, repokey-kryptering, sparade mål och lagringsregler per schemalagt jobb.",
+    "ogTitle": "ProxMenux Backup - Borg destination",
+    "ogDescription": "Så lagrar ProxMenux värdsäkerhetskopior i Borg-förvar med SSH-autentisering och repokey-kryptering.",
+    "twitterTitle": "Borg som mål för säkerhetskopior | ProxMenux",
+    "twitterDescription": "Lokala, USB och SSH-serverade Borg repositorier för värdbackups."
+  },
+  "header": {
+    "title": "Borg",
+    "description": "Borg-destinationen skriver värdbackups till ett Borg-förvar. Tre förvarstyper stöds: lokal filsystemväg, monterad extern disk eller fjärrserver via SSH. Chunk-nivå deduplicering över alla arkiv i förvaret och valfri repokey kryptering.",
+    "section": "Säkerhetskopiering och återställning"
+  },
+  "aboutBorg": {
+    "heading": "Vad Borg är",
+    "body": "Borg (även stavat BorgBackup) är en öppen källkod som deduplicerar backupverktyg som upprätthålls av Borg Backup community. Det lagrar varje arkiv som en uppsättning av variabel-längd bitar inuti ett arkiv; bitar delas över arkiv så åter backa upp oförändrade data har nästan noll lagringskostnad. Borg är inte knuten till Proxmox - det är ett allmänt ändamål backupverktyg som används i många miljöer. ProxMenux använder den som en av de tre destinationerna för värdbackups; varje Borg-specifik mekanism som beskrivs på denna sida (förvarstyper, borg-serve över SSH, repokey kryptering, beskärning) är standard Borg beteende."
+  },
+  "intro": {
+    "title": "Blockbaserad deduplicering med lokala förvar eller förvar via SSH",
+    "body": "Ett Borg-förvar lagrar block som delas mellan alla arkiv. Att säkerhetskopiera en oförändrad fil igen överför och lagrar därför inga nya data. ProxMenux kör <code>borg create</code> vid säkerhetskopiering och <code>borg extract</code> vid återställning. Förvaret kan ligga på samma filsystem som källan, på en monterad extern disk eller på en fjärrvärd via SSH."
+  },
+  "binarySourcing": {
+    "heading": "Det körbara borg-programmet",
+    "intro": "Borg är inte en bas beroende av ProxMenux installer. När en backup körs, <code>hb_ensure_borg</code> löser binären från fyra källor i ordning och returnerar den första som fungerar:",
+    "rows": [
+      {
+        "priority": "1",
+        "source": "Systemets <code>borg</code>",
+        "detail": "Om värden redan har <code>borg</code> installerat via APT (<code>which borg</code> löser), den binära används."
+      },
+      {
+        "priority": "2",
+        "source": "Cache för tillståndskatalogen",
+        "detail": "<code>/usr/local/share/proxmenux/borg</code> — sparat från en tidigare GitHub-nedladdning på värden."
+      },
+      {
+        "priority": "3",
+        "source": "Monitors AppImage-paket",
+        "detail": "<code>/usr/local/share/proxmenux/monitor-app/usr/bin/borg</code> - den AppImage buntar en signerad borg-linux64. Detta är offline-säker väg: en värd utan internet har fortfarande en fungerande <code>borg</code>."
+      },
+      {
+        "priority": "4",
+        "source": "GitHub nedladdning",
+        "detail": "<code>wget</code> mot <code>borg-linux64</code> URL under <code>github.com/borgbackup/borg/releases/</code>, verifierad mot en konstant SHA-256 i <code>lib_host_backup_common.sh</code> (<code>HB_BORG_LINUX64_SHA256</code>). På checksum missmatch binären kasseras och backupen aborter. Den nedladdade filen är cachad i tillståndskatalogen så efterföljande säkerhetskopior använder sökväg 2."
+      }
+    ]
+  },
+  "repoTypes": {
+    "heading": "Förvarstyper",
+    "intro": "Förvarstypen väljs när ett mål läggs till. Varje typ löser sig till en annan adress som Borg förstår.",
+    "rows": [
+      {
+        "type": "remote",
+        "url": "ssh://USER@HOST/RPATH",
+        "detail": "Repository bor på en fjärrserver som kör <code>borg serve</code>. Kräver en SSH-anslutning till den servern."
+      },
+      {
+        "type": "usb",
+        "url": "/mnt/MOUNTPOINT/borgbackup",
+        "detail": "Repository bor på en monterad extern disk (typiskt USB). Monteringen löses via <code>hb_prompt_mounted_path</code>, som upptäcker, monterar eller formaterar USB-partitioner efter behov."
+      },
+      {
+        "type": "local",
+        "url": "/backup/borgbackup (any absolute path)",
+        "detail": "Repository bor på en lokal katalog. Meningsfullt endast när målkatalogen är på en separat fysisk disk - ett förvar på samma disk som källan skyddar mot operatörsfel men inte mot diskfel."
+      }
+    ]
+  },
+  "serverSetup": {
+    "heading": "Förbereda Borg-servern (server sida)",
+    "intro": "<code>remote</code> repository typ förväntar sig en fungerande Borg server tillgänglig över SSH. ProxMenux startar inte själva servern - den tillåter bara en nyckel mot ett befintligt konto på den. Det här avsnittet dokumenterar vad servern behöver innan ProxMenux kan ansluta.",
+    "hostChoicesTitle": "Där servern kan leva",
+    "hostChoicesBody": "Alla Linux värd med SSH åtkomst kvalificerar. Vanliga inställningar:",
+    "hostChoicesItems": [
+      "En dedikerad NAS eller backup box (Debian, Ubuntu, TrueNAS SCALE med ett skal).",
+      "En LXC-behållare inuti en Proxmox-nod. Litet fotavtryck, isolerat från värden som kör säkerhetskopiorna.",
+      "En annan Proxmox värd på samma LAN, eller en VM var som helst nås över SSH."
+    ],
+    "lxcWarningTitle": "LXC som Borg server",
+    "lxcWarningBody": "Om Borg-servern körs i en LXC kräver generate-auto ett konto som tillåter SSH-inloggning med lösenord när nyckeln installeras. Annars används manuell nyckelinstallation eller alternativet generate-pct via PVE-värden.",
+    "requirementsTitle": "Krav på servern",
+    "requirementsRows": [
+      {
+        "requirement": "Körbart borg-program på <code>/usr/bin/borg</code>",
+        "detail": "<code>command=\"/usr/bin/borg serve ...\"</code>-linjen ProxMenux skriver i <code>authorized_keys</code> hårdkoder som väg. Installera via APT (<code>apt install borgbackup</code>) sätter den där. En fristående binär måste symlinkeras till <code>/usr/bin/borg</code>."
+      },
+      {
+        "requirement": "Ett dedikerat användarkonto (vanligtvis <code>borg</code>)",
+        "detail": "Äger förvarskatalogen och tar emot inkommande SSH-anslutningar. Behöver inte sudo eller skal åtkomst - authorized_keys-linjen inaktiverar interaktiva skal ändå."
+      },
+      {
+        "requirement": "En skrivbar repository katalog",
+        "detail": "Den väg som operatören ger ProxMenux (till exempel <code>/backup/borgbackup</code>) måste finnas på servern och ägas av borganvändaren."
+      },
+      {
+        "requirement": "SSH daemon accepterar borganvändaren",
+        "detail": "<code>PubkeyAuthentication yes</code> (standard). Lösenordsautentisering behövs endast för en-shot <em>generate-auto</em>-flödet - efter att nyckeln är installerad kan servern inaktivera lösenord auth helt."
+      }
+    ],
+    "minimalSetupTitle": "Minimal serverkonfiguration",
+    "minimalSetupBody": "På en Borg-server med Debian eller Ubuntu ger fyra kommandon som root en grundkonfiguration:",
+    "minimalSetupCmd": "apt install borgbackup\nuseradd -m -d /home/borg -s /bin/bash borg\nmkdir -p /backup/borgbackup\nchown borg:borg /backup/borgbackup",
+    "minimalSetupNote": "När servern är förberedd och SSH-lösenordsinloggning är tillgänglig kan <code>generate-auto</code> installera nyckeln via ett konto som får skriva i borg-användarens authorized_keys. Senare säkerhetskopior använder nyckeln, begränsad till <code>borg serve</code> på den konfigurerade sökvägen. Utan lösenordsinloggning installeras nyckeln manuellt eller via PVE-värden."
+  },
+  "sshAuth": {
+    "heading": "SSH autentisering (klientsida)",
+    "intro": "Remote Borg repositorier är tillgängliga över SSH. Anslutningen går från ProxMenux-värden till ett användarkonto på Borg-servern som kör <code>borg serve</code>. Den här användaren heter vanligtvis <code>borg</code>, inte admin/root-användaren av servern - borg-serve-kommandoraden låser anslutningen till den specifika förvaringsbanan (se de viktigaste strategierna nedan).",
+    "strategiesTitle": "SSH-nyckelalternativ",
+    "strategiesIntro": "När ett fjärrmål läggs till frågar ProxMenux efter SSH-användare, värd och fjärrsökväg och erbjuder fyra autentiseringsval. Alternativet generate-pct erbjuds om lösenordsautentisering nekas. Lägena beskrivs nedan:",
+    "strategyRows": [
+      {
+        "mode": "generate-auto",
+        "label": "Rekommenderas",
+        "detail": "ProxMenux skapar eller återanvänder ett ed25519-nyckelpar på <code>~/.ssh/borg_proxmenux_HOST_ed25519</code> och använder <code>sshpass</code> för att testa inloggningen och installera den offentliga nyckeln i <code>~borg/.ssh/authorized_keys</code>. Lösenordet tillhör ett konto som får skriva i filen, oftast root eller borg. Det används under installationen och sparas inte."
+      },
+      {
+        "mode": "generate-manual",
+        "label": "Inget admin lösenord på denna värd",
+        "detail": "ProxMenux genererar nyckelparet som ovan men visar hela <code>authorized_keys</code>-linjen för operatören att klistra in manuellt i servern. Admin lösenord lämnar aldrig ProxMenux värd eftersom det aldrig bett om."
+      },
+      {
+        "mode": "generate-pct",
+        "label": "Borg server är en PVE LXC",
+        "detail": "Borg-servern körs inuti en LXC på en PVE-nod. ProxMenux tillåter nyckeln via <code>pct exec</code> från PVE-värden - root på PVE-värden skriver in i LXC <code>~borg/.ssh/authorized_keys</code> utan att behöva SSH i LXC själv."
+      },
+      {
+        "mode": "existing",
+        "label": "Använd en befintlig nyckel",
+        "detail": "ProxMenux skannar <code>/root/.ssh/</code> och <code>$HOME/.ssh/</code> för parseable ed25519/RSA privata nycklar och listar dem. Operatören väljer en eller bläddrar manuellt till en icke-standardväg."
+      },
+      {
+        "mode": "none",
+        "label": "Standard SSH konfig",
+        "detail": "Ingen anpassad nyckel - Borg är beroende av värdens standard SSH-konfiguration (vanligtvis <code>~/.ssh/id_rsa</code> eller en SSH-agent)."
+      }
+    ],
+    "restrictTitle": "authorized_keys-linjen",
+    "restrictBody": "För varje skapad nyckel begränsar raden <code>authorized_keys</code> som ProxMenux skriver på servern nyckeln till följande borg-serve-anrop för den konfigurerade förvarssökvägen:",
+    "restrictLine": "command=\"/usr/bin/borg serve --restrict-to-path RPATH\",restrict PUBKEY",
+    "restrictNote": "<code>command=</code> tvingar varje SSH-session med hjälp av den här nyckeln för att bara köra borg-serve-kommandot; <code>restrict</code> inaktiverar portöverföring, agentöverföring, X11-överföring och PTY-tilldelning. Nyckeln kan inte användas för att öppna ett interaktivt skal på servern eller för att komma åt någon annan förvaringsväg, även om kontot har bredare privilegier."
+  },
+  "savedTargets": {
+    "heading": "Sparade mål",
+    "intro": "Ett sparat mål behåller förvarskonfigurationen under ett tydligt namn, så att uppgifterna inte behöver anges igen. Filer i ProxMenux tillståndskatalog:",
+    "rows": [
+      {
+        "file": "borg-targets.txt",
+        "content": "En linje per mål: <code>NAME|REPO|SSH_KEY_PATH|ENCRYPT_MODE</code>. Läs av <code>hb_collect_borg_configs</code> för att befolka målvalsmenyn."
+      },
+      {
+        "file": "borg-pass-NAME.txt",
+        "content": "Lösenfras för målet som anges som NAME ovan (<code>chmod 600</code>). Finns endast om repokey-kryptering har valts."
+      }
+    ],
+    "outro": "Det är valfritt att spara målet. Om frågan avböjs sparas ingen namngiven målkonfiguration, men en skapad SSH-nyckel tas inte bort. Om repokey aktiveras utan ett sparat mål lagrar ProxMenux ändå lösenfrasen i den äldre filen borg-pass.txt."
+  },
+  "encryption": {
+    "heading": "Kryptering",
+    "body": "Repositorier inleds med ett krypteringsläge via <code>hb_borg_init_if_needed</code>: den moderna <code>borg repo-create -e MODE</code> när den är tillgänglig, eller arvet <code>borg init --encryption=MODE</code>. ProxMenux avslöjar två lägen: <code>repokey</code> (standard) och <code>none</code>. I <code>repokey</code>-läget lagrar Borg krypteringsnyckeln inuti själva förvaret; tillgång kräver en passfras, som ProxMenux uppmanar till två gånger med match validering och lagrar i <code>borg-pass-NAME.txt</code> för sparade mål, annars i den äldre fil som beskrivs ovan. En obligatorisk bekräftelsedialog visas efter passfrasen sparas: passfrasen är det enda sättet att komma åt krypterade arkiv och förlora det gör varje arkiv i förvaret oåterkallelig."
+  },
+  "runtimeEnv": {
+    "heading": "Runtime miljö",
+    "intro": "ProxMenux exporterar följande miljövariabler innan <code>borg</code>. De konfigurerar anslutningen och låser upp förvaret utan att bädda in hemligheter i kommandoraden.",
+    "rows": [
+      {
+        "var": "BORG_RSH",
+        "value": "ssh -i SSH_KEY_PATH -o IdentitiesOnly=yes -o StrictHostKeyChecking=accept-new [-p PORT]",
+        "purpose": "Fjärrskalskommandot som Borg använder för SSH-förvar. En vald nyckel lägger till identitetsalternativen; en annan port än standard lägger till -p PORT. Utan egen nyckel och med standardport lämnas variabeln osatt och Borg använder värdens SSH-konfiguration."
+      },
+      {
+        "var": "BORG_PASSPHRASE",
+        "value": "(passfras från borg-pass-NAME.txt)",
+        "purpose": "låser upp repokey. Ange endast när målet använder <code>repokey</code>-kryptering. Aldrig visas i processargumentlistan."
+      },
+      {
+        "var": "BORG_ENCRYPT_MODE",
+        "value": "repokey | none",
+        "purpose": "Används av <code>hb_borg_init_if_needed</code> när du startar ett förvar som ännu inte existerar. Ignorerad av <code>borg create</code> på befintliga repositorier."
+      },
+      {
+        "var": "BORG_RELOCATED_REPO_ACCESS_IS_OK",
+        "value": "yes",
+        "purpose": "Undertrycker den interaktiva prompten Borg höjer när förvaringsadressen skiljer sig från webbadressen som den ursprungligen nåddes från (gemensamt efter ett monteringsnamn eller SSH-värd som nås via ny adress)."
+      },
+      {
+        "var": "BORG_UNKNOWN_UNENCRYPTED_REPO_ACCESS_IS_OK",
+        "value": "yes",
+        "purpose": "Undertrycker den interaktiva prompten Borg höjer första gången ett okrypterat förvar nås från en ny klient."
+      }
+    ]
+  },
+  "archiveFormat": {
+    "heading": "Arkivnamn och retention",
+    "intro": "Varje backup skapar ett nytt arkiv inuti förvaret.",
+    "namePattern": "hostcfg-HOSTNAME-YYYYMMDD_HHMMSS",
+    "retentionBody": "För schemalagda jobb kör <code>run_scheduled_backup.sh</code> <code>borg prune</code> mot förvaret efter varje framgångsrik backup med lagringsvärdena konfigurerade på jobbet (<code>--keep-last</code>, <code>--keep-daily</code>, <code>--keep-weekly</code>). Interaktiva säkerhetskopior inte beskär."
+  },
+  "restoreAccess": {
+    "heading": "Hämta vid återställning",
+    "body": "Återställningsflödet listar arkiv med <code>borg list REPO</code> och extraherar den valda med <code>borg extract REPO::ARCHIVE-NAME</code> i en staging katalog som <code>_rs_check_layout</code> matar till standardåterställning pipeline. För manuell hämtning utanför ProxMenux samma kommandon arbete; det extraherade trädet är den standard tre-payload layout som beskrivs i <em>Hur det fungerar</em>."
+  },
+  "references": {
+    "heading": "Referenser",
+    "intro": "Officiell Borg-dokumentation för komponenterna ProxMenux är beroende av.",
+    "items": [
+      {
+        "label": "Borg dokumentation",
+        "href": "https://borgbackup.readthedocs.io/",
+        "tail": " - huvudingångspunkt som täcker koncept, distribution, snabbstart och varje kommando."
+      },
+      {
+        "label": "borg create",
+        "href": "https://borgbackup.readthedocs.io/en/stable/usage/create.html",
+        "tail": " - kommandot ProxMenux åberopar varje backup, med alla stödda flaggor."
+      },
+      {
+        "label": "Repository kryptering",
+        "href": "https://borgbackup.readthedocs.io/en/stable/usage/init.html#encryption-mode",
+        "tail": " - krypteringslägen Borg stöder, inklusive repokey som ProxMenux använder som standard."
+      },
+      {
+        "label": "borg serve och driftsättning via SSH",
+        "href": "https://borgbackup.readthedocs.io/en/stable/deployment/central-backup-server.html",
+        "tail": " - hur man ställer in en central Borg-server som nås över SSH, inklusive borg-serve-kommandot och restrict-to-path-flaggan ProxMenux skriver i authorized_keys."
+      },
+      {
+        "label": "borg prune",
+        "href": "https://borgbackup.readthedocs.io/en/stable/usage/prune.html",
+        "tail": " — lagringsreglerna bakom --keep-last / --keep-daily / --keep-weekly som ProxMenux tillämpar per schemalagt jobb."
+      }
+    ]
+  }
+}

web/messages/sv/docs/backup-restore/destinations/index.json

@@ -0,0 +1,110 @@
+{
+  "meta": {
+    "title": "Destinationer för säkerhetskopior — lokalt, Proxmox Backup Server, Borg | ProxMenux",
+    "description": "Tre lagringsbackender tar emot samma säkerhetskopieringsinnehåll från ProxMenux: ett lokalt .tar.zst-arkiv på ett skrivbart filsystem, en PBS-säkerhetskopia i en Proxmox Backup Server-datastore eller ett Borg-arkiv i ett lokalt eller fjärranslutet Borg-arkivlager. Varje backend har egna egenskaper för komprimering, deduplicering, kryptering och nätverk.",
+    "ogTitle": "ProxMenux mål för säkerhetskopior",
+    "ogDescription": "Lokal, Proxmox Backup Server och Borg - tre lagringsbackends för samma värdbackup payload.",
+    "twitterTitle": "Destinationer för ProxMenux-säkerhetskopior | ProxMenux",
+    "twitterDescription": "Lokal arkiv, Proxmox Backup Server och Borg backends för värdbackups."
+  },
+  "header": {
+    "title": "Destinationer",
+    "description": "Tre lagringsbackends som stöds av ProxMenux Backup: lokal arkiv, Proxmox Backup Server (rekommenderas) och Borg. Varje får samma tre-payload arkiv; de skiljer sig i lagringsformat, deduplicering, krypteringsmodell och nätverkskrav.",
+    "section": "Säkerhetskopiering och återställning"
+  },
+  "intro": {
+    "title": "Samma nyttolast, tre backends",
+    "body": "Varje säkerhetskopia skapar samma tre datablock (rootfs, manifest, program). Det som skiljer destinationerna åt är hur innehållet lagras och hämtas inför en återställning. Varje backend är en separat funktion i <code>backup_host.sh</code> — <code>_bk_local</code>, <code>_bk_pbs</code>, <code>_bk_borg</code> — men alla tre använder samma tillfälliga förberedelsesteg (<code>hb_prepare_staging</code>) och samma återställningskod. Valet av destination påverkar bara skrivning och hämtning; det ändrar inte hur återställningen fungerar eller använder arkivet."
+  },
+  "comparison": {
+    "heading": "Funktionsjämförelse",
+    "intro": "Följande tabell listar de konkreta skillnaderna mellan de tre backends som de beter sig i ProxMenux idag. Alla värden beskriver observerat beteende av backend själv, inte redaktionella rekommendationer.",
+    "rows": [
+      {
+        "feature": "Lagringsformat",
+        "local": "Enkel <code>.tar.zst</code>-fil (eller <code>.tar.gz</code> om <code>zstd</code> är frånvarande).",
+        "pbs": "PBS-säkerhetskopia (<code>.pxar</code>-block i datastoren).",
+        "borg": "Borg arkiv inuti ett Borg-förvar (segmentfiler)."
+      },
+      {
+        "feature": "Kompression",
+        "local": "zstd (standardnivå) via <code>tar --zstd</code>. gzip fallback.",
+        "pbs": "Hanteras av proxmox-backup-client. ProxMenux åsidosätter inte komprimeringsinställningarna.",
+        "borg": "Borgs inbyggda komprimering. ProxMenux anropar borg create utan att åsidosätta komprimeringsinställningarna."
+      },
+      {
+        "feature": "Deduplicering",
+        "local": "Ingen. Varje backup är ett fullt oberoende arkiv.",
+        "pbs": "Full chunk-nivå deduplicering över alla säkerhetskopior i databutiken.",
+        "borg": "Full chunk-nivå deduplicering över alla arkiv i förvaret."
+      },
+      {
+        "feature": "Kryptering i vila",
+        "local": "Ingen (förlitar sig på skydd av filsystemnivå).",
+        "pbs": "Valfri kryptering på klientsidan med en nyckelfil. När den är aktiverad laddas återställningsbloben upp som en separat säkerhetskopieringsgrupp.",
+        "borg": "Valfri repokey kryptering (nyckel lagrad i repan, upplåst med en passfras)."
+      },
+      {
+        "feature": "Bevarande / rensning",
+        "local": "Tillämpas per schemalagt jobb via <code>KEEP_LAST</code>. Gamla arkiv tas bort tillsammans med sina sidofiler och körningsloggar. Interaktiva säkerhetskopior utför ingen rensning.",
+        "pbs": "Tillämpas per schemalagt jobb via <code>proxmox-backup-client prune --keep-last / --keep-daily / --keep-weekly</code>. Interaktiva säkerhetskopior utför ingen rensning.",
+        "borg": "Tillämpas per schemalagt jobb via <code>borg prune --keep-last / --keep-daily / --keep-weekly</code>. Interaktiva säkerhetskopior utför ingen rensning."
+      },
+      {
+        "feature": "Nätverk",
+        "local": "Ingen. Skriver till en lokal monteringspunkt (vanligtvis en intern disk eller en USB-enhet).",
+        "pbs": "TCP till PBS-servern (standardport 8007). Kräver PBS-uppgifter + fingeravtryck.",
+        "borg": "Lokal filsystemväg eller SSH tunnel till en avlägsen Borg värd."
+      },
+      {
+        "feature": "Beroenden",
+        "local": "<code>tar</code>, <code>zstd</code> (på Proxmox som standard).",
+        "pbs": "Paketet <code>proxmox-backup-client</code> (medföljer Proxmox VE 8+).",
+        "borg": "<code>borg</code> binär. Autotillhandahållen av ProxMenux från Monitor AppImage-paketet när det saknas."
+      },
+      {
+        "feature": "Åtkomst för återställning",
+        "local": "Alla värdar med tar+zstd kan extrahera arkivet. Inget PBS/Borg behövs.",
+        "pbs": "Kräver <code>proxmox-backup-client</code>, PBS-inloggningsuppgifter och nyckelfilen (om säkerhetskopian är krypterad).",
+        "borg": "Kräver <code>borg</code> + sökvägen till arkivlagret + passfrasen (om krypterad)."
+      }
+    ],
+    "captionCode": "feature",
+    "captionLocal": "Lokal",
+    "captionPbs": "Proxmox Backup Server (rekommenderas)",
+    "captionBorg": "Borg"
+  },
+  "sameArchive": {
+    "heading": "Arkivlayouten ändras inte med destinationen",
+    "body": "Alla tre destinationerna innehåller samma struktur med <code>rootfs/</code> + <code>metadata/</code> + <code>manifest.json</code> som beskrivs i <em>Så fungerar det</em>. Ett uppackat lokalt <code>.tar.zst</code>-arkiv, ett <code>.pxar</code>-arkiv återställt från PBS och ett Borg-arkiv uppackat med <code>borg extract</code> ger samma katalogträd. Återställningskoden (<code>_rs_check_layout</code>, <code>_rs_apply</code>, <code>_rs_prepare_pending_restore</code>) läser samma tre datablock utan att behöva veta vilken destination de kommer från."
+  },
+  "extractStandalone": {
+    "heading": "Extrahera en backup utanför ProxMenux",
+    "intro": "Alla tre arkivformat kan läsas med standardverktyg utan ProxMenux installerat på läsvärden. Kommandona nedan producerar samma katalogträd som en återställning konsumerar internt.",
+    "localCmd": "# From a local .tar.zst archive:\ntar --zstd -xf hostcfg-HOST-TIMESTAMP.tar.zst\n\n# From a .tar.gz fallback:\ntar -xzf hostcfg-HOST-TIMESTAMP.tar.gz",
+    "pbsCmd": "# From a PBS backup (requires proxmox-backup-client):\nproxmox-backup-client restore \\\n    --repository USER@REALM@HOST:DATASTORE \\\n    host/hostcfg-HOST/BACKUP-TIME \\\n    hostcfg.pxar /tmp/hostcfg\n\n# Add --keyfile KEY-PATH when the backup is encrypted.",
+    "borgCmd": "# Från ett Borg-arkiv (kräver borg och passfrasen för krypterade arkivlager):\nborg extract REPO-PATH::ARCHIVE-NAME\n\n# Från ett fjärranslutet arkivlager via SSH:\nborg extract ssh://USER@HOST:PORT/REPO-PATH::ARCHIVE-NAME",
+    "note": "Det extraherade trädet kan sedan inspekteras manuellt eller matas till en manuell återställning. Se de enskilda destinationssidorna för det exakta hämtningsflödet ProxMenux använder under huven."
+  },
+  "whereNext": {
+    "heading": "Detaljer per destination",
+    "intro": "Varje destination har sin egen sida som täcker konfigurationsflödet, on-disk-formatet och hämtningskommandot som används av återställningen.",
+    "items": [
+      {
+        "label": "Lokalt arkiv",
+        "href": "/docs/backup-restore/destinations/local",
+        "tail": " — förkonfigurera ett lokalt mål, montera USB-enheter, skydd mot att arkivet inkluderar sig självt samt JSON-sidofilen som låter Monitor identifiera filen."
+      },
+      {
+        "label": "Proxmox Backup Server (rekommenderas)",
+        "href": "/docs/backup-restore/destinations/pbs",
+        "tail": " — val av datastore, inloggningsuppgifter och certifikatets fingeravtryck, nyckelfilens livscykel, återställningspassfras samt uppladdning av återställningsbloben till PBS för återställning efter en nyinstallation."
+      },
+      {
+        "label": "Borg",
+        "href": "/docs/backup-restore/destinations/borg",
+        "tail": " — lokala arkivlager och arkivlager via SSH, var Borg-binären hämtas (system / cache / Monitors AppImage-paket / GitHub), initiering av arkivlager, hantering av passfraser och SSH-nycklar för fjärranslutna arkivlager."
+      }
+    ]
+  }
+}

web/messages/sv/docs/backup-restore/destinations/local.json

@@ -0,0 +1,75 @@
+{
+  "meta": {
+    "title": "Lokalt arkivmål — tar.zst på ett filsystem eller en USB-enhet | ProxMenux",
+    "description": "Det lokala säkerhetskopieringsmålet skriver ett enda .tar.zst-arkiv till en skrivbar katalog: en intern disk, en Proxmox-monteringspunkt, en NFS-delning eller en USB-enhet. Sidan beskriver konfigurationen, hur USB-enheter upptäcks och monteras, skyddet mot att skriva arkivet till en sökväg som säkerhetskopieras samt JSON-sidofilen som identifierar arkivet.",
+    "ogTitle": "ProxMenux Backup - Lokal arkiv destination",
+    "ogDescription": "Hur ProxMenux skriver lokala säkerhetskopior som .tar.zst arkiv och hur man konfigurerar destinationskatalogen eller USB-enheten.",
+    "twitterTitle": "Lokal backup destination | ProxMenux",
+    "twitterDescription": "Hur ProxMenux skriver lokala säkerhetskopior som .tar.zst arkiv på ett filsystem eller USB-enhet."
+  },
+  "header": {
+    "title": "Lokalt arkiv",
+    "description": "Det lokala målet skriver ett enda komprimerat tar-arkiv till en skrivbar katalog på värden: en intern disk, ett monterat NFS- eller SMB-filsystem eller en USB-enhet.",
+    "section": "Säkerhetskopiering och återställning"
+  },
+  "intro": {
+    "title": "En fristående fil",
+    "body": "En lokal säkerhetskopia producerar en enda <code>hostcfg-HOST-TIMESTAMP.tar.zst</code>-fil (eller <code>.tar.gz</code> när <code>zstd</code> är frånvarande). Filen innehåller hela arkivträdet - <code>manifest.json</code>, <code>metadata/</code> och <code>rootfs/</code> - och kan återställas på någon Proxmox värd med ProxMenux återställningsflöde, eller extraheras manuellt med <code>tar --zstd -xf</code> på alla Linux-system. Ingen server, ingen initiering av arkivlager, inget externt beroende. Detta är destinationen med den kortaste återhämtningsvägen när varken PBS eller Borg är tillgänglig."
+  },
+  "targetConfig": {
+    "heading": "Konfigurera målkatalogen",
+    "intro": "Det lokala målet är en <strong>enda sparad målkatalog</strong> — inte en lista. ProxMenux sparar användarens val i <code>/usr/local/share/proxmenux/local-target.conf</code> och läser det vid varje säkerhetskopiering. Om inget mål har konfigurerats används standardvärdet <code>HB_LOCAL_TARGET_DEFAULT = /var/lib/vz/dump</code> (samma katalog som Proxmox använder för sina egna <code>vzdump</code>-utdata). Målet konfigureras via <em>Konfigurera säkerhetskopieringsmål → Lokala mål</em>:",
+    "options": [
+      "<strong>Använd standard (<code>/var/lib/vz/dump</code>).</strong> Proxmox lokal lagring. Finns på varje Proxmox-installation; arkivet sitter bredvid vzdump-utdata och hämtas av fliken Monitor's Backups automatiskt.",
+      "<strong>Ange en anpassad sökväg.</strong> Alla absoluta filsystemsökvägar kan användas: en NFS-montering, en SMB-delning monterad via <code>fstab</code>, ett särskilt ZFS-dataset eller en andra intern disk. ProxMenux kontrollerar att sökvägen finns och är en katalog innan valet sparas.",
+      "<strong>Välj en USB-enhet.</strong> Öppnar USB-undermenyn (nedan), som upptäcker flyttbara enheter och erbjuder sig att montera eller formatera en."
+    ]
+  },
+  "usbFlow": {
+    "heading": "USB-enhetsdetektering och montering",
+    "intro": "USB-undermenyn listar partitioner på flyttbara enheter som rapporteras av <code>lsblk</code>. Varje partition visas med storlek, filsystemets etikett och aktuellt tillstånd. Tillståndet avgör vilken åtgärd ProxMenux erbjuder.",
+    "statesTitle": "De tre enhetstillstånden",
+    "stateRows": [
+      {
+        "state": "monterad",
+        "shown": "Storlek · etikett · [fstype] · → /mount/point",
+        "action": "Partitionen är redan monterad. Om den väljs sparas dess aktuella monteringspunkt som lokalt mål. Ingen ny montering utförs."
+      },
+      {
+        "state": "ej monterad",
+        "shown": "Storlek · etikett · [fstype] · (ej monterad — kommer att monteras)",
+        "action": "Ett filsystem är närvarande men inte monterat. På bekräftelse kör ProxMenux <code>hb_mount_usb_partition</code>: skapar <code>/mnt/backup-LABEL</code> (eller en UUID-baserad väg om det inte finns någon etikett), monterar partitionen och sparar monteringspunkten som det lokala målet."
+      },
+      {
+        "state": "tom",
+        "shown": "Storlek · rå USB-disk — inget filsystem (kommer att FORMATERAS)",
+        "action": "Enheten har inget filsystem. Denna destruktiva åtgärd skyddas av två bekräftelser. Först förklarar en Ja/Nej-dialog att disken raderas. Sedan måste användaren <strong>skriva den exakta enhetssökvägen</strong> (t.ex. <code>/dev/sdb</code>) innan ProxMenux skapar en ny GPT med en ext4-partition och monterar den."
+      }
+    ],
+    "notMountedFallback": "Om ingen USB-enhet upptäcks visar undermenyn ett vanligt inmatningsfält. Användaren kan ange valfri sökväg till en monteringspunkt; om sökvägen inte är en registrerad monteringspunkt visas en varning i en bekräftelsedialog innan processen fortsätter."
+  },
+  "safetyCheck": {
+    "heading": "Säkerhetskontroll - destination inuti en backupbana",
+    "body": "Innan du skriver arkivet, verifierar <code>_bk_local</code> att destinationskatalogen <strong>inte</strong> är en undersökväg till någon katalog som säkerhetskopieras. Ett vanligt misstag skulle vara att lägga till <code>/root</code> till profilen och välja <code>/root/backups</code> som destination — arkivet skulle då inkludera sig självt, antingen producera ett korrupt arkiv eller växa utan gräns tills skivan fylls. Kontrollen löser båda sökvägarna med <code>readlink -m</code>, jämför dem och, vid konflikt, avbryter säkerhetskopieringen med en dialogruta som namnger den motstridiga sökvägen och listar tre sätt att lösa den: välj en destination utanför den motstridiga sökvägen, ta bort den anpassade posten som innehåller destinationen, eller använd anpassat läge för att avmarkera den motstridiga sökvägen för denna körning."
+  },
+  "archiveFormat": {
+    "heading": "Arkivformat och komprimering",
+    "intro": "Utdatafilnamnet bäddar in källvärdnamnet och backup timestamp så att en katalog med flera arkiv sorterar kronologiskt och varje fil är självidentifierande.",
+    "namePattern": "hostcfg-HOSTNAME-YYYYMMDD_HHMMSS.tar.zst",
+    "compressionTitle": "Kompression",
+    "compressionBody": "Huvudmetoden använder <code>tar --zstd -cf</code> — ett enda kommando som komprimerar med zstd:s standardnivå. Om <code>zstd</code> saknas på källan (ovanligt på Proxmox, men möjligt på minimala installationer) används <code>gzip</code>. Om <code>pv</code> finns vid denna reservmetod läggs en förloppsindikator till så att användaren ser arkivstorleken växa i realtid; utan <code>pv</code> används vanlig <code>tar -czf</code> utan förloppsutdata.",
+    "sourceTitle": "Vad går in i arkivet",
+    "sourceBody": "Kommandot tar anropas med <code>-C \"$staging_root\" .</code> och arkiverar därmed <strong>hela roten i den tillfälliga katalogen</strong>: <code>rootfs/</code>, <code>metadata/</code> och <code>manifest.json</code>. Alla tre datablocken ligger bredvid varandra högst upp i tar-arkivet. Uppackningen ger exakt samma träd som återställningskoden använder."
+  },
+  "sidecar": {
+    "heading": "JSON-sidofilen",
+    "intro": "Varje framgångsrik lokal backup producerar en följeslagare fil: <code>HOSTNAME-TIMESTAMP.tar.zst.proxmenux.json</code>, skriven bredvid arkivet av <code>hb_write_archive_sidecar</code>. Denna lilla JSON-fil låter ProxMenux Monitor identifiera arkivet som en ProxMenux-värdbackup även om det senare flyttas, bytas namn eller arkiveras någon annanstans.",
+    "contentTitle": "Sidofilens innehåll",
+    "contentBody": "Sidofilen lagrar schemaversionen, om säkerhetskopian kom från en interaktiv körning eller ett schemalagt jobb (<code>kind</code>), jobb-ID för schemalagda körningar, det profilläge som används (<code>default</code> eller <code>custom</code>), källvärdnamnet, den ursprungliga arkivbasnamnet, en tidsstämpel för skapandet i ISO-8601-format och arkivstorleken i byte.",
+    "whyBody": "Monitors Backups-flik söker igenom konfigurerade lokala kataloger efter <code>*.proxmenux.json</code>-sidofiler, inte efter <code>*.tar.zst</code>-filer, eftersom en <code>.tar.zst</code> utan sidofil kanske inte är en ProxMenux-säkerhetskopia. Sökningen är snabb (JSON-filer är små) och kopplingen fungerar även efter namnbyte om sidofilen får ett motsvarande nytt namn."
+  },
+  "restoreAccess": {
+    "heading": "Återställande från ett lokalt arkiv",
+    "body": "ProxMenux återställningsflödet upptäcker lokala arkiv genom att skanna det konfigurerade lokala målet efter sidofiler och visa dem i arkivlistan. Valet av ett arkiv utlöser <code>_rs_check_layout</code>, som extraherar tarball i en staging katalog och bekräftar strukturen med tre datablock innan du fortsätter. För manuell utvinning utanför ProxMenux ger <code>tar --zstd -xf hostcfg-HOSTNAME-TIMESTAMP.tar.zst -C /tmp/hostcfg</code> samma träd som återställningskoden förbrukar."
+  }
+}

web/messages/sv/docs/backup-restore/destinations/pbs.json

@@ -0,0 +1,113 @@
+{
+  "meta": {
+    "title": "Proxmox Backup Server destination - förvar, kryptering, återhämtning | ProxMenux",
+    "description": "PBS-målet lagrar ProxMenux värdsäkerhetskopior som PBS-säkerhetskopior. Sidan beskriver automatisk identifiering från /etc/pve/storage.cfg, manuell PBS-konfiguration, uppladdning av .pxar, klientkryptering med nyckelfil och en valfri återställningskopia skyddad med lösenfras samt återställning av nyckeln från flera källor på en nyinstallerad värd.",
+    "ogTitle": "ProxMenux Backup - Proxmox Backup Server destination",
+    "ogDescription": "Hur ProxMenux skriver värdbackups till Proxmox Backup Server med klient-side keyfile kryptering och återhämtning escrow.",
+    "twitterTitle": "PBS som mål för säkerhetskopior | ProxMenux",
+    "twitterDescription": "Proxmox Backup Server som mål med nyckelfilskryptering och en återställningskopia skyddad med lösenfras."
+  },
+  "header": {
+    "title": "Proxmox Backup Server",
+    "description": "PBS-målet laddar upp hela förberedelsekatalogen som en enda .pxar-säkerhetskopia till ett Proxmox Backup Server-datalager. Klientkryptering med nyckelfil är valfri, liksom uppladdning av en återställningskopia av nyckelfilen, skyddad med lösenfras, bredvid varje säkerhetskopia.",
+    "section": "Säkerhetskopiering och återställning"
+  },
+  "recommendedBadge": "Rekommenderad destination",
+  "aboutPbs": {
+    "heading": "Vad Proxmox Backup Server är",
+    "body": "Proxmox Backup Server (PBS) är Proxmox egen backup server produkt, utvecklad och underhålls av samma team som författare Proxmox VE. Det är en dedikerad säkerhetskopieringsserver utformad för att ta emot säkerhetskopior från Proxmox VE-värdar (VM, LXCs och - via <code>proxmox-backup-client</code> - godtyckliga värdkataloger) med chunk-baserad deduplicering, klient-side-kryptering och lagringspolicy tillämpad server-side. ProxMenux använder PBS som en av de tre destinationerna för värdbackups; varje PBS-specifik mekanism som beskrivs på denna sida (backupgrupper, <code>.pxar</code> arkiv, <code>--backup-id</code>, keyfile kryptering) är standard PBS beteende."
+  },
+  "intro": {
+    "title": "En säkerhetskopia per körning, deduplicering på blocknivå",
+    "body": "En PBS-säkerhetskopia skapar en enda post i datalagret under säkerhetskopierings-ID:t <code>host/hostcfg-HOSTNAME/BACKUP-TIME</code>. Innehållet är ett <code>.pxar</code>-arkiv med samma struktur i tre delar som beskrivs i <em>Så fungerar det</em>. PBS deduplicerar block mellan alla säkerhetskopior i datalagret, så senare säkerhetskopior av samma värd överför och lagrar endast ändrade block. ProxMenux tillämpar själv lagringsreglerna för schemalagda jobb: efter varje lyckad körning kör <code>run_scheduled_backup.sh</code> kommandot <code>proxmox-backup-client prune</code> med <code>--keep-last</code> / <code>--keep-daily</code> / <code>--keep-weekly</code> och jobbets inställda värden."
+  },
+  "repoSelection": {
+    "heading": "Repository urval",
+    "intro": "ProxMenux upptäcker PBS repositorier från två källor på varje backup. Operatören väljer en från en enhetlig meny; valet bestämmer <code>HB_PBS_REPOSITORY</code>, <code>HB_PBS_SECRET</code> och <code>HB_PBS_FINGERPRINT</code> för körningen.",
+    "sourceRows": [
+      {
+        "source": "Proxmox storage.cfg (identifierad automatiskt)",
+        "path": "/etc/pve/storage.cfg + /etc/pve/priv/storage/NAME.pw",
+        "content": "Varje <code>pbs:</code>-avsnitt i Proxmox egen lagringskonfiguration identifieras automatiskt. Server, datalager, användarnamn och fingeravtryck hämtas från avsnittet. Lösenordet läses från Proxmox egen katalog för inloggningsuppgifter. Uppgifterna behöver inte anges på nytt i ProxMenux; förvaret är tillgängligt så snart det har konfigurerats i Proxmox."
+      },
+      {
+        "source": "ProxMenux manuell konfig",
+        "path": "/usr/local/share/proxmenux/pbs-manual-configs.txt + pbs-pass-NAME.txt + pbs-fingerprint-NAME.txt",
+        "content": "Läggs till via <em>Konfigurera säkerhetskopieringsmål → PBS-mål → Lägg till PBS</em>. Du anger namn, användarnamn (<code>root@pam</code> eller <code>user@pbs!token</code>), värd eller IP-adress, datalager och lösenord. Om lösenordet lämnas tomt visas frågan igen; annars skulle en tom uppgift sparas utan varning och alla senare säkerhetskopior misslyckas med ett otydligt autentiseringsfel. Detta används när PBS-målet inte är registrerat som Proxmox-lagring."
+      }
+    ],
+    "menuTitle": "Urvalsmenyn",
+    "menuBody": "Båda källorna visas i en enda meny, varje rad märkt med sitt ursprung (<code>[proxmox]</code> eller <code>[manual]</code>). Anteckningar vars lösenord inte kunde lösas är taggade med en <code>⚠ no password</code>-varning - välja en utlöser ett lösenord återinträde innan backupen startar. Fingeravtrycket överförs till <code>proxmox-backup-client</code> via <code>PBS_FINGERPRINT</code>-miljövariabeln; när det saknas frågar klienten operatören att acceptera servercertifikatet interaktivt på den första säkerhetskopian."
+  },
+  "backupCommand": {
+    "heading": "Backup kommandot",
+    "intro": "Uppladdningen sker med ett enda anrop till <code>proxmox-backup-client backup</code>. ProxMenux använder <code>env</code> för att överföra lösenord, krypteringslösenord och fingeravtryck till klienten som miljövariabler.",
+    "cmd": "env \\\n    PBS_PASSWORD=\"$HB_PBS_SECRET\" \\\n    PBS_ENCRYPTION_PASSWORD=\"$HB_PBS_ENC_PASS\" \\\n    PBS_FINGERPRINT=\"$HB_PBS_FINGERPRINT\" \\\n    proxmox-backup-client backup \\\n        hostcfg.pxar:$staging_root \\\n        --repository USER@REALM@HOST:DATASTORE \\\n        --backup-type host \\\n        --backup-id  hostcfg-HOSTNAME \\\n        --backup-time BACKUP-EPOCH \\\n        [--keyfile /usr/local/share/proxmenux/pbs-key.conf]",
+    "backupIdTitle": "Namnge säkerhetskopierings-ID",
+    "backupIdBody": "Standard-ID är <code>hostcfg-HOSTNAME</code>. Operatören bekräftar eller redigerar det före uppladdning; tecken utanför <code>[A-Za-z0-9_-]</code> och avslutande bindestreck tas bort. Att återanvända samma ID är avsiktligt: PBS behandlar ID:t som en <em>grupp</em>, och varje senare säkerhetskopia blir en ny post i gruppen med gemensam deduplicering med tidigare körningar.",
+    "pxarTitle": "Varför källan är hela staging roten",
+    "pxarBody": "<code>.pxar</code>-källan är hela <code>staging_root</code> - <code>rootfs/</code>, <code>metadata/</code> och <code>manifest.json</code> tillsammans. Tidigare versioner passerade <code>$staging_root/rootfs</code> som källa; som lämnade <code>metadata/</code> ur arkivet och återställningens kompatibilitetskontroll hade ingenting att läsa, försämrade att korsa värd varningar även på samma värd återställningar. Gamla säkerhetskopior som skapats med rootfs-bara källan återställs fortfarande korrekt via <code>_rs_check_layout</code>: s fall-3 gren, som lindrar en platt <code>etc/var/root/usr</code> träd tillbaka till en <code>rootfs/</code> hierarki."
+  },
+  "encryption": {
+    "heading": "Klient-side kryptering",
+    "glossaryHint": "Avsnittet använder termerna <em>nyckelfil</em>, <em>lösenfras</em> och <em>återställningskuvert</em>. <glosarioLink>Ordlistan</glosarioLink> sammanfattar skillnaderna med en mening per term.",
+    "intro": "PBS klientkryptering med nyckelfil krypterar blocken på källvärden före uppladdning. Kryptering är valfri i ProxMenux. När den aktiveras väljer operatören uttryckligen ja eller nej till att även lagra en återställningskopia av nyckelfilen, skyddad med lösenfras, på PBS. Valet kan ändras senare i Monitor. Själva nyckelfilen finns alltid på den kanoniska sökvägen <code>/usr/local/share/proxmenux/pbs-key.conf</code> och återanvänds utan nya frågor vid varje senare krypterad säkerhetskopiering.",
+    "keyfileTitle": "Ställ in nyckelfilen",
+    "keyfileBody": "Krypteringsdialogen visas vid värdens första krypterade säkerhetskopiering. Först frågar den om säkerhetskopian ska krypteras: <em>Nej</em> fortsätter utan kryptering och <em>Ja</em> går till steg två. Det steget beror på om en nyckelfil redan finns på <code>/usr/local/share/proxmenux/pbs-key.conf</code>. I så fall återanvänds den utan frågor och säkerhetskopieringen fortsätter; inte heller senare säkerhetskopieringar frågar igen. Annars visar en meny två alternativ. <em>Skapa en ny nyckelfil</em> kör <code>proxmox-backup-client key create --kdf none</code>. <em>Använd en befintlig nyckelfil</em> identifierar automatiskt en PVE-hanterad nyckel: om det valda PBS-förvaret är registrerat i Proxmox med en krypteringsnyckel på <code>/etc/pve/priv/storage/&lt;NAME&gt;.enc</code>, kopieras filen utan frågor till ProxMenux kanoniska sökväg. Om ingen PVE-hanterad nyckel matchar förvaret efterfrågas den absoluta sökväg där operatören redan har placerat nyckelfilen på värden. I båda fallen installeras filen på den kanoniska sökvägen med <code>chmod 600</code>.",
+    "modesTitle": "En nyckelfil per värd eller en gemensam nyckelfil",
+    "modesIntro": "Båda driftsmodellerna stöds och ingen är obligatorisk. Operatören väljer utifrån hur värdarna är organiserade.",
+    "modesPerHostTitle": "En nyckelfil per värd (standard)",
+    "modesPerHostBody": "Varje värd genererar sin egen nyckelfil första gången det möjliggör PBS-kryptering. Isolering är maximal: att kompromissa med nyckelfilen hos en värd exponerar inte någon annans säkerhetskopior. Rekommenderas för produktionsflottor och för miljöer där värdar har olika ägare eller överensstämmelse gränser.",
+    "modesSharedTitle": "Gemensam nyckelfil (importeras på varje värd)",
+    "modesSharedBody": "En huvudnyckelfil skapas en gång och installeras på varje värd via alternativet <em>Använd en befintlig nyckelfil</em>. Hanteringen blir enklare: en enda hemlighet att skydda, och varje värd kan dekryptera alla andra värdars arkiv. Det är användbart för konsolidering, återställningsövningar mellan värdar och central verifiering av säkerhetskopior. Nackdelen är att en läcka av den gemensamma nyckeln exponerar alla värdar samtidigt. Rekommenderas för hemlabb och miljöer där alla värdar har samma ägare och ingår i samma tillitsområde.",
+    "recoveryTitle": "Ladda upp nyckeln till PBS – operatören bestämmer",
+    "recoveryBody": "Direkt efter valet av nyckelfil ställer ProxMenux den uttryckliga frågan <em>Ladda upp nyckeln till PBS?</em> med två svar. <strong>Ingen återställningsfil laddas upp till PBS förrän operatören svarar Ja.</strong> Standardvalet är <em>Nej, behåll endast lokalt</em>: nyckelfilen ligger kvar på den kanoniska lokala sökvägen, ProxMenux laddar inte upp någon återställningsfil till PBS och operatören ansvarar själv för kopian utanför värden. Knappen <em>Ladda ner nyckelfil</em> på PBS-målets rad i Monitor ger en kopia vid behov. Valet <em>Ja, ladda upp</em> efterfrågar en återställningslösenfras två gånger och kontrollerar att svaren matchar. ProxMenux skyddar nyckelfilen med AES-256-CBC och PBKDF2 (600 000 iterationer, slumpmässigt salt) och skapar <code>pbs-key.recovery.enc</code>. Varje senare krypterad säkerhetskopia laddar upp detta kuvert till PBS som en tillhörande säkerhetskopieringsgrupp. Dessa uppladdningar skickar varken lösenfrasen eller nyckelfilen i klartext till PBS. Valet kan ändras när som helst i Monitor: kontrollen på PBS-målets rad växlar Ja/Nej och tillämpar omedelbart Börja ladda upp, Sluta ladda upp eller Uppdatera lösenfras beroende på aktuellt tillstånd.",
+    "blobUploadTitle": "Tillhörande säkerhetskopieringsgrupp på PBS",
+    "blobUploadBody1": "När läget är <em>Ja, ladda upp</em> laddar ProxMenux upp återställningskuvertet till PBS efter varje krypterad säkerhetskopiering, som en andra tillhörande grupp. Den har samma namn som värdens grupp med suffixet <code>-keyrecovery</code>. Grupperna visas bredvid varandra i datalagrets lista: en för värdsäkerhetskopior och en för återställningskuvert. <strong>Kuvertet lämnar aldrig värden i klartext</strong>: krypteringen sker på värden med AES-256-CBC och PBKDF2 innan några data överförs (<code>openssl enc -aes-256-cbc -pbkdf2 -iter 600000 -salt</code>). PBS tar endast emot det redan krypterade kuvertet.",
+    "envelopeSecurityTitle": "Överför nyckelåterhämtningsfilen till PBS en säkerhetsrisk?",
+    "envelopeSecurityBody": "Keyrecovery-filen krypteras i transit och i vila. Återhämtningspassfrasen lämnar aldrig värden: kryptering sker lokalt före uppladdningen, och PBS ser bara det redan krypterade resultatet. En PBS-administratör - eller någon med tillgång till databutiken - kan ladda ner nyckelrecovery-filen, men utan återställningspassfrasen kan de inte läsa nyckelfilen inuti: det är ogenomskinlig chiffertext. Rekonstruera nyckelfilen kräver båda bitarna samtidigt, nyckelrecovery-filen och passfrasen, och endast operatören håller båda.",
+    "blobUploadConstraintTitle": "Varför två grupper istället för en enda krypterad",
+    "blobUploadConstraintBody": "Ett enda anrop till <code>proxmox-backup-client backup</code> krypterar antingen alla sina arkiv med samma nyckelfil eller inget av dem. Värdsäkerhetskopian måste krypteras med värdens nyckelfil, men återställningskuvertet kan inte skickas med i samma uppladdning: då skulle det krypteras med just den nyckelfil som det innehåller. På en nyinstallerad värd skulle det inte gå att öppna, eftersom nyckelfilen skulle behövas för att dekryptera sig själv. Därför laddas de två filerna upp separat och visas som två grupper. PBS-klienten krypterar värdsäkerhetskopian med nyckelfilen, medan ProxMenux krypterar kuvertet med lösenfrasen före uppladdning. Två olika krypteringslager skyddar två olika innehåll.",
+    "blobUploadImageAlt": "PBS-gränssnittet visar säkerhetskopieringsgrupperna hostcfg-HOSTNAME och hostcfg-HOSTNAME-keyrecovery bredvid varandra i datalagrets lista.",
+    "blobUploadImageCaption": "PBS-gränssnittet — de tillhörande säkerhetskopieringsgrupperna. Huvudgruppen innehåller värdsäkerhetskopiorna; gruppen -keyrecovery innehåller nyckelfilen skyddad med lösenfras.",
+    "recoverTitle": "Återhämtning på en ny värd",
+    "recoverBody": "Om nyckelfilen saknas på den kanoniska sökvägen, efter en ominstallation eller uttrycklig borttagning, provar återställningen tre källor i ordning och stannar vid den första användbara nyckeln. Först kopieras en matchande PVE-hanterad nyckel från <code>/etc/pve/priv/storage/&lt;NAME&gt;.enc</code> utan frågor till den kanoniska sökvägen, om den finns för det valda PBS-förvaret. Om det finns en <code>-keyrecovery</code>-grupp på PBS laddas sedan den senaste ögonblicksbilden ner och operatören anger återställningslösenfrasen för att dekryptera den. Om båda alternativen misslyckas eller avböjs efterfrågas till sist den absoluta sökvägen till nyckelfilen på värden, och filen kopieras till den kanoniska sökvägen. Monitor visar samma importflöde i säkerhetskopians detaljdialog. En gul panel visas överst när Återställ, Ladda ner eller Visa innehåll behöver en nyckel som saknas. Om en installerad nyckel inte matchar säkerhetskopian returnerar PBS <code>wrong key — manifest's key XX does not match provided key YY</code>. Samma tre åtgärder visar då en strukturerad panel med manifestets nödvändiga nyckelfingeravtryck tydligt utmärkt, så att operatören kan identifiera rätt nyckelfil att importera för säkerhetskopian.",
+    "monitorManagementTitle": "Hantera nyckelfilen från Monitor",
+    "monitorManagementBody": "Monitor visar nyckelfilens kontroller direkt på varje PBS-målrad i säkerhetskopieringskonfigurationen. Tre åtgärder finns: <em>Ladda ner</em> exporterar den aktuella filen till webbläsaren; <em>Ladda upp</em> ersätter den installerade filen med operatörens fil, och den gamla skrivs över först när den nya har installerats på den kanoniska sökvägen; <em>Ta bort</em> tar bort filen från värden. Bredvid finns kontrollen för återställningskopian: ett Ja/Nej-val för <em>Ladda upp nyckeln till PBS?</em>, ett lösenfrasfält när Ja väljs och en knapp som beroende på tillstånd tillämpar <em>Börja ladda upp</em>, <em>Sluta ladda upp</em> eller <em>Uppdatera lösenfras</em>. Alla åtgärder använder samma Flask-slutpunkter som terminalgränssnittet, så effekten på disk och tillståndet på PBS blir identiska från båda gränssnitten."
+  },
+  "restoreAccess": {
+    "heading": "Hämta vid återställning",
+    "body": "Återställningen hittar ProxMenux värdsäkerhetskopior på PBS genom att lista grupperna i det konfigurerade förvaret och filtrera efter ID-mönster. Fliken Säkerhetskopior i Monitor visar samma lista. När en säkerhetskopia väljs körs <code>proxmox-backup-client restore</code> med samma förvar, lösenord och fingeravtryck, samt <code>--keyfile</code> om kopian är krypterad. Arkivet <code>.pxar</code> packas upp i en förberedelsekatalog som <code>_rs_check_layout</code> lämnar vidare till den vanliga återställningen. Utanför ProxMenux kan samma kommando packa upp arkivet till valfri sökväg för att granska trädet eller återställa manuellt."
+  },
+  "references": {
+    "heading": "Referenser",
+    "intro": "Officiell Proxmox Backup Server-dokumentation för komponenterna ProxMenux är beroende av.",
+    "items": [
+      {
+        "label": "Proxmox Backup Server dokumentation",
+        "href": "https://pbs.proxmox.com/docs/",
+        "tail": " - huvudingångspunkt som täcker installation, administration, lagring, användare och roller."
+      },
+      {
+        "label": "proxmox-backup-client",
+        "href": "https://pbs.proxmox.com/docs/backup-client.html",
+        "tail": " — kommandoradsverktyget som ProxMenux använder för varje säkerhetskopiering och återställning. Beskriver säkerhetskopierings-ID, typer, arkiv, förvarssyntax och miljövariabler."
+      },
+      {
+        "label": "Kryptering på klientsidan",
+        "href": "https://pbs.proxmox.com/docs/backup-client.html#encryption",
+        "tail": " — skapa nyckelfiler, --kdf-lägen och krypteringsmodellen som ProxMenux utökar med en återställningskopia skyddad med lösenfras."
+      },
+      {
+        "label": "Datalagerhantering",
+        "href": "https://pbs.proxmox.com/docs/storage.html",
+        "tail": " - skapa och hantera datastorer som tar emot värdbackups, inklusive chunk-store layout och behörigheter."
+      },
+      {
+        "label": "Gallring och skräpinsamling",
+        "href": "https://pbs.proxmox.com/docs/maintenance.html#pruning",
+        "tail": " — lagringsreglerna bakom --keep-last / --keep-daily / --keep-weekly som ProxMenux tillämpar per schemalagt jobb, samt hur PBS frigör oanvända block efter gallring."
+      }
+    ]
+  }
+}

web/messages/sv/docs/backup-restore/glossary.json

@@ -0,0 +1,230 @@
+{
+  "meta": {
+    "title": "Ordlista - Backup & Restore | ProxMenux",
+    "description": "Termer i ProxMenux system för säkerhetskopiering och återställning: kryptering, nyckelfil, passfras, återställningskuvert, PBS, datablock, rootfs, manifest, körprocess och komplettering mellan kärnversioner.",
+    "ogTitle": "Backup & Återställ ordlista | ProxMenux",
+    "ogDescription": "Tydliga definitioner för ordförråd som används över ProxMenux backup och återställa dokumentation.",
+    "twitterTitle": "Backup & Återställ ordlista | ProxMenux",
+    "twitterDescription": "Passfras, keyfile, återhämtningskuvert, rootfs, manifest, PBS, bitar - alla definierade på ett ställe."
+  },
+  "header": {
+    "title": "Ordlista",
+    "description": "Termer i dokumentationen för säkerhetskopiering och återställning, med definitioner.",
+    "section": "Säkerhetskopiering och återställning"
+  },
+  "intro": {
+    "body": "Termer grupperas efter tema. Varje post ger termen och en kort definition."
+  },
+  "groups": [
+    {
+      "title": "Kryptering och nyckelåterställning",
+      "intro": "Vocabulary för PBS kryptering block. Det handlar om två distinkta hemligheter: en binär nyckelfil och en skriftlig passfras.",
+      "entries": [
+        {
+          "id": "passphrase-recuperacion",
+          "term": "Återställningslösenfras",
+          "def": "Text lösenord användaren väljer för att skydda <a href=\"#sobre-recuperacion\">återställningskuvertet</a>. Det uppmanas två gånger med en matchkontroll, och används endast för att kryptera kuvertet och för att dekryptera det om nyckelfilen någonsin behöver återställas. <strong>Det är inte passfrasen som låser upp nyckelfilen själv</strong>, och det skickas aldrig till PBS. Under en normal backup lämnar den aldrig värden."
+        },
+        {
+          "id": "clave-cifrado",
+          "term": "Keyfile (krypteringsnyckel)",
+          "def": "Nyckelfil som proxmox-backup-client använder för att kryptera <a href=\"#chunk\">datablock</a> före uppladdning till PBS. Utan rätt nyckel kan krypterade data inte läsas. ProxMenux sparar filen på <code>/usr/local/share/proxmenux/pbs-key.conf</code> med läge <code>600</code>. Skydda den: <a href=\"#sobre-recuperacion\">återställningskuvertet</a> finns för att återställa filen om den förloras."
+        },
+        {
+          "id": "contrasena-keyfile",
+          "term": "Keyfile passfras (KDF passfras)",
+          "def": "Valfri passfras som keyfilen själv kan bära, skiljer sig från <a href=\"#passphrase-recuperacion\">återställningspassfrasen</a>. Det finns bara när nyckelfilen skapades med <code>--kdf scrypt</code> (vanligtvis en importerad nyckelfil). Utan det kan nyckelfilen inte låsas upp för användning. ProxMenux sparar den i krypterad form på värden så att schemalagda säkerhetskopior kan köras utan en interaktiv prompt."
+        },
+        {
+          "id": "sobre-recuperacion",
+          "term": "Återhämtningskuvert",
+          "def": "<a href=\"#clave-cifrado\">Nyckelfilen</a> är insvept i ett extra lager: det är krypterat med <a href=\"#passphrase-recuperacion\">Återhämtningspassfras</a> Använda <a href=\"#aes-256-cbc\">AES-256-CBC</a> och <a href=\"#pbkdf2\">PBKDF2</a> innan den någonsin lämnar värden. Det är det som laddas upp till PBS som den <code>-keyrecovery</code> grupp. Utan passfrasen är kuvertet ogenomskinligt: ladda ner det från PBS avslöjar inte keyfile."
+        },
+        {
+          "id": "cifrado-cliente",
+          "term": "Klient-side kryptering",
+          "def": "Krypteringsmodell där data krypteras på källvärden innan de laddas upp. PBS får bara och lagrar chiffertext; inte ens en PBS-administratör med databutiksåtkomst kan läsa den utan nyckelfilen. ProxMenux bygger på denna modell och lägger till <a href=\"#sobre-recuperacion\">återställningskuvertet</a> ovanpå."
+        },
+        {
+          "id": "kdf-none",
+          "term": "--kdf none",
+          "def": "Alternativ till <code>proxmox-backup-client key create</code> som producerar en nyckelfil utan bifogad passfras. Nyckelfilen kan användas direkt utan en prompt, vilket är viktigt för schemalagda jobb som körs obevakad. Detta är vad ProxMenux använder som standard när man skapar en ny nyckelfil."
+        },
+        {
+          "id": "kdf-scrypt",
+          "term": "--kdf scrypt",
+          "def": "Alternativ till <code>proxmox-backup-client key create</code> som producerar en nyckelfil skyddad av en <a href=\"#contrasena-keyfile\">nyckelfilspassfras</a>. Varje användning av nyckelfilen kräver att låsa upp den med den passfrasen. ProxMenux accepterar denna typ av nyckelfil på import och lagrar passfrasen krypterad så schemalagda säkerhetskopior kan fortfarande köras obevakad."
+        },
+        {
+          "id": "aes-256-cbc",
+          "term": "AES-256-CBC",
+          "def": "Standard symmetrisk chiffer. ProxMenux använder den (via <code>openssl enc -aes-256-cbc</code>) för att linda <a href=\"#clave-cifrado\">nyckelfilen</a> med <a href=\"#passphrase-recuperacion\">återställningspassfrasen</a> och producera <a href=\"#sobre-recuperacion\">kuvertet</a>."
+        },
+        {
+          "id": "pbkdf2",
+          "term": "PBKDF2",
+          "def": "Kryptografisk funktion som förvandlar en mänskligt utformad passfras till en binär nyckel som är lämplig för kryptering. Det saktar ner brute-force försök genom att tillämpa många iterationer. ProxMenux använder den med 600 000 iterationer och ett slumpmässigt salt när man krypterar återhämtningskuvertet."
+        }
+      ]
+    },
+    {
+      "title": "Backup struktur",
+      "intro": "Termer som beskriver vad som lever i en säkerhetskopia, oavsett destination.",
+      "entries": [
+        {
+          "id": "rootfs",
+          "term": "rootfs / rotfilsystem",
+          "def": "Filbaserad kopia av källvärdens filsystem skapad med <code>rsync</code> enligt <a href=\"#perfil-defecto\">standardprofilen</a> och <a href=\"#rutas-personalizadas\">egna sökvägar</a>. Det är ingen hel diskavbildning: endast sökvägar med konfiguration eller tillstånd som Proxmox inte kan återskapa självt kopieras."
+        },
+        {
+          "id": "manifiesto",
+          "term": "Manifest (manifest.json)",
+          "def": "Strukturerad JSON-dokument som beskriver källvärden vid backuptid: hårdvara, lagring, kärna, ProxMenux-installerade komponenter och inventering av VM och LXC. Den produceras av sex oberoende samlare. Återställningsflödet använder det för att jämföra källa och mål."
+        },
+        {
+          "id": "staging",
+          "term": "Staging katalog",
+          "def": "Tillfällig katalog där ProxMenux monterar de tre blocken (rootfs, metadata och manifest) innan du packar dem och laddar upp till destinationen. Det tas bort automatiskt när backupen slutar, även på abort."
+        },
+        {
+          "id": "perfil-defecto",
+          "term": "Standardprofil",
+          "def": "Utvalda sökvägar som ProxMenux kopierar som standard i varje säkerhetskopia. Omfattar PVE-konfiguration, nätverk, SSH, kärna, apt, ProxMenux-verktyg och mer. Definieras i koden och beskrivs på sidan <em>Hur det fungerar</em>."
+        },
+        {
+          "id": "rutas-personalizadas",
+          "term": "Anpassade vägar",
+          "def": "Extra vägar som användaren lägger till ovanpå <a href=\"#perfil-defecto\">default profil</a>. Antingen ihållande (lagras i <code>backup-extra-paths.txt</code>) eller per-run (plockad i anpassat läge)."
+        }
+      ]
+    },
+    {
+      "title": "Destinationer och lagring",
+      "intro": "Villkor bundna till var backup landar - PBS server, lokal arkiv eller Borg repository - och hur PBS organiserar data.",
+      "entries": [
+        {
+          "id": "repositorio-pbs",
+          "term": "PBS-arkivet",
+          "def": "Kombination av Proxmox Backup Server + <a href=\"#datastore\">datastore</a> + användare som tar emot backupen. Identifierad av strängen <code>user@realm@host:datastore</code>. En enda PBS-server kan vara värd för flera förråd."
+        },
+        {
+          "id": "datastore",
+          "term": "Datalager",
+          "def": "Ett visst lagringsutrymme på en PBS-server där säkerhetskopior och deras datablock finns. Varje datalager ligger på ett filsystem på PBS-servern och har egna behörigheter och regler."
+        },
+        {
+          "id": "chunk",
+          "term": "Datablock / deduplicering av datablock",
+          "def": "PBS delar varje backup i varierande storlek bitar, identifierar varje bit av sin hash och lagrar varje bit bara en gång, även om det visas i många olika säkerhetskopior. Detta innebär successiva säkerhetskopior av samma värd - eller över liknande värdar - ta mycket lite extra utrymme."
+        },
+        {
+          "id": "fingerprint",
+          "term": "Fingeravtryck",
+          "def": "Kryptografiskt fingeravtryck av PBS-serverns TLS-certifikat. Den låter kunden verifiera att den talar till den avsedda servern utan att förlita sig på en myndighet för offentlig certifikat. ProxMenux passerar den till <code>proxmox-backup-client</code> via <code>PBS_FINGERPRINT</code> miljövariabel."
+        },
+        {
+          "id": "grupo-copia",
+          "term": "Säkerhetskopia grupp",
+          "def": "Logisk container inuti PBS under vilken successiva säkerhetskopior av samma tillgång ackumuleras. Varje ny backup delar deduplicering med tidigare i samma grupp. ProxMenux använder två grupper per värd när kryptering är aktiverad: en för värdbackupen och en med ett <code>-keyrecovery</code>-suffix för <a href=\"#sobre-recuperacion\">återställningskuvertet</a>."
+        },
+        {
+          "id": "backup-id",
+          "term": "Säkerhetskopierings-ID",
+          "def": "Namnet på <a href=\"#grupo-copia\">backup grupp</a>. ProxMenux standarder till <code>hostcfg-HOSTNAME</code> och låter användaren redigera det innan uppladdning; ostödda tecken tas bort automatiskt."
+        },
+        {
+          "id": "pxar",
+          "term": ".pxar",
+          "def": "PBS-inhemska arkivformat för kataloger. Det beter sig som en tar-arkiv optimerad för chunk deduplicering: snarare än att lagra en ogenomskinlig fil bryter PBS innehållet i återanvändbara bitar."
+        }
+      ]
+    },
+    {
+      "title": "Körning och schemaläggning",
+      "intro": "Termer i ProxMenux system för schemalagda jobb.",
+      "entries": [
+        {
+          "id": "runner",
+          "term": "Körprocess",
+          "def": "<code>run_scheduled_backup.sh</code>-skriptet som utför en schemalagd säkerhetskopia. Den läser jobbkonfigen, lanserar matchande backend (Local, PBS eller Borg), tillämpar lagring på framgång och skickar konfigurerade meddelanden."
+        },
+        {
+          "id": "trabajo-programado",
+          "term": "Schemalagt jobb",
+          "def": "Bestående konfiguration av en återkommande backup. Håller destination, referenser, kryptering, schema och lagring. Lever på <code>/var/lib/proxmenux/backup-jobs/&lt;id&gt;.env</code>."
+        },
+        {
+          "id": "modo-adjunto",
+          "term": "Anslutet läge",
+          "def": "Jobb utan egen timer. En job-end-hook i PVE <code>vzdump</code> utlöser det efter gästsäkerhetskopior när mållagringen matchar. Det valda överordnade jobbet ger lagring och inledande lagringsregler, men hooken matchar lagring, inte jobb-ID. Även en annan uppgift med samma lagring kan utlösa det. Endast Local och PBS."
+        },
+        {
+          "id": "timer-systemd",
+          "term": "systemd-timer",
+          "def": "Standard systemd-mekanism som skjuter ett kommando i en kalender. ProxMenux skapar en timer per <em>oberoende</em> schemalagt jobb; <a href=\"#modo-adjunto\">attach-mode</a> jobb använder ingen timer, de körs via PVE script-hook."
+        },
+        {
+          "id": "retencion",
+          "term": "Lagringsregler (keep-last, keep-daily…)",
+          "def": "Policy som bestämmer vilka äldre säkerhetskopior som ska hållas och vilka som ska beskäras. Definieras per jobb med parametrar som <code>keep-last</code>, <code>keep-daily</code>, <code>keep-weekly</code>, <code>keep-monthly</code>. Tillämpad av körprocessen efter varje framgångsrik backup."
+        }
+      ]
+    },
+    {
+      "title": "Återställa",
+      "intro": "Termer från återställningsflödet.",
+      "entries": [
+        {
+          "id": "restauracion-universal",
+          "term": "Universell återställning",
+          "def": "ProxMenux-återställningsflödet extraherar inte bara filsystemet: det läser manifestet för att upptäcka skillnader mellan källa och mål, reproducerar systemkonfigurationen och kör om installatörerna för ProxMenux-hanterade komponenter. Målet är att reproducera källvärden, inte bara arkivet."
+        },
+        {
+          "id": "hidratacion",
+          "term": "Komplettering mellan kärnversioner",
+          "def": "Återställ pass som sammanfogar användarens egen konfiguration från källan (IOMMU-tokens, VFIO-enhets-ID, anpassade quirks, GRUB-nycklar) ovanpå målets färska startkonfiguration, utan att kopiera källans kärnbundna filer verbatim. Kör när målkärnan är nyare än backupen."
+        },
+        {
+          "id": "cross-kernel",
+          "term": "Återställning mellan kärnversioner",
+          "def": "Återställ var målets kärna skiljer sig från (vanligtvis är nyare än) källan. Kräver <a href=\"#hidratacion\">hydration</a> pass för att undvika att dra längs filer oförenliga med målets kärna."
+        },
+        {
+          "id": "instalador-postboot",
+          "term": "Installerare efter uppstart",
+          "def": "Komponenter installerade efter den första starten av den restaurerade värden (NVIDIA drivrutiner, Coral TPU drivrutiner, AMD GPU verktyg, Intel GPU verktyg). Varje installatör körs mot målets kärna, så den restaurerade värden beror inte på att källans kärna är närvarande."
+        },
+        {
+          "id": "compatibility-check",
+          "term": "Kompatibilitetskontroll",
+          "def": "Jämförelse mellan källans manifest och målets tillstånd som ProxMenux utför i början av återställningen. Det bestämmer vilka delar som kopieras verbatim, som behöver hydrering och som återskapas av en installatör."
+        },
+        {
+          "id": "equipo-recien-instalado",
+          "term": "Färsk installation",
+          "def": "Värd bara ominstallerad från början, utan lokal <a href=\"#clave-cifrado\">nyckelfil</a>. Återställa en krypterad säkerhetskopia kräver första återställning av nyckelfilen från <a href=\"#sobre-recuperacion\">återställningskuvertet</a> lagrad på PBS, med hjälp av <a href=\"#passphrase-recuperacion\">återställningspassfrasen</a>."
+        }
+      ]
+    }
+  ],
+  "whereNext": {
+    "heading": "Nästa steg",
+    "items": [
+      {
+        "label": "Hur det fungerar",
+        "href": "/docs/backup-restore/how-it-works",
+        "tail": " — där rootfs, manifest och applikationsinventering passar in i en backup."
+      },
+      {
+        "label": "Proxmox Backup Server-mål",
+        "href": "/docs/backup-restore/destinations/pbs",
+        "tail": " - där klient-side kryptering, keyfile, återställningspassfras och kuvert dokumenteras på djupet."
+      },
+      {
+        "label": "Återställande",
+        "href": "/docs/backup-restore/restoring",
+        "tail": " — Återställande flöde och manifest användning."
+      }
+    ]
+  }
+}

web/messages/sv/docs/backup-restore/how-it-works.json

@@ -0,0 +1,205 @@
+{
+  "meta": {
+    "title": "Hur ProxMenux Backup fungerar internt - rootfs, manifest, applikationer",
+    "description": "Detaljerat innehåll i en ProxMenux-säkerhetskopia: rootfs kopierat med rsync enligt standardprofilens sökvägar, ett strukturerat manifest från sex oberoende insamlare och programinventeringen som styr automatisk ominstallation av paket och komponenter efter återställning.",
+    "ogTitle": "Hur ProxMenux Backup fungerar internt",
+    "ogDescription": "De tre nyttolasterna av en ProxMenux-backup förklarade: rootfs, manifest och applikationer.",
+    "twitterTitle": "Hur ProxMenux Backup fungerar | ProxMenux",
+    "twitterDescription": "De tre nyttolasterna av en ProxMenux-backup och hur återställningen reproducerar källvärden från dem."
+  },
+  "header": {
+    "title": "Hur det fungerar",
+    "description": "Den interna nedbrytningen av en ProxMenux-backup - filsystem, manifest och applikationsinventering - och hur återställningen förbrukar alla tre för att reproducera källvärden på ett mål som kanske inte delar samma kärna.",
+    "section": "Säkerhetskopiering och återställning"
+  },
+  "intro": {
+    "title": "Ett arkiv, tre delar",
+    "body": "Varje säkerhetskopia skapar tre tydliga delar under en gemensam förberedelsekatalog. Arkivet som laddas upp till målet (lokalt <code>.tar.zst</code>, PBS-säkerhetskopia eller Borg-arkiv) innehåller samma struktur. Återställningen använder alla tre: <strong>manifestet</strong> läses före ändringar för att upptäcka avvikelser och bestämma undantag; <strong>rootfs</strong> ger konfigurationsfiler som tillämpas direkt eller efter omstart; <strong>programinventeringen</strong> styr paketinstallation och ominstallation av komponenter efter start. Varje del kan granskas eller packas upp oberoende."
+  },
+  "layout": {
+    "heading": "Arkivlayout",
+    "intro": "Varje arkiv följer samma trädlayout oavsett destination. <code>metadata/</code> underkatalog håller de strukturerade nyttolasterna; <code>rootfs/</code> underkatalog håller filsystemet kopiera.",
+    "treeCaption": "Förberedelsekatalogen som skapas vid säkerhetskopiering. Alla mål får samma träd i sitt eget format: tar för lokala mål, PBS-block för PBS och Borg-segment för Borg.",
+    "tree": "backup-[timestamp]/\n├── manifest.json                  # structured host state\n├── metadata/\n│   ├── packages.manual.list       # apt-mark showmanual\n│   ├── run_info.env               # backup run identity + kernel version + pmxcfs method\n│   ├── paths_archived.txt         # exact list of paths that reached rootfs/\n│   └── missing_paths.txt          # paths from the profile absent on source\n└── rootfs/\n    ├── etc/                       # /etc/pve, /etc/network, /etc/systemd/network, /etc/ssh, …\n    ├── root/                      # /root (with volatile subdirs excluded)\n    ├── usr/local/                 # /usr/local/bin, /usr/local/share/proxmenux, …\n    └── var/                       # /var/lib/pve-cluster (config.db via sqlite3 .backup), /var/spool/cron/…"
+  },
+  "rootfs": {
+    "heading": "Innehållet i rootfs",
+    "intro": "Trädet <code>rootfs/</code> är en <strong>vanlig filsystemkopia</strong> som skapas med <code>rsync</code> från källvärden. Det innehåller en utvald <strong>standardprofil</strong> med sökvägar som behövs för Proxmox-återställning samt <strong>egna sökvägar</strong> som användaren lägger till i jobbet eller den interaktiva sessionen. Urvalet är avsiktligt begränsat till sökvägar som <em>innehåller konfiguration</em> eller <em>lagrar tillstånd som Proxmox inte kan återskapa själv</em>.",
+    "defaultProfileTitle": "Standardprofilen",
+    "defaultProfileBody": "Standardprofilen definieras av <code>hb_default_profile_paths</code> i <code>lib_host_backup_common.sh</code>. Den omfattar åtta fasta kategorier och vid behov ZFS-tillstånd, som tillsammans beskriver en fungerande Proxmox-värd:",
+    "categoriesTitle": "Sökvägskategorier",
+    "categoryRows": [
+      {
+        "category": "PVE-kärna",
+        "paths": "/etc/pve, /var/lib/pve-cluster, /etc/vzdump.conf",
+        "why": "Cluster filsystem innehåll och vzdump standarder. Pmxcfs databas (<code>config.db</code>) fångas som en konsekvent ögonblicksbild via <code>sqlite3 .backup</code> utan att stoppa klustret, och <code>.db-wal</code> / <code>.db-shm</code> sidovagnar är uteslutna från rsync. När <code>sqlite3</code> inte är tillgänglig, skapas i stället <code>config.db.raw-fallback</code>, som automatiskt används som databas vid återställning."
+      },
+      {
+        "category": "Värd identitet och nätverk",
+        "paths": "/etc/hostname, /etc/hosts, /etc/timezone, /etc/resolv.conf, /etc/network, /etc/systemd/network",
+        "why": "Det värden behöver för att komma upp i nätverket med samma identitet. Filerna <code>.link</code> under <code>/etc/systemd/network</code> kopplar nätverkskortens namn till deras MAC-adresser, så att namnen bevaras vid ominstallation och hårdvaruändringar."
+      },
+      {
+        "category": "Åtkomst och autentisering",
+        "paths": "/etc/ssh, /etc/sudoers, /etc/sudoers.d, /etc/pam.d, /etc/security",
+        "why": "SSH-nycklar, sudoregler och PAM-konfiguration. Att förlora dessa låser användaren ur den restaurerade värden."
+      },
+      {
+        "category": "Kärna och uppstart",
+        "paths": "/etc/default/grub, /etc/kernel, /etc/modules, /etc/modules-load.d, /etc/modprobe.d, /etc/sysctl.conf, /etc/sysctl.d, /etc/udev/rules.d, /etc/fstab, /etc/iscsi, /etc/multipath",
+        "why": "IOMMU-parametrar, svartlistor för moduler, VFIO-enhets-ID, monteringstabell och lagringskonfiguration."
+      },
+      {
+        "category": "Skal och språkinställningar",
+        "paths": "/etc/environment, /etc/bash.bashrc, /etc/inputrc, /etc/profile, /etc/profile.d, /etc/locale.gen, /etc/locale.conf",
+        "why": "Systemgemensam skalkonfiguration, miljövariabler och inställningar för generering av språkmiljöer."
+      },
+      {
+        "category": "Pakethantering och cron",
+        "paths": "/etc/apt, /etc/cron.d, /etc/cron.{daily,hourly,weekly,monthly}, /etc/cron.allow, /etc/cron.deny, /var/spool/cron/crontabs",
+        "why": "APT-källor för konsekvent paketlösning, schemalagda uppgifter som definieras av användaren."
+      },
+      {
+        "category": "ProxMenux tillstånd och verktyg",
+        "paths": "/etc/proxmenux, /etc/systemd/system, /etc/log2ram.conf, /etc/logrotate.conf, /etc/logrotate.d, /etc/lm-sensors, /etc/sensors3.conf, /etc/fail2ban, /etc/snmp, /etc/postfix, /etc/wireguard, /etc/openvpn, /etc/grafana, /etc/influxdb, /etc/prometheus, /etc/telegraf, /etc/zabbix",
+        "why": "Valfri men vanlig Proxmox verktyg. Saknade vägar noteras i <code>metadata/missing_paths.txt</code> utan att stoppa backupen."
+      },
+      {
+        "category": "ProxMenux-program och root-kontot",
+        "paths": "/usr/local/bin, /usr/local/sbin, /usr/local/share/proxmenux, /var/lib/proxmenux, /root (flyktiga subdirs exkluderade)",
+        "why": "ProxMenux-installerade binärer och per användare konfiguration under <code>/root</code>. Volatila vägar (<code>.bash_history</code>, <code>.cache/</code>, <code>tmp/</code>, <code>.local/share/Trash/</code>) utesluts från kopian. <code>/var/lib/proxmenux</code> håller de schemalagda backupjobben och värdens tillstånd som hålls av ProxMenux; återställningsstagningen, återställningskopiorna och efteråtsmarkörerna är uteslutna, eftersom de tillhör värden som kör en återställning."
+      },
+      {
+        "category": "ZFS tillstånd (villkor)",
+        "paths": "/etc/zfs",
+        "why": "Det ingår endast när källvärden kör ZFS. innehåller <code>zpool.cache</code> och <code>hostid</code>."
+      }
+    ],
+    "customTitle": "Utöka profilen med anpassade vägar",
+    "customBody": "Utöver standardprofilen erbjuder ProxMenux två sätt att inkludera ytterligare vägar i en säkerhetskopia. De komponerar utan konflikt och gäller både interaktiva säkerhetskopior och schemalagda jobb.",
+    "customExtrasTitle": "1. Persistenta extrafunktioner (per-host-fil)",
+    "customExtrasBody": "En textfil på <code>/usr/local/share/proxmenux/backup-extra-paths.txt</code> innehåller en lista över absoluta vägar som användaren har markerat som \"alltid inkluderar\" på denna värd. När en säkerhetskopia körs i <strong>Default</strong>-läge, appenderar ProxMenux dessa vägar till standardprofilen automatiskt utan att fråga. Filen redigeras från gränssnittet - ingen manuell redigering behövs - och kvarstår över omstart och uppdateringar. En absolut väg per rad; <code>#</code> kommentarer är tillåtna.",
+    "customModeTitle": "2. Anpassat läge (per körning)",
+    "customModeBody": "Att starta en säkerhetskopia i <strong>Custom</strong>-läge ersätter den automatiska tillämpningen av standardprofilen med en checklista som visar varje väg: standardprofilerade poster och de ihållande extrafunktionerna (prefixed med <code>[+]</code> och förmarkerade). Användaren markerar eller avmarkerar poster för den specifika körningen, och kan också trycka på <em>Lägg till anpassad sökväg</em> för att ange en ny väg - som sedan kvarstår till extrafilen för framtida säkerhetskopior.",
+    "customMissingTitle": "Vägar frånvarande från källan",
+    "customMissingBody": "Varje väg från profilen (standard eller tillägg) som inte finns på källvärden registreras i <code>metadata/missing_paths.txt</code> inuti arkivet. Säkerhetskopieringen misslyckas varken eller slutar - användaren ser en sammanfattning av arkiverade vägar och saknade vägar i slutet. I praktiken sker detta för valfria verktygsvägar som <code>/etc/wireguard</code> eller <code>/etc/prometheus</code> när dessa verktyg inte är installerade."
+  },
+  "manifest": {
+    "heading": "Manifestdelen",
+    "intro": "<code>manifest.json</code> är ett strukturerat JSON-dokument som beskriver källvärden vid backupen. Den produceras av <strong>sex oberoende insamlare</strong> orkestrerad av <code>build_manifest.sh</code>. Varje samlare läser endast data, producerar ett väldefinierat JSON-fragment och faller tillbaka till ett säkert tomt standard om det misslyckas - manifestet är fortfarande användbart om ett avsnitt är ofullständigt.",
+    "orchestratorCaption": "De sex samlarna komponerar manifestet. Varje samlare körs i sin egen underprocess; ett misslyckande i en faller tillbaka till en dokumenterad säker standard och varnar men inte avbryter backupen.",
+    "collectorRows": [
+      {
+        "collector": "collect_source_host.sh",
+        "produces": "source_host",
+        "content": "Hostname, PVE version (<code>pveversion</code>), PBS version om värden kör backup-server roll, kärna (<code>uname -r</code>), startläge (efi/bios), root filsystem typ, CPU modell + arkitektur, minne i KB."
+      },
+      {
+        "collector": "collect_hardware.sh",
+        "produces": "hardware_inventory",
+        "content": "GPU (med leverantör och ProxMenux installer mapping), TPUs (Coral USB + M.2 med <code>lsusb</code> / <code>lspci</code> detektering), NICs (med MAC, PCI slot och bro medlemskap), trådlösa enheter. GPU-poster bär en <code>passthrough_eligible</code>-heuristisk."
+      },
+      {
+        "collector": "collect_storage.sh",
+        "produces": "storage_inventory",
+        "content": "ZFS-pooler (med pooltyp + medlemsdisker löste <code>/dev/disk/by-id/*</code>, <code>/dev/disk/by-partuuid/*</code> eller rå <code>/dev/sdX</code>-vägar beroende på hur varje pool ursprungligen skapades), LVM-volymgrupper + tunna pooler, fysiska diskar med SMART-kapacitet, PVE <code>storage.cfg</code>-poster, externa monteringar."
+      },
+      {
+        "collector": "collect_kernel.sh",
+        "produces": "kernel_params",
+        "content": "Parametrar som operatören lagt till i <code>/proc/cmdline</code>, utan standardposter som <code>BOOT_IMAGE=</code>, <code>root=</code>, <code>ro/rw</code>, <code>quiet</code> och <code>splash</code>; moduler som laddas vid start från <code>/etc/modules</code>; sökvägar till <code>/etc/modprobe.d/*.conf</code>-filer med faktiska direktiv (<code>options</code>, <code>blacklist</code>, <code>install</code>, <code>alias</code>, <code>softdep</code>)."
+      },
+      {
+        "collector": "collect_proxmenux_state.sh",
+        "produces": "proxmenux_installed_components",
+        "content": "Läser <code>/usr/local/share/proxmenux/managed_installs.json</code> (registret över allt ProxMenux har installerat) och <code>installed_tools.json</code>. Varje post håller installationsbanan (<code>menu_script</code>) så att återställningen kan utlösa exakt samma installationsflöde."
+      },
+      {
+        "collector": "collect_guests.sh",
+        "produces": "vms_lxcs_at_backup",
+        "content": "Uppräknar VMs (<code>qm list</code>) och LXCs (<code>pct list</code>) närvarande vid backuptid - VMID, namn, aktuell status. Endast inventeringen: de faktiska gästdata är <code>vzdump</code>/PBS."
+      }
+    ],
+    "schemaTitle": "Schema validering",
+    "schemaBody": "manifestet validerar mot <code>scripts/backup_restore/schema/manifest.schema.json</code>. Kör <code>build_manifest.sh --validate</code> utlöser en Python-side JSON Schema validering (kräver <code>python3</code> + <code>jsonschema</code>). Om modulen inte är närvarande, är kontrollen hoppad tyst - validering är i första hand ett utvecklarhjälp, inte ett drifttidsberoende."
+  },
+  "applications": {
+    "heading": "Applikationsinventeringen",
+    "intro": "Två inventeringar listar programvara utöver Proxmox VE:s baspaket: paketlistan under <code>metadata/</code> och komponentregistret i rootfs, som beskrivs nedan. Återställningen använder APT eller ProxMenux egna installationsprogram för att återskapa användarens programvara enligt det ursprungliga installationssättet.",
+    "packagesTitle": "packages.manual.list",
+    "packagesBody": "En alfabetisk textlista från <code>apt-mark showmanual</code> med alla APT-paket som <em>uttryckligen installerats</em> på källvärden. Beroenden till Proxmox VE:s bassystem ingår inte; målets APT installerar dem automatiskt. Under återställningen läser <code>_rs_run_complete_extras</code> listan och använder ett <em>filter mot borttagning i kaskad</em> i tre steg: <code>dpkg -s</code> hittar redan installerade paket, andra huvudversioner av bibliotek identifieras och <code>apt-get install --simulate</code> kontrollerar risken för följdborttagningar. Återstående paket installeras med <code>apt-get install -y</code>.",
+    "componentsTitle": "components_status.json (del av rootfs)",
+    "componentsBody": "En JSON registret under <code>/usr/local/share/proxmenux/</code> som registrerar varje komponent ProxMenux har installerat med sitt exakta tillstånd: version, ProxMenux-specifika flaggor (för NVIDIA: <code>patched</code> boolean; för Coral: DKMS version). Denna fil lever i rootfs - inte i <code>metadata/</code> - eftersom det är <em>läses efter</em> att rootfs har kopierats till målet. Post-boot dispatcher (<code>apply_cluster_postboot.sh</code>) itererar över sina poster och kör varje komponent <code>--auto-reinstall</code> krok, som läser det inspelade tillståndet och reproducerar installationen mot målets nuvarande kärna.",
+    "componentInstallersTitle": "Installationsprogram för komponenter",
+    "componentInstallersBody": "Fyra ProxMenux installatörer exponerar för närvarande en <code>--auto-reinstall</code> ingångspunkt:",
+    "installerRows": [
+      {
+        "component": "nvidia_driver",
+        "installer": "gpu_tpu/nvidia_installer.sh",
+        "action": "Läser <code>version</code> + <code>patched</code>. Ladda ner exakt samma NVIDIA runfil, bygger DKMS-moduler mot målets kärna, applicerar ProxMenux-patchen om källan hade den."
+      },
+      {
+        "component": "coral_driver",
+        "installer": "gpu_tpu/install_coral.sh",
+        "action": "Läser versionen av Coral-drivrutinen och kompilerar DKMS-modulen för målets kärna."
+      },
+      {
+        "component": "amdgpu_top",
+        "installer": "gpu_tpu/amd_gpu_tools.sh",
+        "action": "Läser den inspelade versionen. Laddar ner exakt <code>.deb</code> från GitHub release."
+      },
+      {
+        "component": "intel_gpu_tools",
+        "installer": "gpu_tpu/intel_gpu_tools.sh",
+        "action": "APT-installerar paketet. Idempotent om det redan finns från <code>packages.manual.list</code>."
+      }
+    ]
+  },
+  "restoreFlow": {
+    "heading": "Hur återställningen förbrukar de tre nyttolasterna",
+    "intro": "Återställningen är en sexstegs pipeline. Varje steg läser en specifik delmängd av arkivet och uppdaterar målvärden. Inget stadium kräver att källvärden kan nås - arkivet är helt fristående.",
+    "stagesCaption": "Steg 1 använder manifestet för att bestämma vad du ska röra. Steg 2 kopierar rootfs vägar som är säkra att tillämpa på ett körsystem. Stadium 3 iscensätter de riskfyllda vägarna för nästa start. Steg 3b importerar icke-rot ZFS datapooler vars diskar är alla närvarande. Steg 4 hanterar paket. Stage 5 körs efter omstart och ominstallerar komponenter mot målets kärna.",
+    "stageRows": [
+      {
+        "stage": "1",
+        "name": "Kompatibilitetskontroll",
+        "reads": "manifest.json",
+        "action": "Kör <code>hb_compat_check</code>. Jämför källa vs mål hårdvara (NIC, lagrings-ID), PVE-version och stor kärnversion. Set <code>HB_COMPAT_KERNEL_DIRECTION</code> (<code>same</code>, <code>bk_newer</code> eller <code>bk_older</code>) och befolkar <code>RS_SKIP_PATHS</code> med hårdvara-drift och cross-kernel uteslutningar."
+      },
+      {
+        "stage": "2",
+        "name": "Tillämpning under drift",
+        "reads": "rootfs/ (endast säkra vägar)",
+        "action": "<code>_rs_apply … hot</code> kopierar <code>hb_classify_path</code>=<code>hot</code>-poster direkt till live-målet. Allt under <code>/etc/pve</code>, <code>/etc/network</code> eller vägar som klassificeras som <em>reboot</em>/<em>dangerous</em> uppskjuts."
+      },
+      {
+        "stage": "3",
+        "name": "Förbered uppskjutna ändringar",
+        "reads": "rootfs/ (omstart + farliga vägar)",
+        "action": "<code>_rs_prepare_pending_restore</code> förbereder riskfyllda sökvägar under <code>/var/lib/proxmenux/pending-restore/</code>, skriver <code>plan.env</code>, <code>apply-on-boot.list</code> och <code>rs-skip-paths.txt</code> och aktiverar <code>proxmenux-restore-onboot.service</code> för nästa start."
+      },
+      {
+        "stage": "3b",
+        "name": "Datapool import",
+        "reads": "manifest.storage_inventory + mål ZFS tillstånd",
+        "action": "<code>_rs_import_data_pools</code> försöker importera varje ZFS-pool utan rotfilsystem vars samtliga diskar finns på målet. Pooler med ett annat hostid provas igen med <code>zpool import -f</code>. Om någon disk saknas hoppas poolen över med en varning. Resultatet per pool loggas i <code>/var/log/proxmenux/restore-datapools-&lt;timestamp&gt;.log</code>."
+      },
+      {
+        "stage": "4",
+        "name": "Paketinstallation",
+        "reads": "metadata/packages.manual.list",
+        "action": "<code>_rs_run_complete_extras</code> kör kaskadsäkert filter och kallar <code>apt-get install -y</code> med den överlevande paketlistan. Fullständig utdata går till <code>/var/log/proxmenux/restore-apt-*.log</code>."
+      },
+      {
+        "stage": "5",
+        "name": "Efter uppstart",
+        "reads": "rootfs (redan tillämpat) + components_status.json",
+        "action": "Efter omstart, <code>apply_pending_restore.sh</code> spelar tillbaka de uppskjutna banorna och <code>apply_cluster_postboot.sh</code> kör <code>update-initramfs</code>, <code>update-grub</code> (eller <code>proxmox-boot-tool refresh</code>) och itererar över <code>components_status.json</code> skjuter varje komponent <code>--auto-reinstall</code> krok."
+      }
+    ]
+  },
+  "whyItWorks": {
+    "heading": "Varför säkerhetskopian delas i tre delar",
+    "body": "Uppdelningen följer uppgifternas <strong>livscykel</strong>. Filsystemet överförs med <code>rsync</code>: snabbt, öppet och atomärt per fil. Konfigurationstillstånd som måste tolkas före ändringar lagras som <strong>strukturerad JSON</strong>, läsbar för sig, versionshanterbar med schema och maskinellt jämförbar med målets tillstånd. Programvara som ska installeras om beskrivs i en <strong>inventering</strong> med namn och versioner; målets pakethanterare och ProxMenux installationsprogram väljer rätt binärer. Varje del fyller sin egen uppgift. Tillsammans eftersträvar de en sammanhängande återställning med feltolerans: ett skadat manifest lämnar rootfs återställbart, ett saknat paket hindrar inte komponentinstallation och ett fel för en post stoppar inte nästa."
+  }
+}

web/messages/sv/docs/backup-restore/index.json

@@ -0,0 +1,93 @@
+{
+  "meta": {
+    "title": "ProxMenux Säkerhetskopiering och återställning — Översikt | Fullständig säkerhetskopiering och återställning av värd för Proxmox VE",
+    "description": "ProxMenux Backup & Restore fångar det fullständiga tillståndet för en Proxmox-värd – filsystem, strukturerat konfigurationsmanifest och installerade paket/komponenter – och återskapar det på samma eller en annan värd. Säkerhetskopieringen och återställningen är fristående: inga externa beroenden, och återställningar över kärnor stöds genom ett riktningsmedvetet filter för säker delmängd och kärnagnostisk hydrering.",
+    "ogTitle": "ProxMenux Säkerhetskopiering och återställning — Översikt",
+    "ogDescription": "Fullständig säkerhetskopiering och återställning av värd för Proxmox VE med strukturerat manifest, paketlista och ominstallerare av komponenter.",
+    "twitterTitle": "ProxMenux Säkerhetskopiering och återställning | ProxMenux",
+    "twitterDescription": "Fullständig säkerhetskopiering och återställning av värd för Proxmox VE med strukturerat manifest, paketlista och ominstallerare av komponenter."
+  },
+  "header": {
+    "title": "Säkerhetskopiering och återställning",
+    "description": "Säkerhetskopiering av hela värden och återställning för Proxmox VE. Fångar filsystem, konfiguration och installerade komponenter i ett enda arkiv och återskapar värden på samma eller en annan Proxmox-installation utan externa beroenden.",
+    "section": "Säkerhetskopiering och återställning"
+  },
+  "intro": {
+    "title": "Vad det är, i ett stycke",
+    "body": "En ProxMenux-säkerhetskopia sparar hela tillståndet för en Proxmox-värd: <strong>filsystemet</strong>, med relevanta kataloger under <code>/etc</code>, <code>/root</code> och <code>/var/lib/pve-cluster</code> samt valfria egna sökvägar; <strong>ett strukturerat manifest</strong> i JSON med upptäckt maskinvara, kärnparametrar, nätverkskonfiguration, ZFS-status, användare och cron-poster; och <strong>en programinventering</strong> med paket som APT markerar som manuellt installerade samt komponenter som ProxMenux installerat, med exakta versioner. Alla tre mål som stöds – lokalt arkiv, Proxmox Backup Server (rekommenderas) och Borg – får samma fristående innehåll. Vart och ett kan användas för att återskapa målvärden utan att källvärden behöver vara nåbar under återställningen."
+  },
+  "video": {
+    "heading": "Videogenomgång",
+    "intro": "Föredrar du att titta på Backup & Restore i aktion innan du konfigurerar det? Den här genomgången täcker en fullständig demo av funktionen i ProxMenux.",
+    "title": "ProxMenux – genomgång för säkerhetskopiering och återställning",
+    "caption": "Extern video på YouTube. Spelas upp i integritetsförbättrat läge (inga cookies förrän du trycker på play)."
+  },
+  "whatItIsNot": {
+    "heading": "Vad det inte är",
+    "intro": "Det här avsnittet gäller säkerhetskopiering och återställning <strong>av värden</strong>: själva Proxmox-installationen, inte de program och gästsystem som körs på den.",
+    "items": [
+      "<strong>Det här är inget verktyg för säkerhetskopiering av VM:ar eller CT:er.</strong> Funktionen sparar varken gästernas diskar eller RAM-tillstånd; det sköts av <code>vzdump</code>. Gästernas <strong>konfigurationsfiler</strong> (<code>/etc/pve/nodes/&lt;node&gt;/qemu-server/*.conf</code> och <code>lxc/*.conf</code>) <strong>ingår däremot</strong>. Efter återställning visas inventeringen igen, och diskarna kan återställas eller anslutas från en befintlig PBS- eller lokal säkerhetskopia.",
+      "<strong>Det här är ingen åtgärd för hela klustret.</strong> Varje nod säkerhetskopierar sig själv. Klustertillhörigheten sparas i <code>/etc/pve</code> så att en återställd nod kan anslutas igen, men återställning av hela klustret kräver samordning mellan noderna.",
+      "<strong>Det här är ingen fullständig diskavbildning.</strong> Kärnans binärfiler, initramfs och startpartitionen ingår inte. Vid återställning använder ProxMenux målvärdens egna startfiler, som återskapas automatiskt av <code>update-initramfs</code> och starthanterarens verktyg, och installerar drivrutiner som passar målets körande kärna."
+    ]
+  },
+  "threePillars": {
+    "heading": "De tre pelarna i en säkerhetskopia",
+    "intro": "Ett ProxMenux arkiv är uppbyggt kring tre fristående nyttolaster. Återställningen använder alla tre tillsammans för att reproducera källvärden på ett mål som kanske inte ens har samma kärna installerad.",
+    "diagramCaption": "Varje säkerhetskopia innehåller samma tre datablock oavsett destination. Återställningen använder alla tre: rootfs för att återställa filerna, manifestet för att upptäcka avvikelser och skillnader mellan kärnversioner samt programinventeringen för att installera om paket och komponenter för målets egen kärna.",
+    "pillar1Label": "Filsystem",
+    "pillar1Detail": "rootfs/\n(rsync av /etc,\n/etc/systemd/network,\n/root, samt en\nsqlite3-ögonblicksbild\nav /var/lib/pve-cluster,\n+ valfria sökvägar)",
+    "pillar2Label": "Manifest",
+    "pillar2Detail": "manifest.json\n(maskinvara, kärn-\nparametrar, nätverk,\nZFS, användare, cron,\nZFS-pooler, lagring)",
+    "pillar3Label": "Applikationer",
+    "pillar3Detail": "packages.manual.list\n+ components_status.json\n(manuella APT-paket + ProxMenux-\ninstallationsprogram med versioner)"
+  },
+  "restoreIsUniversal": {
+    "heading": "Återställningen återger källvärden, inte arkivet",
+    "body": "En återställning av en ProxMenux-säkerhetskopia packar inte bara upp filsystemet. Återställningen läser manifestet för att upptäcka avvikelser mellan källa och mål (maskinvaruskillnader, namnbyten på nätverkskort, kärnversion och ZFS-poolens identitet), återställer filsystemet och startar sedan rätt komponentinstallerare för varje tjänst som fanns på källan (NVIDIA-drivrutin, Coral TPU samt GPU-verktyg för AMD och Intel). Varje installerare körs för <strong>målets aktuella kärna</strong>, så den återställda värden är inte beroende av att källans kärna finns kvar. När målets kärna är nyare än säkerhetskopians sammanfogar en kärnoberoende <strong>hydrering</strong> användarens egna inställningar (IOMMU-token, VFIO-enhets-ID:n, särskilda anpassningar och GRUB-nycklar) med målets nya startkonfiguration utan att kopiera kärnbundna filer ordagrant."
+  },
+  "twoInterfaces": {
+    "heading": "Två gränssnitt, en backend",
+    "intro": "Varje steg i arbetsflödet för säkerhetskopiering och återställning är tillgängligt från två ingångspunkter. Båda anropar samma skalbibliotek, producerar identiska arkiv och läser samma jobbregister.",
+    "cliLabel": "ProxMenux Scripts (TUI)",
+    "cliDetail": "meny → Verktyg →\nVärdsäkerhetskopiering/återställning\n\nDialogbaserat flöde,\nSSH-vänlig, skriptbar\nför obevakad användning.",
+    "webLabel": "ProxMenux Monitor (Webb UI)",
+    "webDetail": "Backups-fliken i\nMonitors webbgränssnitt.\n\nÅterställning med ett klick,\nlöpande loggvisning, integrerat\nmed aviseringar och visning\nav skillnader vid återställning."
+  },
+  "whereNext": {
+    "heading": "Vart ska man gå härifrån",
+    "intro": "Varje underavsnitt nedan täcker en aspekt av arbetsflödet på djupet. Börja med <em>Hur det fungerar</em> om målet är att förstå vad arkivet innehåller och varför. Hoppa till <em>Destinationer</em> för att konfigurera målet för kopian. Läs <em>Återställning</em> och <em>Återställning mellan kärnversioner</em> för återställningssidan.",
+    "items": [
+      {
+        "label": "Så fungerar det",
+        "href": "/docs/backup-restore/how-it-works",
+        "tail": "— de tre nyttolasterna (rootfs, manifest, applikationer) i detalj, med de samlare som producerar dem och formatet för varje fil."
+      },
+      {
+        "label": "Destinationer",
+        "href": "/docs/backup-restore/destinations",
+        "tail": "— jämförelse av lokal, Proxmox Backup Server (rekommenderas) och Borg, och hur man konfigurerar var och en."
+      },
+      {
+        "label": "Skapa säkerhetskopior",
+        "href": "/docs/backup-restore/creating-backups",
+        "tail": "— engångssäkerhetskopior, standardsökvägsprofilen, lägga till anpassade sökvägar, kryptering för PBS."
+      },
+      {
+        "label": "Schemalagda jobb",
+        "href": "/docs/backup-restore/scheduled-jobs",
+        "tail": "— nya jobb kontra att koppla till ett befintligt PVE vzdump-jobb, schemaläggningsformat, jobbdetaljmodal."
+      },
+      {
+        "label": "Återställning",
+        "href": "/docs/backup-restore/restoring",
+        "tail": "— de tre åtgärderna i ett arkiv (visa, ladda ner, återställ), Komplett vs. anpassad återställning, post-boot-dispatcher och varför de sista tio minuterna är viktiga."
+      },
+      {
+        "label": "Återställning mellan kärnversioner",
+        "href": "/docs/backup-restore/cross-kernel",
+        "tail": " — beteende som tar hänsyn till riktningen på versionsbytet när målets kärna skiljer sig från säkerhetskopians, filtret för en säker delmängd och de fyra hydreringsfaserna."
+      }
+    ]
+  }
+}

web/messages/sv/docs/backup-restore/scheduled-jobs.json

@@ -0,0 +1,152 @@
+{
+  "meta": {
+    "title": "Schemalagda jobb — timers, kopplingsläge, bevarande | ProxMenux",
+    "description": "Schemalagda ProxMenux-jobb för säkerhetskopiering av värden. Två sätt att skapa jobb (egen systemd-timer eller koppling till ett befintligt PVE vzdump-jobb), bevaranderegler per jobb via proxmox-backup-client, Borg eller lokal rensning, filer under /var/lib/proxmenux/backup-jobs och körningsskriptet som skapar samma arkiv som det interaktiva flödet.",
+    "ogTitle": "ProxMenux Backup - schemalagda jobb",
+    "ogDescription": "Obevakade schemalagda värdsäkerhetskopior med kopplingsläge, bevaranderegler och samma tre destinationer som det interaktiva flödet.",
+    "twitterTitle": "Planerade jobb | ProxMenux",
+    "twitterDescription": "Obevakade schemalagda värdsäkerhetskopieringsjobb med kopplingsläge och bevaranderegler."
+  },
+  "header": {
+    "title": "Planerade jobb",
+    "description": "Obevakade jobb för säkerhetskopiering av värden. Två modeller: ett nytt oberoende jobb med eget schema eller ett jobb kopplat till ett befintligt PVE vzdump-jobb som ärver dess schema och bevaranderegler. Båda skapar samma arkiv som det interaktiva flödet.",
+    "section": "Säkerhetskopiering och återställning"
+  },
+  "intro": {
+    "title": "De två modellerna för schemalagda jobb",
+    "body": "Ett schemalagt jobb kan skapas efter en av två modeller:",
+    "modelsList": [
+      "<strong>Nytt oberoende jobb</strong> - ProxMenux definierar själva arbetsschemat med sin egen systemd timer, oberoende av någon annan uppgift på värden. Kompatibel med alla tre destinationer: Lokal, PBS och Borg.",
+      "<strong>Koppla till ett befintligt PVE vzdump-jobb</strong> — jobbet har inget eget schema; det körs automatiskt när det överordnade vzdump-jobbet säkerhetskopierar värdens VM:ar och LXC:er. Det ärver schemat och bevarandereglerna. Stöder lokalt mål och PBS (Borg stöds inte eftersom PVE saknar en inbyggd schemaläggare för Borg)."
+    ]
+  },
+  "attachBadge": {
+    "title": "Kopplingsläge — rekommenderas när ett PVE vzdump-jobb redan finns",
+    "body": "Om ett PVE vzdump-jobb redan är konfigurerat för nodens VM:ar och LXC:er körs den kopplade värdsäkerhetskopieringen efter gästernas säkerhetskopiering, i <strong>samma säkerhetskopieringscykel</strong>. Vid återställning kommer gästkonfigurationerna från värdsäkerhetskopian (under <code>/etc/pve</code>) och gästdiskarna från cykelns vzdump-kopior. Detta underlättar samordnad återställning av hela noden men är ingen atomär ögonblicksbild: ändringar under cykeln kan ge skillnader mellan värdkonfiguration och gästernas disktillstånd."
+  },
+  "frequencyBadge": {
+    "title": "Rekommenderad frekvens",
+    "body": "Säkerhetskopiera värden ofta för att maximera kompatibiliteten med en framtida återställning. Ju närmare säkerhetskopian ligger värdens aktuella tillstånd, desto färre avvikelser i konfiguration, paket och komponenter måste återställningen hantera."
+  },
+  "modes": {
+    "heading": "De två lägena",
+    "rows": [
+      {
+        "mode": "Nytt schemalagt jobb",
+        "backends": "Lokalt, PBS, Borg",
+        "schedule": "Egen <code>OnCalendar</code> uttryck (systemd kalendersyntax - t.ex. <code>daily</code>, <code>Mon..Fri 03:00</code>).",
+        "retention": "Efterfrågas separat: <code>keep-last</code>, <code>keep-hourly</code>, <code>keep-daily</code>, <code>keep-weekly</code>, <code>keep-monthly</code>, <code>keep-yearly</code>. Tillämpad av körningsskriptet efter varje framgångsrik backup."
+      },
+      {
+        "mode": "Bifoga till ett PVE vzdump jobb",
+        "backends": "Lokal, PBS (Borg har ingen PVE-sida schemaläggning)",
+        "schedule": "Ärvd från föräldern PVE jobb. Ingen systemd-timer installeras på ProxMenux-sidan.",
+        "retention": "Ärvd från förälderns <code>prune-backups</code>-konfiguration (mappade en-till-en till körningsskriptets <code>KEEP_*</code>-variabler via <code>hb_pve_prune_to_keep_env</code>)."
+      }
+    ]
+  },
+  "attachDetail": {
+    "heading": "Så fungerar kopplingsläget",
+    "intro": "PVE skriver <code>vzdump</code>-jobb till <code>/etc/pve/jobs.cfg</code>, med ett avsnitt per jobb som anger lagringen för VM- och LXC-kopiorna. Kopplingsläget kräver en backend som ProxMenux stöder (lokalt eller PBS). Värdsäkerhetskopieringen körs via job-end-hooken efter att gästernas säkerhetskopieringsjobb avslutats.",
+    "steps": [
+      {
+        "step": "1",
+        "detail": "Under jobbskapande listar ProxMenux kompatibla förälder PVE-uppgifter via <code>hb_pve_list_vzdump_jobs_for_backend</code>. Användaren väljer en."
+      },
+      {
+        "step": "2",
+        "detail": "Jobbets <code>.env</code> är skrivet med <code>PVE_PARENT_JOB</code>, <code>PVE_STORAGE</code> och de ärvda <code>KEEP_*</code> värdena; ingen systemd timer skapas."
+      },
+      {
+        "step": "3",
+        "detail": "<code>hb_install_vzdump_hook</code> registrerar en skripthook i <code>/etc/vzdump.conf</code>. I job-end-fasen för varje vzdump-jobb jämförs mottaget <code>$STOREID</code> med <code>PVE_STORAGE</code> för varje aktiverat kopplat jobb, och körningsskriptet startas för matchande jobb. Matchningen görs efter lagring, inte efter det valda överordnade jobbets ID."
+      },
+      {
+        "step": "4",
+        "detail": "Arkivet sparas i samma lagring som vzdump-kopiorna: <code>path/dump/</code> för lokalt mål eller PBS-arkivlagret som konfigurerats i PVE-lagringsposten."
+      }
+    ],
+    "outroBody": "Kopplingsläget har ingen egen timer. Om det valda överordnade PVE-jobbet inaktiveras eller tas bort stoppas dess utlösning, men ett annat vzdump-jobb med samma lagring kan fortfarande starta värdsäkerhetskopieringen. Inaktivera eller ta bort själva ProxMenux-jobbet för att förhindra det. Vid inaktivering ligger jobbposten kvar och kan senare aktiveras eller kopplas igen."
+  },
+  "storageLayout": {
+    "heading": "Filer som utgör ett jobb",
+    "intro": "Varje schemalagt jobb beskrivs fullständigt av tre eller fyra filer på disken. Att läsa dem ger hela konfigurationen av jobbet utan att förlita sig på gränssnittet.",
+    "rows": [
+      {
+        "path": "/var/lib/proxmenux/backup-jobs/JOB_ID.env",
+        "content": "Backend, backup-ID eller destination, schema (nyt läge) eller PVE-förälder (Attach-läge), aktiverad flagga, lagring <code>KEEP_*</code>-värden, referenspekare."
+      },
+      {
+        "path": "/var/lib/proxmenux/backup-jobs/JOB_ID.paths",
+        "content": "En absolut sökväg per rad — valet från profilen fastställs när jobbet skapas. Om filen redigeras används det nya valet nästa gång timern löser ut."
+      },
+      {
+        "path": "/etc/systemd/system/proxmenux-backup-JOB_ID.timer + .service",
+        "content": "Nytt läge bara. Tjänsten anropar <code>run_scheduled_backup.sh JOB_ID</code>. Timern schemalägger det med <code>Persistent=true</code> (missade körningar utförs vid nästa start) och en liten <code>RandomizedDelaySec=120</code> att sprida belastning när flera jobb delar samma OnCalendar uttryck."
+      },
+      {
+        "path": "/etc/vzdump.conf script-hook",
+        "content": "Fäst läge bara. Installerad en gång av <code>hb_install_vzdump_hook</code>; matchar varje bifogat jobb <code>PVE_STORAGE</code> mot <code>$STOREID</code> PVE passerar till krokskriptet."
+      }
+    ]
+  },
+  "runner": {
+    "heading": "Vad ett jobb gör när det startar",
+    "intro": "Varje jobb – oavsett om det är nymodell eller bifogad – kör samma trestegssekvens:",
+    "steps": [
+      "<strong>Förbered säkerhetskopian.</strong> Läser jobbkonfigurationen (destination, profil, vägar) och monterar arkivträdet exakt på samma sätt som det interaktiva flödet gör. Resultatet är samma arkiv som en manuell säkerhetskopia med dessa inställningar skulle producera.",
+      "<strong>Skriv till destinationen.</strong> Laddar eller skriver arkivet till den konfigurerade destinationen - en lokal <code>.tar.zst</code> fil, en PBS backup, eller ett Borg-arkiv - med exakt samma verktyg och referenser en manuell säkerhetskopia till samma destination skulle använda.",
+      "<strong>Tillämpa bevaranderegler.</strong> Ta bort gamla säkerhetskopior från destinationen, hålla <code>keep-last</code> / <code>keep-daily</code> / <code>keep-weekly</code> räknas konfigurerade på jobbet. Pruning utförs av själva destinationen: PBS tillämpar sina egna bevaranderegler, Borg kör <code>borg prune</code>, och för Local ProxMenux raderar filerna som faller utanför <code>keep-last</code>-fönstret."
+    ]
+  },
+  "management": {
+    "heading": "Hantera jobb",
+    "intro": "Schemaläggarmenyn (Scripts TUI) och fliken Monitor Backups avslöjar samma åtgärder på något jobb.",
+    "rows": [
+      {
+        "action": "Kör nu",
+        "detail": "Anropar körningsskriptet omedelbart utan att vänta på timern eller vzdump-hooken. Användbart för att verifiera konfigurationen utan att vänta till nästa schemalagda körning."
+      },
+      {
+        "action": "Aktivera / Inaktivera",
+        "detail": "Nytt läge: <code>systemctl enable/disable --now</code> timern. Bifoga läge: vänder <code>ENABLED</code> flaggan i jobbenv - krokskriptet respekterar den vid nästa PVE-körning."
+      },
+      {
+        "action": "Redigera",
+        "detail": "Öppnar åter dialogerna för destination, schema, profil och bevarande och skriver om jobbfilerna. Jobb-ID:t behålls."
+      },
+      {
+        "action": "Ta bort",
+        "detail": "Tar bort jobbets env-fil, sökvägsfilen och systemd-timern med tjänsten (nytt läge) samt inaktiverar hookkopplingen (kopplingsläge). Arkiv som redan finns på destinationen påverkas inte."
+      },
+      {
+        "action": "Visa logg",
+        "detail": "Strömmar <code>/var/log/proxmenux/backup-jobs/JOB_ID-YYYYMMDD_HHMMSS.log</code> — en loggfil per körning. Körningsskriptet sänder också ut en kompakt statusrad till journald under tjänsten systemd."
+      }
+    ]
+  },
+  "notifications": {
+    "heading": "Aviseringar",
+    "body": "Varje schemalagd körning utlöser samma <code>hb_notify_lifecycle</code> händelser som det interaktiva flödet (<code>start</code>, <code>complete</code>, <code>fail</code>). Om meddelandekanaler är konfigurerade i Monitor, obevakade jobb visar sina resultat på samma sätt manuella säkerhetskopior gör - en användare behöver inte kontrollera loggen för att veta om ett jobb lyckades."
+  },
+  "whereNext": {
+    "heading": "Nästa steg",
+    "items": [
+      {
+        "label": "Skapa backups",
+        "href": "/docs/backup-restore/creating-backups",
+        "tail": " - det interaktiva flödet som delar backend med schemaläggaren."
+      },
+      {
+        "label": "Destinationer",
+        "href": "/docs/backup-restore/destinations",
+        "tail": " — per-backend konfiguration som används av både det interaktiva flödet och schemaläggaren."
+      },
+      {
+        "label": "Återställande",
+        "href": "/docs/backup-restore/restoring",
+        "tail": " — flödet som använder de säkerhetskopior som jobben skapar."
+      }
+    ]
+  }
+}