mirror of
https://github.com/MacRimi/ProxMenux.git
synced 2026-11-02 19:02:31 +00:00
Bring the web documentation in line with develop in every language
- English pages describe backups, the manifest, ROCm GPUs, OCI host directories and storage as develop does, and say user instead of operator - New paragraph on host directories mounted with everything the host has mounted inside them, and a new update rule for host directories - The Proxmox Backup Server section of the post-install page is translated into every language - Spanish and the other six languages follow the updated English
This commit is contained in:
MacRimi
@@ -76,7 +76,7 @@
|
||||
},
|
||||
"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."
|
||||
"body": "Var säkerhetskopian än lagras innehåller den alltid samma tre block som beskrivs i <em>Så fungerar det</em>: filsystemet (<code>rootfs/</code>), metadata (<code>metadata/</code>) och manifestet (<code>manifest.json</code>). Att packa upp ett lokalt <code>.tar.zst</code>-arkiv, återställa ett <code>.pxar</code>-arkiv från PBS eller packa upp ett Borg-arkiv ger alltid samma katalogträd. Återställningen läser därför alltid samma filer, oavsett vilken destination säkerhetskopian kommer från."
|
||||
},
|
||||
"extractStandalone": {
|
||||
"heading": "Extrahera en backup utanför ProxMenux",
|
||||
|
||||
@@ -23,7 +23,7 @@
|
||||
},
|
||||
"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.",
|
||||
"intro": "ProxMenux hittar PBS-repositorier från två källor vid varje säkerhetskopiering. Användaren väljer ett från en enhetlig meny; för den körningen avgör valet vilken server och vilket datalager säkerhetskopian skickas till, vilket lösenord den autentiserar sig med och vilket <em>fingeravtryck</em> som validerar certifikatet.",
|
||||
"sourceRows": [
|
||||
{
|
||||
"source": "Proxmox storage.cfg (identifierad automatiskt)",
|
||||
@@ -46,7 +46,7 @@
|
||||
"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."
|
||||
"pxarBody": "<code>.pxar</code>-arkivet packar hela arbetskatalogen: värdens filsystem (<code>rootfs/</code>), metadata (<code>metadata/</code>) och manifestet (<code>manifest.json</code>). Vid återställning jämför ProxMenux manifestet med målvärden för att avgöra om de är likvärdiga, om hårdvaran har ändrats eller om det är en annan maskin, och anpassar processen därefter. Äldre säkerhetskopior, gjorda av tidigare ProxMenux-versioner som bara packade filsystemet, återställs fortfarande korrekt: återställningen upptäcker det äldre formatet och ordnar om det automatiskt."
|
||||
},
|
||||
"encryption": {
|
||||
"heading": "Klient-side kryptering",
|
||||
@@ -63,7 +63,7 @@
|
||||
"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.",
|
||||
"blobUploadBody1": "När svaret är <em>Ja, ladda upp</em> laddar ProxMenux upp återställningskuvertet till PBS efter varje krypterad säkerhetskopiering, som en andra, tillhörande säkerhetskopieringsgrupp. Den har samma namn som värdens grupp men slutar på <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 själv med AES-256-CBC och PBKDF2 innan några byte ö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",
|
||||
@@ -73,7 +73,7 @@
|
||||
"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/<NAME>.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."
|
||||
"monitorManagementBody": "Monitor visar nyckelfilens kontroller på varje PBS-målrad på sidan för säkerhetskopieringskonfiguration. Raden har tre åtgärder: <em>Ladda ner</em> exporterar den aktuella nyckelfilen till användarens webbläsare, <em>Ladda upp</em> ersätter den installerade nyckelfilen med en som användaren tillhandahåller (den tidigare filen skrivs över först när den nya har kommit fram korrekt till sin sökväg) och <em>Ta bort</em> tar bort nyckelfilen från värden. Direkt bredvid finns reglaget för återställningskuvertet: ett Ja/Nej-val för <em>Ladda upp nyckeln till PBS?</em>, ett lösenfrasfält som visas när Ja väljs och en knapp som följer det aktuella tillståndet: <em>Börja ladda upp</em>, <em>Sluta ladda upp</em> eller <em>Uppdatera lösenfras</em>. Kontrollerna i Monitor och dialogrutan i skalet gör samma sak i grunden, så resultatet på disken och på PBS blir identiskt oavsett vilket som används."
|
||||
},
|
||||
"restoreAccess": {
|
||||
"heading": "Hämta vid återställning",
|
||||
|
||||
@@ -121,7 +121,7 @@
|
||||
}
|
||||
],
|
||||
"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."
|
||||
"schemaBody": "ProxMenux levereras med en mall som beskriver vilka fält manifestet måste innehålla och hur vart och ett ska se ut. När en säkerhetskopia skapas kan manifestet kontrolleras automatiskt mot mallen, så att en insamlare som har gett felformaterad JSON eller ett felstavat fält upptäcks direkt. Kontrollen är avsedd för utvecklingen av ProxMenux självt: på ett system där den inte är installerad fungerar säkerhetskopieringen som vanligt och manifestet skapas ändå."
|
||||
},
|
||||
"applications": {
|
||||
"heading": "Applikationsinventeringen",
|
||||
|
||||
@@ -127,7 +127,7 @@
|
||||
},
|
||||
"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."
|
||||
"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 aviseringskanaler är konfigurerade i Monitor visar obevakade jobb sina resultat på samma sätt som manuella säkerhetskopior – en användare behöver inte kontrollera loggen för att veta om ett jobb lyckades."
|
||||
},
|
||||
"whereNext": {
|
||||
"heading": "Nästa steg",
|
||||
|
||||
@@ -105,7 +105,7 @@
|
||||
[
|
||||
"AMD ROCm",
|
||||
"Rendernoden, <code>/dev/kfd</code> och generationen som beräkningsdrivrutinen rapporterar i <code>/sys/class/kfd/kfd/topology/nodes/*/properties</code>",
|
||||
"En generation som programmets ROCm-avbildning innehåller beräkningskärnor för — de namngivna RDNA2-GPU:erna och nyare — erbjuds utan anpassning. Andra GPU:er i dessa familjer, till exempel Radeon 680M och 780M, erbjuds som experimentella och väljs aldrig som föreslaget alternativ: ROCm stöder dem inte officiellt, programmet presenterar dem som familjens generation (<code>HSA_OVERRIDE_GFX_VERSION</code>) och installeraren begär bekräftelse innan den större avbildningen hämtas. Äldre GPU:er, till exempel den integrerade grafiken i Ryzen 5000U, erbjuds inte och Immich fortsätter köra igenkänningen på CPU:n."
|
||||
"En GPU av en generation som programmets ROCm-avbildning stöder (de RDNA2-GPU:er den nämner och nyare) erbjuds som den är. Andra GPU:er i dessa familjer, till exempel Radeon 680M och 780M, erbjuds som experimentella och är aldrig det föreslagna alternativet. ROCm stöder dem inte officiellt: programmet presenterar dem som familjens generation (<code>HSA_OVERRIDE_GFX_VERSION</code>) och installeraren begär bekräftelse innan den större avbildningen hämtas. En äldre GPU, till exempel den integrerade grafiken i en Ryzen 5000U, erbjuds inte och Immich fortsätter köra igenkänningen på CPU:n"
|
||||
],
|
||||
[
|
||||
"NVIDIA",
|
||||
|
||||
@@ -104,6 +104,7 @@
|
||||
"Den nya avbildningen verifieras lager för lager innan CT:n stoppas. En skadad nedladdning hämtas en andra gång; en redan cachad avbildning som inte klarar kontrollen laddas ned igen.",
|
||||
"Inställningar som ändrats i Proxmox VE efter installationen (minne, swap, kärnor, CPU-gräns, CPU-prioritet och start med noden) bevaras och förs över till det nya kontraktet.",
|
||||
"LAN-gränssnittet som Arr-sviten och multi-container-applikationerna lägger till (<code>net1</code>) och startordern (<code>startup</code>) ges tillbaka till den nya containern som de är.",
|
||||
"En katalog på värden känns igen på sin sökväg och på filsystemet den ligger på, inte på det enhetsnamn som värden ger dess disk, så en USB- eller nätverksdisk som kommer tillbaka under ett annat namn är fortfarande samma katalog. När dess disk inte är ansluten stoppar uppdateringen innan CT stoppas och anger vilken katalog som saknas.",
|
||||
"Alla andra skillnader mellan CT och dess kontrakt stoppar uppdateringen innan CT stoppas."
|
||||
]
|
||||
}
|
||||
|
||||
@@ -38,7 +38,7 @@
|
||||
},
|
||||
{
|
||||
"title": "Lagring och storlek",
|
||||
"body": "En containerdisk skapas på en Proxmox VE-lagring med den angivna storleken. Standardinstallationen använder <code>local-lvm</code>. Den avancerade installationen frågar efter lagring för varje sökväg strax före storleken och föreslår lagringen för rootfs. Disken visas som <code>vm-VMID-disk-N</code> och ansluts som <code>mpN</code>."
|
||||
"body": "En containerdisk skapas på en Proxmox VE-lagring med den angivna storleken. Standardinstallationen frågar en gång efter lagringen för containern och dess data när noden har mer än en; den avancerade installationen frågar efter lagring för varje sökväg strax före storleken och föreslår lagringen för rootfs. Disken visas som <code>vm-VMID-disk-N</code> och ansluts som <code>mpN</code>."
|
||||
},
|
||||
{
|
||||
"title": "Katalog på värden",
|
||||
@@ -109,6 +109,9 @@
|
||||
},
|
||||
{
|
||||
"p": "Rootfs är reserverat för binärfilerna och avbildningens innehåll. En uppdatering eller ett återskapande ersätter det utan att röra någon av de två typerna av monteringspunkt."
|
||||
},
|
||||
{
|
||||
"p": "En katalog på värden monteras med allt som värden har monterat i den. En katalog som <code>/mnt/pve</code> visar sina nätverksresurser, diskar och dataset i containern, och det som värden senare monterar eller avmonterar där dyker upp eller försvinner utan att containern startas om. En katalog som lagts till som skrivskyddad är skrivskyddad tillsammans med det som är monterat i den när containern startar. Ett filsystem som värden monterar efteråt kommer med de behörigheter som värden monterar det med, och blir också skrivskyddat när containern startas om."
|
||||
}
|
||||
]
|
||||
},
|
||||
|
||||
@@ -78,6 +78,17 @@
|
||||
"heading": "Gemenskapens skript",
|
||||
"body": "Menyn erbjuder också två tredjepartsskript från projektet <a>community-scripts</a>: <em>Proxmox VE Post Install</em> och <em>Proxmox VE Microcode</em>. Startskripten laddar ned och kör originalförfattarnas skript via <code>wget | bash</code>. De underhålls inte av ProxMenux. Se <link>Externa paketförråd</link> för detaljer och frågor om tillit innan du kör dem."
|
||||
},
|
||||
"pbs": {
|
||||
"heading": "På Proxmox Backup Server",
|
||||
"body": "På en Proxmox Backup Server-värd öppnas samma meny från <strong>Inställningar efter installation av Proxmox</strong> i PBS-menyn. Automatiserat, Anpassningsbart, Tillämpa tillgängliga uppdateringar och Avinstallera optimeringar fungerar som på Proxmox VE, med dessa skillnader:",
|
||||
"items": [
|
||||
"<strong>Paketkällor och uppgradering:</strong> när servern saknar prenumeration och bara Enterprise-källan för PBS är aktiv frågar ProxMenux innan den byter till PBS-källan utan prenumeration. Bytet görs via serverns egen API för paketkällor, samma som används i <em>Administration > Repositories</em>. Med en aktiv prenumeration, eller med en källa utan prenumeration eller en testkälla redan konfigurerad, lämnas källorna som de är.",
|
||||
"<strong>Anpassningsbar lista:</strong> alternativ som bara gäller Proxmox VE visas inte: gästagent, VFIO IOMMU, Open vSwitch, hastighet för vzdump-backuper, pigz, Appliance Manager, Ceph, hög tillgänglighet och OVH Real Time Monitoring.",
|
||||
"<strong>Prenumerationsbanner:</strong> patchen gäller webbgränssnittet för Proxmox Backup Server, och Avinstallera optimeringar återställer det.",
|
||||
"<strong>Figurine:</strong> installeras utan Proxmox VE-aliasen.",
|
||||
"<strong>Communityskript:</strong> avsnittet erbjuder <em>Proxmox Backup Server Post Install</em> och <em>Proxmox Backup Server Microcode</em> i stället för Proxmox VE-skripten."
|
||||
]
|
||||
},
|
||||
"related": {
|
||||
"heading": "Relaterat",
|
||||
"items": [
|
||||
|
||||
Reference in New Issue
Block a user