mirror of
https://github.com/MacRimi/ProxMenux.git
synced 2026-11-02 10:52:22 +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
@@ -118,7 +118,7 @@
|
||||
{
|
||||
"step": "5",
|
||||
"name": "Notificação (início)",
|
||||
"detail": "<code>hb_notify_lifecycle \"start\"</code> é acionado. Se as notificações estiverem configuradas no Monitor, um evento <em>Backup do host iniciado</em> é enviado ao usuário. Nada é enviado se não houver canais configurados."
|
||||
"detail": "<code>hb_notify_lifecycle \"start\"</code> é acionado. Se as notificações estiverem configuradas no Monitor, é enviado ao utilizador um evento <em>Backup do host iniciado</em>. Nada é enviado se não houver canais configurados."
|
||||
}
|
||||
]
|
||||
},
|
||||
|
||||
@@ -76,7 +76,7 @@
|
||||
},
|
||||
"sameArchive": {
|
||||
"heading": "A disposição do arquivo não muda com o destino",
|
||||
"body": "Dentro de qualquer um dos três destinos, o mesmo <code>rootfs/</code> + <code>metadata/</code> + <code>manifest.json</code> layout descrito em <em>Como funciona</em> está presente. Um <code>.tar.zst</code> extraído de um arquivo local, um <code>.pxar</code> restaurado de PBS, e um arquivo Borg extraído com <code>borg extract</code> todos produzem uma árvore de diretórios idêntica. O caminho do código de restauração (<code>_rs_check_layout</code>, <code>_rs_apply</code>, <code>_rs_prepare_pending_restore</code>) lê as mesmas três cargas úteis sem saber de que destino vieram."
|
||||
"body": "Onde quer que o backup esteja guardado, contém sempre os mesmos três blocos descritos em <em>Como funciona</em>: o sistema de ficheiros (<code>rootfs/</code>), os metadados (<code>metadata/</code>) e o manifesto (<code>manifest.json</code>). Extrair um arquivo local <code>.tar.zst</code>, restaurar um <code>.pxar</code> a partir do PBS ou extrair um arquivo Borg produzem sempre uma árvore de diretórios idêntica. Por isso, o restauro lê sempre os mesmos ficheiros, seja qual for o destino de onde vem o backup."
|
||||
},
|
||||
"extractStandalone": {
|
||||
"heading": "Extraindo um backup fora de ProxMenux",
|
||||
|
||||
@@ -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/<NAME>.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",
|
||||
|
||||
@@ -121,7 +121,7 @@
|
||||
}
|
||||
],
|
||||
"schemaTitle": "Validação do esquema",
|
||||
"schemaBody": "O manifesto valida contra <code>scripts/backup_restore/schema/manifest.schema.json</code>. Executar o <code>build_manifest.sh --validate</code> desencadeia uma validação do esquema JSON do lado Python (exige o <code>python3</code> + <code>jsonschema</code>). Se o módulo não estiver presente, a verificação é ignorada silenciosamente — a validação é principalmente um auxílio ao desenvolvedor, não uma dependência de execução."
|
||||
"schemaBody": "O ProxMenux inclui um modelo que descreve os campos que o manifesto deve conter e o formato de cada um. Quando é gerado um backup, o manifesto pode ser verificado automaticamente face a esse modelo, pelo que um coletor que tenha produzido JSON malformado ou um campo mal escrito é detetado de imediato. A verificação destina-se ao desenvolvimento do próprio ProxMenux: num sistema que não a tenha instalada, o backup funciona normalmente e o manifesto é gerado na mesma."
|
||||
},
|
||||
"applications": {
|
||||
"heading": "O inventário de aplicativos",
|
||||
|
||||
@@ -127,7 +127,7 @@
|
||||
},
|
||||
"notifications": {
|
||||
"heading": "Notificações",
|
||||
"body": "Cada execução programada dispara os mesmos eventos <code>hb_notify_lifecycle</code> que o fluxo interativo (<code>start</code>, <code>complete</code>, <code>fail</code>). Se os canais de notificação estiverem configurados no Monitor, os trabalhos não vigiados mostram seus resultados da mesma forma que backups manuais – um usuário não precisa verificar o log para saber se um trabalho foi bem sucedido."
|
||||
"body": "Cada execução agendada dispara os mesmos eventos <code>hb_notify_lifecycle</code> que o fluxo interativo (<code>start</code>, <code>complete</code>, <code>fail</code>). Se houver canais de notificação configurados no Monitor, as tarefas não vigiadas comunicam os seus resultados da mesma forma que os backups manuais: um utilizador não precisa de consultar o registo para saber se uma tarefa foi bem-sucedida."
|
||||
},
|
||||
"whereNext": {
|
||||
"heading": "Para onde ir a seguir",
|
||||
|
||||
@@ -105,7 +105,7 @@
|
||||
[
|
||||
"AMD ROCm",
|
||||
"O nó de renderização, <code>/dev/kfd</code> e a geração que o controlador de computação relata em <code>/sys/class/kfd/kfd/topology/nodes/*/properties</code>",
|
||||
"Uma geração para a qual a imagem ROCm do aplicativo inclui kernels de computação — as GPUs RDNA2 citadas e as mais recentes — é oferecida sem adaptação. As outras GPUs dessas famílias, como Radeon 680M e 780M, são oferecidas como experimentais e nunca são a opção sugerida: o ROCm não as suporta oficialmente, o aplicativo as apresenta como a geração de sua família (<code>HSA_OVERRIDE_GFX_VERSION</code>) e o instalador pede confirmação antes de baixar a imagem maior. Uma GPU mais antiga, como a integrada de um Ryzen 5000U, não é oferecida e o Immich mantém o reconhecimento na CPU."
|
||||
"Uma GPU de uma geração suportada pela imagem ROCm da aplicação (as GPUs RDNA2 que indica e as mais recentes) é oferecida sem alterações. As outras GPUs dessas famílias, como as Radeon 680M e 780M, são oferecidas como experimentais e nunca são a opção proposta. O ROCm não as suporta oficialmente: a aplicação apresenta-as como a geração da sua família (<code>HSA_OVERRIDE_GFX_VERSION</code>) e o instalador pede confirmação antes de transferir a imagem maior. Uma GPU mais antiga, como a gráfica integrada de um Ryzen 5000U, não é oferecida e o Immich mantém o reconhecimento na CPU"
|
||||
],
|
||||
[
|
||||
"NVIDIA",
|
||||
|
||||
@@ -104,6 +104,7 @@
|
||||
"A nova imagem é verificada camada a camada antes de parar o CT. Uma transferência que chega danificada é repetida uma segunda vez; uma imagem já em cache que não passa na verificação é transferida novamente.",
|
||||
"As definições alteradas no Proxmox VE após a instalação (memória, swap, núcleos, limite e prioridade da CPU, arranque com o nó) são mantidas e incluídas no novo contrato.",
|
||||
"A interface LAN adicionada pela suite Arr e pelas aplicações com vários contentores (<code>net1</code>) e a ordem de arranque (<code>startup</code>) são repostas sem alterações no novo contentor.",
|
||||
"Um diretório do host é reconhecido pelo seu caminho e pelo sistema de ficheiros em que se encontra, e não pelo nome de dispositivo que o host atribui ao seu disco, pelo que um disco USB ou de rede que volte com outro nome continua a ser o mesmo diretório. Quando o seu disco não está ligado, a atualização é interrompida antes de parar o CT e indica o diretório em falta.",
|
||||
"Qualquer outra diferença entre o CT e o seu contrato interrompe a atualização antes de parar o CT."
|
||||
]
|
||||
}
|
||||
|
||||
@@ -38,7 +38,7 @@
|
||||
},
|
||||
{
|
||||
"title": "Armazenamento e tamanho",
|
||||
"body": "É criado um disco do contentor num armazenamento do Proxmox VE com o tamanho indicado. A instalação predefinida utiliza <code>local-lvm</code>; a avançada pergunta o armazenamento de cada caminho imediatamente antes do tamanho e propõe o do rootfs. O disco aparece como <code>vm-VMID-disk-N</code> e é associado como <code>mpN</code>."
|
||||
"body": "É criado um disco do contentor num armazenamento do Proxmox VE com o tamanho indicado. A instalação predefinida pergunta uma única vez o armazenamento do contentor e dos seus dados quando o nó tem mais do que um; a avançada pergunta o armazenamento de cada caminho imediatamente antes do tamanho e propõe o do rootfs. O disco aparece como <code>vm-VMID-disk-N</code> e é associado como <code>mpN</code>."
|
||||
},
|
||||
{
|
||||
"title": "Diretório do host",
|
||||
@@ -109,6 +109,9 @@
|
||||
},
|
||||
{
|
||||
"p": "O rootfs fica reservado para os binários e o conteúdo da imagem. Uma atualização ou recriação substitui-o sem tocar em nenhum dos dois tipos de ponto de montagem."
|
||||
},
|
||||
{
|
||||
"p": "Um diretório do host é montado com tudo o que o host montou dentro dele. Um diretório como <code>/mnt/pve</code> mostra no contentor as suas partilhas de rede, discos e datasets, e o que o host lá montar ou desmontar mais tarde aparece ou desaparece sem reiniciar o contentor. Um diretório adicionado só de leitura fica só de leitura juntamente com o que estiver montado dentro dele quando o contentor arranca. Um sistema de ficheiros que o host monte depois chega com as permissões com que o host o monta e passa também a só de leitura quando o contentor é reiniciado."
|
||||
}
|
||||
]
|
||||
},
|
||||
|
||||
@@ -78,6 +78,17 @@
|
||||
"heading": "Scripts da comunidade",
|
||||
"body": "O menu também oferece dois scripts de terceiros do projeto <a>community-scripts</a>: <em>Proxmox VE Post Install</em> e <em>Proxmox VE Microcode</em>. São invólucros que transferem e executam os scripts originais através de <code>wget | bash</code>. Não são mantidos pelo ProxMenux. Consulte <link>Repositórios externos</link> para detalhes e questões de confiança antes de os executar."
|
||||
},
|
||||
"pbs": {
|
||||
"heading": "No Proxmox Backup Server",
|
||||
"body": "Num host Proxmox Backup Server, o mesmo menu abre-se a partir de <strong>Configurações pós-instalação do Proxmox</strong> no menu do PBS. Automatizado, Personalizável, Aplicar atualizações disponíveis e Desinstalar otimizações funcionam como no Proxmox VE, com estas diferenças:",
|
||||
"items": [
|
||||
"<strong>Repositórios e atualização:</strong> quando o servidor não tem subscrição e apenas o repositório Enterprise do PBS está ativo, o ProxMenux pergunta antes de mudar para o repositório sem subscrição do PBS. A mudança é feita através da API de repositórios do próprio servidor, a mesma usada em <em>Administration > Repositories</em>. Com uma subscrição ativa, ou com um repositório sem subscrição ou de teste já configurado, as fontes mantêm-se como estão.",
|
||||
"<strong>Lista personalizável:</strong> as opções que só se aplicam ao Proxmox VE não são mostradas: agente convidado, VFIO IOMMU, Open vSwitch, velocidade dos backups vzdump, pigz, Appliance Manager, Ceph, alta disponibilidade e OVH Real Time Monitoring.",
|
||||
"<strong>Banner de subscrição:</strong> o patch aplica-se à interface web do Proxmox Backup Server, e Desinstalar otimizações repõe-na.",
|
||||
"<strong>Figurine:</strong> é instalado sem os aliases do Proxmox VE.",
|
||||
"<strong>Scripts da comunidade:</strong> a secção oferece <em>Proxmox Backup Server Post Install</em> e <em>Proxmox Backup Server Microcode</em> em vez dos scripts do Proxmox VE."
|
||||
]
|
||||
},
|
||||
"related": {
|
||||
"heading": "Relacionado",
|
||||
"items": [
|
||||
|
||||
Reference in New Issue
Block a user