- 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
"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."
"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",
"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 como 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."
"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."
"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 bemsucedido."
"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",
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
MacRimi