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

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

@@ -23,7 +23,7 @@
   },
   "repoSelection": {
     "heading": "Selecção do repositório",
-    "intro": "ProxMenux descobre repositórios PBS de duas fontes em cada backup. O operador escolhe um de um menu unificado; a escolha determina <code>HB_PBS_REPOSITORY</code>, <code>HB_PBS_SECRET</code> e <code>HB_PBS_FINGERPRINT</code> para a execução.",
+    "intro": "O ProxMenux descobre repositórios PBS a partir de duas fontes em cada backup. O utilizador escolhe um num menu unificado; para essa execução, a escolha determina o servidor e o datastore para onde o backup é enviado, a palavra-passe com que se autentica e a <em>impressão digital</em> que valida o certificado.",
     "sourceRows": [
       {
         "source": "storage.cfg do Proxmox (deteção automática)",
@@ -46,7 +46,7 @@
     "backupIdTitle": "Nome do ID de backup",
     "backupIdBody": "O ID de backup padrão é <code>hostcfg-HOSTNAME</code>. Pede-se ao operador que o confirme ou edite antes do envio; quaisquer caracteres fora do <code>[A-Za-z0-9_-]</code> são despojados e os traços são aparados. Reutilizar o mesmo ID entre as execuções é intencional — o PBS trata o ID como um <em>group</em>, e cada backup subsequente aparece como um novo backup dentro desse grupo, compartilhando dedup com execuções anteriores.",
     "pxarTitle": "Por que a fonte é a raiz de estadiamento completa",
-    "pxarBody": "A origem do arquivo <code>.pxar</code> é todo o <code>staging_root</code>: <code>rootfs/</code>, <code>metadata/</code> e <code>manifest.json</code> em conjunto. Versões anteriores usavam <code>$staging_root/rootfs</code> como origem, deixando <code>metadata/</code> fora do arquivo. Sem esses dados, a verificação de compatibilidade emitia avisos de mudança de host mesmo ao restaurar no mesmo host. As cópias antigas continuam a ser restauradas pelo caso 3 de <code>_rs_check_layout</code>, que volta a colocar a árvore simples <code>etc/var/root/usr</code> dentro de uma hierarquia <code>rootfs/</code>."
+    "pxarBody": "O arquivo <code>.pxar</code> empacota todo o diretório de trabalho: o sistema de ficheiros do host (<code>rootfs/</code>), os metadados (<code>metadata/</code>) e o manifesto (<code>manifest.json</code>). No restauro, o ProxMenux compara o manifesto com o host de destino para determinar se são equivalentes, se o hardware mudou ou se se trata de uma máquina diferente, e ajusta o processo em conformidade. Os backups mais antigos, criados por versões anteriores do ProxMenux que empacotavam apenas o sistema de ficheiros, continuam a ser restaurados corretamente: o restauro deteta esse formato antigo e reorganiza-o automaticamente."
   },
   "encryption": {
     "heading": "Criptografia do lado do cliente",
@@ -63,7 +63,7 @@
     "recoveryTitle": "Chave de envio para PBS — o operador decide",
     "recoveryBody": "Logo após escolher o arquivo de chave, o ProxMenux pergunta explicitamente <em>Enviar a chave para o PBS?</em>, com duas respostas. <strong>Nenhum artefato de recuperação é enviado ao PBS até o operador responder Sim.</strong> O padrão é <em>Não, manter apenas localmente</em>: a chave fica no caminho canônico local, o ProxMenux não envia artefatos de recuperação ao PBS e o operador cuida da cópia externa. O botão <em>Baixar arquivo de chave</em> do Monitor, na linha do destino PBS, fornece essa cópia quando necessário. Ao escolher <em>Sim, enviar</em>, é solicitada duas vezes uma frase secreta de recuperação, verificando se as duas entradas coincidem. O ProxMenux protege o arquivo com AES-256-CBC e PBKDF2 (600.000 iterações, salt aleatório), produzindo <code>pbs-key.recovery.enc</code>. Cada backup criptografado posterior envia esse envelope ao PBS como um grupo de backup associado. Esses envios não transmitem ao PBS a frase secreta nem o arquivo de chave em texto claro. A escolha pode ser alterada a qualquer momento no Monitor: o controle na linha PBS permite Sim ou Não e aplica imediatamente Iniciar envio, Parar envio ou Atualizar frase secreta, conforme o estado atual.",
     "blobUploadTitle": "Grupo de backup emparelhado no PBS",
-    "blobUploadBody1": "Quando o modo de garantia é <em>Sim, fazer upload</em>, ProxMenux carrega o envelope de recuperação para PBS após cada backup criptografado como um segundo grupo de backup emparelhado com o mesmo nome do grupo host, mas terminando em <code>-keyrecovery</code>. Os dois grupos ficam próximos um do outro na listagem do armazenamento de dados – um para backups de host e outro para envelopes de recuperação. <strong>O envelope nunca sai do host em texto simples</strong>: a criptografia acontece no próprio host com AES-256-CBC e PBKDF2 antes que qualquer byte seja transmitido (<code>openssl enc -aes-256-cbc -pbkdf2 -iter 600000 -salt</code>). PBS recebe apenas o envelope já criptografado.",
+    "blobUploadBody1": "Quando a resposta é <em>Sim, fazer upload</em>, o ProxMenux carrega o envelope de recuperação para o PBS após cada backup encriptado, como um segundo grupo de backup emparelhado, com o mesmo nome do grupo do host mas terminado em <code>-keyrecovery</code>. Os dois grupos ficam lado a lado na listagem do datastore: um para os backups do host e outro para os envelopes de recuperação. <strong>O envelope nunca sai do host em texto simples</strong>: a encriptação é feita no próprio host com AES-256-CBC e PBKDF2 antes de qualquer byte ser transmitido (<code>openssl enc -aes-256-cbc -pbkdf2 -iter 600000 -salt</code>). O PBS recebe apenas o envelope já encriptado.",
     "envelopeSecurityTitle": "Carregar o arquivo de recuperação de chaves para PBS é um risco de segurança?",
     "envelopeSecurityBody": "O arquivo de recuperação de chaves está criptografado em trânsito e em repouso. A senha de recuperação nunca deixa o host: criptografia acontece localmente antes do upload, e PBS só vê o resultado já criptografado. Um administrador PBS — ou qualquer pessoa com acesso ao datastore — pode baixar o arquivo keyrecovery, mas sem a frase-passe de recuperação eles não podem ler o arquivo de chave dentro: é cifrar opaco. Reconstruir o arquivo de chaves requer ambas as peças ao mesmo tempo, o arquivo de recuperação de chaves e a frase-passe, e apenas o operador detém ambas.",
     "blobUploadConstraintTitle": "Por que dois grupos em vez de um único criptografado",
@@ -73,7 +73,7 @@
     "recoverTitle": "Recuperação num novo hospedeiro",
     "recoverBody": "Quando o arquivo de chave falta no caminho canônico, após reinstalar o host ou removê-lo explicitamente, a restauração tenta três fontes em ordem e para na primeira que fornece uma chave utilizável. Primeiro, se houver uma chave gerenciada pelo PVE correspondente ao repositório PBS selecionado em <code>/etc/pve/priv/storage/&lt;NAME&gt;.enc</code>, ela será copiada sem perguntas para o caminho canônico. Segundo, se houver um grupo <code>-keyrecovery</code> no PBS, será baixado o instantâneo mais recente e solicitada a frase secreta de recuperação para descriptografá-lo. Terceiro, se as opções anteriores falharem ou forem recusadas, o diálogo pedirá o caminho absoluto do arquivo de chave neste host e o copiará para o caminho canônico. O Monitor oferece o mesmo fluxo de importação na janela de detalhes do backup. Um painel âmbar aparece no topo quando Restaurar, Baixar ou Ver conteúdo exige uma chave ausente. Se a chave instalada não corresponde à usada no backup, o PBS retorna <code>wrong key — manifest's key XX does not match provided key YY</code>. As mesmas três ações exibem então um painel estruturado com a impressão digital exigida pelo manifesto em destaque, permitindo identificar qual chave importar para abrir o backup.",
     "monitorManagementTitle": "Gerenciando o arquivo de chaves do Monitor",
-    "monitorManagementBody": "O Monitor mostra os controles do arquivo de chave diretamente em cada linha de destino PBS na configuração dos backups. Há três ações: <em>Baixar</em> exporta o arquivo atual para o navegador; <em>Enviar</em> substitui o arquivo instalado pelo fornecido pelo operador, sobrescrevendo o anterior somente após a instalação bem-sucedida do novo no caminho canônico; <em>Excluir</em> remove o arquivo do host. Ao lado fica o controle da cópia de recuperação: uma opção Sim/Não para <em>Enviar a chave para o PBS?</em>, um campo de frase secreta quando Sim é escolhido e um botão contextual para aplicar <em>Iniciar envio</em>, <em>Parar envio</em> ou <em>Atualizar frase secreta</em>. Todas as ações usam os mesmos endpoints Flask da interface de terminal; portanto, o efeito em disco e o estado no PBS são idênticos nas duas interfaces."
+    "monitorManagementBody": "O Monitor mostra os controlos do ficheiro de chave em cada linha de destino PBS da página de configuração dos backups. A linha tem três ações: <em>Baixar</em> exporta o ficheiro de chave atual para o navegador do utilizador, <em>Enviar</em> substitui o ficheiro de chave instalado por um fornecido pelo utilizador (o ficheiro anterior só é sobrescrito depois de o novo ter chegado corretamente ao seu caminho) e <em>Excluir</em> remove o ficheiro de chave do host. Mesmo ao lado fica o interruptor do envelope de recuperação: uma opção Sim/Não para <em>Enviar a chave para o PBS?</em>, um campo de frase secreta que aparece quando Sim é selecionado e um botão que acompanha o estado atual: <em>Iniciar envio</em>, <em>Parar envio</em> ou <em>Atualizar frase secreta</em>. Os controlos do Monitor e o diálogo da shell fazem o mesmo internamente, pelo que o resultado no disco e no PBS é idêntico, seja qual for o utilizado."
   },
   "restoreAccess": {
     "heading": "Obtenção no lado da restauração",