docs: review backup and restore documentation in all seven translations

This commit is contained in:
Jonatan
2026-10-17 15:08:53 +02:00
parent ce1a3de719
commit ea6f6dbf6e
86 changed files with 11849 additions and 244 deletions
@@ -0,0 +1,234 @@
{
"meta": {
"title": "Destino Borg — tipos de repositório, autenticação SSH, criptografia | ProxMenux",
"description": "O destino Borg grava backups do host ProxMenux em um repositório local, em disco externo montado ou em servidor remoto via SSH. Descreve a busca pelo executável borg, as quatro opções iniciais de chave SSH, a criptografia repokey, os destinos salvos e a retenção por tarefa agendada.",
"ogTitle": "Cópia de segurança do ProxMenux — destino Borg",
"ogDescription": "Como ProxMenux escreve backups de host para repositórios Borg, com estratégias de autenticação SSH e criptografia repokey.",
"twitterTitle": "Destino de backup Borg | ProxMenux",
"twitterDescription": "Repositórios Borg locais, USB e SSH para backups de host."
},
"header": {
"title": "Borg",
"description": "O destino Borg escreve backups de host para um repositório Borg. Três tipos de repositório são suportados: caminho local do sistema de arquivos, disco externo montado, ou servidor remoto via SSH. Deduplicação de nível de chunk em todos os arquivos no repositório e criptografia opcional repokey.",
"section": "Cópias de segurança e restauro"
},
"aboutBorg": {
"heading": "O que é Borg",
"body": "Borg (também escrito BorgBackup) é uma ferramenta de backup de desduplicação de código aberto mantida pela comunidade Borg Backup. Ele armazena todos os arquivos como um conjunto de blocos de comprimento variável dentro de um repositório; blocos são compartilhados entre os arquivos, então fazer o backup de dados inalterados tem custo de armazenamento quase zero. Borg não está ligado ao Proxmox — é uma ferramenta de backup de propósito geral usada em muitos ambientes. ProxMenux usa-o como um dos três destinos para backups de host; cada mecanismo Borg-específico descrito nesta página (tipos de repositório, borg-serve sobre SSH, criptografia repokey, prune) é o comportamento padrão Borg."
},
"intro": {
"title": "Deduplicação por blocos com repositórios locais ou acessíveis via SSH",
"body": "Um repositório Borg armazena blocos compartilhados entre todos os seus arquivos de backup. Repetir o backup de um arquivo inalterado não transfere nem armazena novos dados. O ProxMenux usa <code>borg create</code> para o backup e <code>borg extract</code> para a restauração. O repositório pode estar no mesmo sistema de arquivos da origem, em disco externo montado ou em host remoto acessível via SSH."
},
"binarySourcing": {
"heading": "O binário borg",
"intro": "Borg não é uma dependência de base do instalador ProxMenux. Quando um backup é executado, o <code>hb_ensure_borg</code> resolve o binário de quatro fontes em ordem e retorna o primeiro que funciona:",
"rows": [
{
"priority": "1",
"source": "Sistema <code>borg</code>",
"detail": "Se o host já tem <code>borg</code> instalado via APT (<code>which borg</code> resolve), esse binário é usado."
},
{
"priority": "2",
"source": "Cache 'State-dir'",
"detail": "<code>/usr/local/share/proxmenux/borg</code> — mantido de um anterior download GitHub neste host."
},
{
"priority": "3",
"source": "Pacote AppImage do Monitor",
"detail": "<code>/usr/local/share/proxmenux/monitor-app/usr/bin/borg</code> — o AppImage agrupa um borg-linux64 assinado. Este é o caminho offline: um host sem internet ainda tem um <code>borg</code> funcionando."
},
{
"priority": "4",
"source": "Transferência do GitHub",
"detail": "<code>wget</code> contra a URL <code>borg-linux64</code> fixada em <code>github.com/borgbackup/borg/releases/</code>, verificada contra uma constante SHA-256 em <code>lib_host_backup_common.sh</code> (<code>HB_BORG_LINUX64_SHA256</code>). No checksum descompasso o binário é descartado e o backup aborta. O arquivo baixado é armazenado em cache na dir estado para backups subsequentes usar caminho 2."
}
]
},
"repoTypes": {
"heading": "Tipos de repositório",
"intro": "O tipo de repositório é escolhido quando um alvo é adicionado. Cada tipo resolve para um URL de repositório diferente que Borg entende.",
"rows": [
{
"type": "remote",
"url": "ssh://USER@HOST/RPATH",
"detail": "O repositório vive em um servidor remoto que executa <code>borg serve</code>. Requer uma conexão SSH para esse servidor."
},
{
"type": "usb",
"url": "/mnt/MOUNTPOINT/borgbackup",
"detail": "O repositório vive em um disco externo montado (tipicamente USB). A montagem é resolvida via <code>hb_prompt_mounted_path</code>, que detecta, monta ou formata partições USB conforme necessário."
},
{
"type": "local",
"url": "/backup/borgbackup (any absolute path)",
"detail": "O repositório vive numa pasta local. Significativo apenas quando o diretório alvo está em um disco físico separado — um repositório no mesmo disco que a fonte protege contra o erro do operador, mas não contra a falha do disco."
}
]
},
"serverSetup": {
"heading": "Preparando o servidor Borg (lado do servidor)",
"intro": "O tipo de repositório <code>remote</code> exige um servidor Borg funcional acessível via SSH. O ProxMenux não configura o servidor; apenas autoriza uma chave em uma conta existente. Esta seção descreve os requisitos antes da conexão.",
"hostChoicesTitle": "Onde o servidor pode viver",
"hostChoicesBody": "Qualquer host Linux com acesso SSH se qualifica. Configuração comum:",
"hostChoicesItems": [
"Um NAS dedicado ou caixa de backup (Debian, Ubuntu, TrueNAS SCALE com uma shell).",
"Um recipiente LXC dentro de um nó Proxmox. Pegada pequena, isolada do hospedeiro a executar os backups.",
"Outro host Proxmox na mesma LAN, ou um VM em qualquer lugar acessível sobre SSH."
],
"lxcWarningTitle": "LXC como servidor Borg",
"lxcWarningBody": "Se o servidor Borg estiver em um LXC, generate-auto exige uma conta que aceite autenticação SSH por senha para instalar a chave. Caso contrário, use a instalação manual ou a alternativa generate-pct pelo host PVE.",
"requirementsTitle": "Requisitos no servidor",
"requirementsRows": [
{
"requirement": "Executável borg em <code>/usr/bin/borg</code>",
"detail": "A linha <code>command=\"/usr/bin/borg serve ...\"</code> gravada pelo ProxMenux em <code>authorized_keys</code> usa esse caminho fixo. A instalação via APT (<code>apt install borgbackup</code>) coloca o executável ali. Um binário independente precisa de um link simbólico em <code>/usr/bin/borg</code>."
},
{
"requirement": "Uma conta de usuário dedicada (tipicamente <code>borg</code>)",
"detail": "Possui o diretório do repositório e recebe conexões SSH recebidas. Não precisa de acesso sudo ou shell — a linha authorized_keys desativa shells interativos de qualquer maneira."
},
{
"requirement": "Um diretório de repositório com escrita",
"detail": "O caminho que o operador dá ProxMenux (por exemplo <code>/backup/borgbackup</code>) deve existir no servidor e ser propriedade do usuário borg."
},
{
"requirement": "O servidor SSH aceita o usuário borg",
"detail": "<code>PubkeyAuthentication yes</code> (padrão). A autenticação por senha só é necessária para instalar a chave pelo fluxo <em>generate-auto</em>. Depois disso, o servidor pode desativar completamente a autenticação por senha."
}
],
"minimalSetupTitle": "Configuração mínima do servidor",
"minimalSetupBody": "Em um servidor Debian ou Ubuntu Borg, uma linha de base de trabalho é quatro comandos como root:",
"minimalSetupCmd": "apt install borgbackup\nuseradd -m -d /home/borg -s /bin/bash borg\nmkdir -p /backup/borgbackup\nchown borg:borg /backup/borgbackup",
"minimalSetupNote": "Com o servidor preparado e a autenticação SSH por senha disponível, <code>generate-auto</code> instala a chave por uma conta que possa gravar em authorized_keys do usuário borg. Os backups seguintes usam essa chave, restrita a <code>borg serve</code> no caminho configurado. Sem acesso por senha, instale-a manualmente ou pelo host PVE."
},
"sshAuth": {
"heading": "Autenticação SSH (lado cliente)",
"intro": "Repositórios Borg remotos são acessados sobre SSH. A conexão é executada do host ProxMenux para uma conta de usuário no servidor Borg que executa o <code>borg serve</code>. Este usuário é tipicamente chamado <code>borg</code>, NÃO o administrador/root usuário do servidor — a linha de comando borg-serve bloqueia a conexão com esse caminho específico do repositório (veja as estratégias chave abaixo).",
"strategiesTitle": "Estratégias de chave SSH",
"strategiesIntro": "Ao adicionar um destino remoto, o ProxMenux pede usuário SSH, host e caminho remoto e oferece quatro opções de autenticação. A alternativa generate-pct é oferecida quando o acesso por senha é recusado. Os modos são descritos abaixo:",
"strategyRows": [
{
"mode": "generate-auto",
"label": "Recomendado",
"detail": "O ProxMenux gera ou reutiliza um par de chaves ed25519 em <code>~/.ssh/borg_proxmenux_HOST_ed25519</code> e usa <code>sshpass</code> para testar o acesso e instalar a chave pública em <code>~borg/.ssh/authorized_keys</code>. A senha pertence a uma conta com permissão para gravar esse arquivo, normalmente root ou borg. Ela é usada durante a configuração e não é salva."
},
{
"mode": "generate-manual",
"label": "Sem senha de administração nesta máquina",
"detail": "ProxMenux gera o keypair como acima, mas exibe a linha <code>authorized_keys</code> completa para o operador colar manualmente no servidor. A senha de administrador nunca deixa o host ProxMenux porque nunca é solicitado."
},
{
"mode": "generate-pct",
"label": "O servidor Borg é um PVE LXC",
"detail": "O servidor Borg é executado dentro de um LXC em um nó PVE. ProxMenux autoriza a chave via <code>pct exec</code> do host PVE — root no host PVE escreve no LXC <code>~borg/.ssh/authorized_keys</code> sem precisar de SSH no próprio LXC."
},
{
"mode": "existing",
"label": "Usar uma chave existente",
"detail": "O ProxMenux procura em <code>/root/.ssh/</code> e <code>$HOME/.ssh/</code> chaves privadas ed25519/RSA que consiga interpretar e as lista. O operador escolhe uma ou indica manualmente um caminho não padrão."
},
{
"mode": "none",
"label": "Configuração padrão do SSH",
"detail": "Nenhuma chave personalizada — Borg depende da configuração padrão SSH da máquina (tipicamente <code>~/.ssh/id_rsa</code> ou um agente SSH)."
}
],
"restrictTitle": "A linha authorized_keys",
"restrictBody": "Para cada chave gerada, a linha <code>authorized_keys</code> gravada pelo ProxMenux no servidor restringe a chave a esta chamada de borg-serve no caminho configurado do repositório:",
"restrictLine": "command=\"/usr/bin/borg serve --restrict-to-path RPATH\",restrict PUBKEY",
"restrictNote": "O <code>command=</code> força cada sessão de SSH usando esta chave para executar apenas o comando borg-serve; <code>restrict</code> desativa o encaminhamento de portas, o encaminhamento de agentes, o encaminhamento de X11 e a alocação de PTY. A chave não pode ser usada para abrir uma shell interativa no servidor ou para acessar qualquer outro caminho do repositório, mesmo que a conta tenha privilégios mais amplos."
},
"savedTargets": {
"heading": "Alvos salvos",
"intro": "Um destino salvo mantém a configuração do repositório com um nome reconhecível, evitando digitar os dados novamente. Arquivos no diretório de estado do ProxMenux:",
"rows": [
{
"file": "borg-targets.txt",
"content": "Uma linha por destino: <code>NAME|REPO|SSH_KEY_PATH|ENCRYPT_MODE</code>. <code>hb_collect_borg_configs</code> lê o arquivo para preencher o menu de seleção de destinos."
},
{
"file": "borg-pass-NAME.txt",
"content": "Frase secreta do destino identificado acima por NAME (<code>chmod 600</code>). Presente somente quando se escolhe criptografia repokey."
}
],
"outro": "Salvar o destino é opcional. Recusar não grava a configuração com nome, mas não remove uma chave SSH gerada. Se repokey for ativado sem destino salvo, o ProxMenux ainda guarda a frase secreta no arquivo legado borg-pass.txt."
},
"encryption": {
"heading": "Criptografia",
"body": "Os repositórios são inicializados com um modo de criptografia via <code>hb_borg_init_if_needed</code>: o moderno <code>borg repo-create -e MODE</code> quando disponível, ou o legado <code>borg init --encryption=MODE</code>. ProxMenux expõe dois modos: <code>repokey</code> (padrão) e <code>none</code>. No modo <code>repokey</code> Borg armazena a chave de criptografia dentro do próprio repositório; o acesso requer uma frase-passe, que ProxMenux pede duas vezes com validação de correspondência e armazena em <code>borg-pass-NAME.txt</code> para destinos salvos, ou no arquivo legado descrito acima. Uma janela de reconhecimento obrigatória é mostrada após a frase- senha ser salva: a frase- senha é a única maneira de acessar os arquivos criptografados, e perdê- la torna cada arquivo no repositório irrecuperável."
},
"runtimeEnv": {
"heading": "Ambiente de execução",
"intro": "ProxMenux exporta as seguintes variáveis de ambiente antes de invocar <code>borg</code>. Eles configuram a conexão e desbloqueiam o repositório sem incorporar segredos na linha de comando.",
"rows": [
{
"var": "BORG_RSH",
"value": "ssh -i SSH_KEY_PATH -o IdentitiesOnly=yes -o StrictHostKeyChecking=accept-new [-p PORT]",
"purpose": "Comando remoto usado pelo Borg para repositórios SSH. Uma chave selecionada acrescenta as opções de identidade; uma porta diferente da padrão acrescenta -p PORT. Sem chave personalizada e com a porta padrão, a variável fica indefinida e o Borg usa a configuração SSH do host."
},
{
"var": "BORG_PASSPHRASE",
"value": "(passfrase de borg-pass-NAME.txt)",
"purpose": "Desbloqueia a chave repokey. Configure apenas quando o alvo usar criptografia <code>repokey</code>. Nunca aparece na lista de argumentos do processo."
},
{
"var": "BORG_ENCRYPT_MODE",
"value": "repokey | none",
"purpose": "Usado pelo <code>hb_borg_init_if_needed</code> ao inicializar um repositório que ainda não existe. Ignorado pelo <code>borg create</code> nos repositórios existentes."
},
{
"var": "BORG_RELOCATED_REPO_ACCESS_IS_OK",
"value": "yes",
"purpose": "Suprime o prompt interativo que Borg levanta quando o URL do repositório difere do URL que foi originalmente alcançado (comum após um renomeamento de ponto de montagem ou SSH-host acessível via novo endereço)."
},
{
"var": "BORG_UNKNOWN_UNENCRYPTED_REPO_ACCESS_IS_OK",
"value": "yes",
"purpose": "Suprime o prompt interativo Borg levanta a primeira vez que um repositório não criptografado é acessado de um novo cliente."
}
]
},
"archiveFormat": {
"heading": "Nome e retenção do arquivo",
"intro": "Cada backup cria um novo arquivo dentro do repositório.",
"namePattern": "hostcfg-HOSTNAME-YYYYMMDD_HHMMSS",
"retentionBody": "Para trabalhos agendados, o <code>run_scheduled_backup.sh</code> executa <code>borg prune</code> contra o repositório após cada backup bem sucedido com os valores de retenção configurados no trabalho (<code>--keep-last</code>, <code>--keep-daily</code>, <code>--keep-weekly</code>). Os backups interativos não removem backups antigos."
},
"restoreAccess": {
"heading": "Obtenção no lado da restauração",
"body": "A restauração lista os arquivos com <code>borg list REPO</code> e extrai o selecionado com <code>borg extract REPO::ARCHIVE-NAME</code> em um diretório de preparação. <code>_rs_check_layout</code> o encaminha ao processo padrão de restauração. Os mesmos comandos funcionam manualmente fora do ProxMenux; a árvore extraída tem a estrutura de três blocos descrita em <em>Como funciona</em>."
},
"references": {
"heading": "Referências",
"intro": "Documentação oficial do Borg para os componentes usados pelo ProxMenux.",
"items": [
{
"label": "Documentação Borg",
"href": "https://borgbackup.readthedocs.io/",
"tail": " — ponto de entrada principal que abrange conceitos, implantação, arranque rápido e todos os comandos."
},
{
"label": "borg create",
"href": "https://borgbackup.readthedocs.io/en/stable/usage/create.html",
"tail": " — o comando usado pelo ProxMenux em cada backup, com todas as opções aceitas."
},
{
"label": "Criptografia do repositório",
"href": "https://borgbackup.readthedocs.io/en/stable/usage/init.html#encryption-mode",
"tail": " — os modos de criptografia aceitos pelo Borg, incluindo repokey, usado por padrão pelo ProxMenux."
},
{
"label": "borg serve e implantação via SSH",
"href": "https://borgbackup.readthedocs.io/en/stable/deployment/central-backup-server.html",
"tail": " — configuração de um servidor Borg central acessível via SSH, incluindo o comando borg-serve e a opção restrict-to-path que o ProxMenux grava em authorized_keys."
},
{
"label": "borg prune",
"href": "https://borgbackup.readthedocs.io/en/stable/usage/prune.html",
"tail": " — o modelo de retenção de --keep-last / --keep-daily / --keep-weekly aplicado pelo ProxMenux em cada tarefa agendada."
}
]
}
}
@@ -0,0 +1,110 @@
{
"meta": {
"title": "Destinos das cópias de segurança — arquivo local, Proxmox Backup Server e Borg | ProxMenux",
"description": "Três backends de armazenamento recebem a mesma carga útil de backup ProxMenux: um arquivo .tar.zst local em qualquer sistema de arquivos com permissão de gravação, um backup PBS em uma datastore Proxmox Backup Server, ou um arquivo Borg em um repositório Borg local ou remoto. Cada infra-estrutura tem suas próprias características de compressão, desduplicação, criptografia e rede.",
"ogTitle": "Destinos de backup do ProxMenux",
"ogDescription": "Local, Proxmox Backup Server e Borg — três backends de armazenamento para a mesma carga útil de backup do host.",
"twitterTitle": "Destinos de backup do ProxMenux | ProxMenux",
"twitterDescription": "Arquivos locais, infraestruturas Proxmox Backup Server e Borg para backups de host."
},
"header": {
"title": "Destinos",
"description": "Três backends de armazenamento suportados pelo ProxMenux Backup: arquivo local, Proxmox Backup Server (recomendado) e Borg. Cada um recebe o mesmo arquivo de três blocos de dados; eles diferem em formato de armazenamento, deduplicação, modelo de criptografia e requisitos de rede.",
"section": "Cópias de segurança e restauro"
},
"intro": {
"title": "Mesmo conteúdo, três backends",
"body": "Cada backup produz as mesmas três cargas (rootfs, manifesto, aplicações). O que muda entre destinos é como essas cargas são armazenadas e como o operador as recupera para uma restauração. Cada infra-estrutura é implementada como uma função separada em <code>backup_host.sh</code> — <code>_bk_local</code>, <code>_bk_pbs</code>, <code>_bk_borg</code> — mas todos os três compartilham a mesma etapa de preparação temporária (<code>hb_prepare_staging</code>) e o mesmo caminho de restauração de código. A escolha de destino apenas afeta a escrita e a recuperação; ela não altera o que uma restauração faz ou como consome o arquivo."
},
"comparison": {
"heading": "Comparação de características",
"intro": "A tabela a seguir lista as diferenças concretas entre as três infra-estruturas como se comportam hoje em ProxMenux. Todos os valores descrevem o comportamento observado da própria infra-estrutura, não as recomendações editoriais.",
"rows": [
{
"feature": "Formato de armazenamento",
"local": "Um ficheiro <code>.tar.zst</code> (ou <code>.tar.gz</code> se o <code>zstd</code> estiver ausente).",
"pbs": "Backup PBS (blocos <code>.pxar</code> no datastore).",
"borg": "Arquivo Borg dentro de um repositório Borg (arquivos de segmentos)."
},
{
"feature": "Compressão",
"local": "zstd (nível padrão) via <code>tar --zstd</code>. gzip fallback.",
"pbs": "Gerenciada pelo proxmox-backup-client. O ProxMenux não altera as configurações de compressão.",
"borg": "Compressão integrada do Borg. O ProxMenux chama borg create sem alterar as configurações de compressão."
},
{
"feature": "Desduplicação",
"local": "Nenhuma. Cada backup é um arquivo independente completo.",
"pbs": "Deduplicação completa por blocos entre todos os backups no datastore.",
"borg": "Deduplicação completa por blocos entre todos os arquivos do repositório."
},
{
"feature": "Criptografia em repouso",
"local": "Nenhum (depende da proteção do sistema de arquivos).",
"pbs": "Criptografia opcional do lado do cliente com um arquivo de chave. Quando ativada, o blob de recuperação é enviado em um grupo de backup separado.",
"borg": "Criptografia opcional repokey (chave armazenada no repo, desbloqueada por uma frase- senha)."
},
{
"feature": "Retenção / limpeza",
"local": "Aplicada por trabalho agendado via <code>KEEP_LAST</code>. Os arquivos antigos são removidos junto com seus arquivos auxiliares e logs de execução. Os backups interativos não fazem limpeza.",
"pbs": "Aplicado por trabalho programado via <code>proxmox-backup-client prune --keep-last / --keep-daily / --keep-weekly</code>. Os backups interativos não fazem limpeza.",
"borg": "Aplicado por trabalho programado via <code>borg prune --keep-last / --keep-daily / --keep-weekly</code>. Os backups interativos não fazem limpeza."
},
{
"feature": "Rede",
"local": "Nenhuma. Escreve para um ponto de montagem local (tipicamente um disco interno ou uma unidade USB).",
"pbs": "TCP para o servidor PBS (porta padrão 8007). Requer credenciais PBS + impressão digital.",
"borg": "Localização local do sistema de ficheiros ou túnel SSH para uma máquina Borg remota."
},
{
"feature": "Dependências",
"local": "<code>tar</code>, <code>zstd</code> (presente no Proxmox por padrão).",
"pbs": "Pacote <code>proxmox-backup-client</code> (incluído no Proxmox VE 8+).",
"borg": "binário <code>borg</code>. Auto-fornecido por ProxMenux do pacote Monitor AppImage quando faltando."
},
{
"feature": "Acesso para restauração",
"local": "Qualquer máquina com tar+zstd pode extrair o arquivo. Não é necessário PBS/Borg.",
"pbs": "Requer <code>proxmox-backup-client</code>, credenciais PBS e o arquivo de chave (se o backup estiver criptografado).",
"borg": "Requer <code>borg</code> + o caminho do repositório + a senha (se criptografada)."
}
],
"captionCode": "feature",
"captionLocal": "Local",
"captionPbs": "Proxmox Backup Server (recomendado)",
"captionBorg": "Borg"
},
"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."
},
"extractStandalone": {
"heading": "Extraindo um backup fora de ProxMenux",
"intro": "Qualquer um dos três formatos de arquivo pode ser lido com ferramentas padrão sem ProxMenux instalado no host de leitura. Os comandos abaixo produzem a mesma árvore de diretórios que uma restauração consome internamente.",
"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": "# De um arquivo Borg (requer borg e a senha dos repositórios criptografados):\nborg extract REPO-PATH::ARCHIVE-NAME\n\n# Em um repositório remoto acessível por SSH:\nborg extract ssh://USER@HOST:PORT/REPO-PATH::ARCHIVE-NAME",
"note": "A árvore extraída pode então ser inspecionada manualmente ou alimentada a uma restauração manual. Veja as páginas de destino individuais para o fluxo de recuperação exato que o ProxMenux usa sob o capô."
},
"whereNext": {
"heading": "Detalhes por destino",
"intro": "Cada destino tem sua própria página cobrindo o fluxo de configuração, o formato on-disk e o comando de recuperação usado pela restauração.",
"items": [
{
"label": "Arquivo local",
"href": "/docs/backup-restore/destinations/local",
"tail": " — pré-configurando um alvo local, montagem da unidade USB, a verificação de segurança contra a gravação do arquivo em si, o sidecar JSON que permite ao Monitor identificar o arquivo."
},
{
"label": "Proxmox Backup Server (recomendado)",
"href": "/docs/backup-restore/destinations/pbs",
"tail": " — seleção de datastore, credenciais e impressão digital, ciclo de vida do arquivo de chave de criptografia, senha de recuperação, carregando o blob de recuperação para PBS para recuperação de nova instalação."
},
{
"label": "Borg",
"href": "/docs/backup-restore/destinations/borg",
"tail": " — repositórios locais ou acessíveis por SSH, origem do binário Borg (sistema / cache / pacote AppImage do Monitor / download do GitHub), inicialização do repositório, gerenciamento da senha e configuração da chave SSH para repositórios remotos."
}
]
}
}
@@ -0,0 +1,75 @@
{
"meta": {
"title": "Destino de arquivo local — tar.zst em um sistema de arquivos ou unidade USB | ProxMenux",
"description": "O destino de backup local escreve um único arquivo .tar.zst para qualquer diretório com permissão de gravação: um disco interno, um ponto de montagem Proxmox, uma partilha NFS, ou uma unidade USB. Documenta o fluxo de configuração, a lógica de detecção e montagem USB, a verificação de segurança contra a gravação do arquivo em um caminho que está sendo feito backup, e o sidecar JSON que identifica o arquivo.",
"ogTitle": "Cópia de segurança do ProxMenux — Destino do arquivo local",
"ogDescription": "Como ProxMenux escreve backups locais como arquivos .tar.zst e como configurar o diretório de destino ou unidade USB.",
"twitterTitle": "Destino de backup local | ProxMenux",
"twitterDescription": "Como ProxMenux escreve backups locais como arquivos .tar.zst em um sistema de arquivos ou unidade USB."
},
"header": {
"title": "Arquivo local",
"description": "O destino local escreve um único arquivo de tar comprimido para qualquer diretório com permissão de gravação no host: um disco interno, uma montagem NFS ou SMB, ou uma unidade USB.",
"section": "Cópias de segurança e restauro"
},
"intro": {
"title": "Um arquivo, auto-suficiente",
"body": "Um backup local produz um único arquivo <code>hostcfg-HOST-TIMESTAMP.tar.zst</code> (ou <code>.tar.gz</code> quando <code>zstd</code> está ausente). O arquivo contém toda a árvore de arquivos — <code>manifest.json</code>, <code>metadata/</code> e <code>rootfs/</code> — e pode ser restaurado em qualquer host Proxmox com o fluxo de restauração ProxMenux, ou extraído manualmente com <code>tar --zstd -xf</code> em qualquer sistema Linux. Nenhum servidor, nenhuma inicialização de repositório, nenhuma dependência externa. Este é o destino com o caminho de recuperação mais curto quando nem PBS nem Borg está disponível."
},
"targetConfig": {
"heading": "Configurando o diretório alvo",
"intro": "O destino local é um <strong>único diretório de destino salvo de forma persistente</strong> — não uma lista. ProxMenux armazena a escolha do operador em <code>/usr/local/share/proxmenux/local-target.conf</code> e lê essa escolha em cada backup. Quando nenhum alvo foi configurado, o <code>HB_LOCAL_TARGET_DEFAULT = /var/lib/vz/dump</code> padrão é usado (o mesmo diretório que o Proxmox usa para suas próprias saídas <code>vzdump</code>). O alvo está configurado a partir de <em>Configure destinos de backup → Destinos locais</em>:",
"options": [
"<strong>Use o padrão (<code>/var/lib/vz/dump</code>).</strong> O armazenamento local Proxmox. Presente em cada instalação do Proxmox; o arquivo fica ao lado das saídas vzdump e é captado automaticamente pela aba Backups do Monitor.",
"<strong>Insira um caminho personalizado.</strong> Qualquer caminho absoluto do sistema de arquivos pode ser usado: uma montagem NFS, uma partilha SMB montada via <code>fstab</code>, um conjunto de dados dedicado ZFS, um segundo disco interno. ProxMenux valida que o caminho existe e é um diretório antes de persisti-lo.",
"<strong>Escolha uma unidade USB.</strong> Abre o submenu USB (abaixo), que detecta dispositivos removíveis e oferece para montar ou formatar um."
]
},
"usbFlow": {
"heading": "Detecção e montagem de unidades USB",
"intro": "O submenu USB lista partições em dispositivos removíveis relatados pelo <code>lsblk</code>. Cada partição é apresentada com seu tamanho, etiqueta do sistema de arquivos e estado atual. O estado determina a ação que o ProxMenux oferece.",
"statesTitle": "Os três estados do dispositivo",
"stateRows": [
{
"state": "montado",
"shown": "Tamanho · etiqueta · [fstype] · → /mount/point",
"action": "A partição já está montada em algum lugar. Selecioná-la salva o ponto de montagem atual como alvo local. Nenhuma montagem é realizada."
},
{
"state": "desmontado",
"shown": "Tamanho · etiqueta · [fstype] · (não montado — será montado)",
"action": "Um sistema de ficheiros está presente mas não está montado. Na confirmação, o ProxMenux executa o <code>hb_mount_usb_partition</code>: cria o <code>/mnt/backup-LABEL</code> (ou um caminho baseado em UUID, se não houver rótulo), monta a partição e persiste o ponto de montagem como alvo local."
},
{
"state": "vazia",
"shown": "Tamanho · disco USB bruto — sem sistema de arquivos (será FORMATADO)",
"action": "O dispositivo não tem sistema de arquivos. Essa operação destrutiva exige duas confirmações. Primeiro, uma janela Sim/Não explica que o disco será apagado. Depois, um campo exige que o usuário <strong>digite o caminho exato do dispositivo</strong> (por exemplo <code>/dev/sdb</code>) antes de o ProxMenux criar uma nova tabela GPT com uma partição ext4 e montá-la."
}
],
"notMountedFallback": "Quando nenhum dispositivo USB é detectado, o submenu cai de volta para uma caixa de entrada simples. O operador pode indicar uma localização arbitrária do ponto de montagem; se a localização não for um ponto de montagem registado, uma janela de confirmação avisa antes de prosseguir."
},
"safetyCheck": {
"heading": "Verificação de segurança — destino dentro de um caminho de backup",
"body": "Antes de gravar o arquivo, <code>_bk_local</code> verifica se o diretório de destino <strong>não</strong> é um subcaminho de qualquer diretório cujo backup está sendo feito. Um erro comum seria adicionar <code>/root</code> ao perfil e escolher <code>/root/backups</code> como destino - o arquivo então se incluiria, produzindo um arquivo corrompido ou crescendo sem limites até que o disco ficasse cheio. A verificação resolve ambos os caminhos com <code>readlink -m</code>, compara-os e, em caso de conflito, aborta o backup com uma caixa de diálogo que nomeia o caminho conflitante e lista três maneiras de resolvê-lo: escolha um destino fora do caminho conflitante, remova a entrada personalizada que contém o destino ou use o modo Personalizado para desmarcar o caminho conflitante para esta execução."
},
"archiveFormat": {
"heading": "Formato de arquivo e compressão",
"intro": "O nome do arquivo de saída inclui o nome do host de origem e a data e hora do backup, permitindo ordenar as cópias cronologicamente no diretório e identificar cada arquivo.",
"namePattern": "hostcfg-HOSTNAME-YYYYMMDD_HHMMSS.tar.zst",
"compressionTitle": "Compressão",
"compressionBody": "O caminho primário usa <code>tar --zstd -cf</code> — um pipeline de um único comando que comprime ao nível padrão do zstd. Quando <code>zstd</code> não está presente na fonte (raro em Proxmox, mas possível em instalações mínimas), ProxMenux cai de volta para <code>gzip</code>. No caminho de retorno, se o <code>pv</code> estiver disponível, uma barra de progresso é adicionada ao pipeline para que o operador veja o tamanho do arquivo crescer em tempo real; sem o <code>pv</code>, o <code>tar -czf</code> simples é usado silenciosamente.",
"sourceTitle": "O que vai para o arquivo",
"sourceBody": "O comando tar é chamado com <code>-C \"$staging_root\" .</code>, incluindo <strong>toda a raiz da área de preparação</strong>: <code>rootfs/</code>, <code>metadata/</code> e <code>manifest.json</code>. Os três blocos de dados ficam lado a lado na raiz do arquivo tar. A extração produz exatamente a árvore usada pelo código de restauração."
},
"sidecar": {
"heading": "O arquivo auxiliar JSON",
"intro": "Cada backup local bem sucedido produz um arquivo companheiro: <code>HOSTNAME-TIMESTAMP.tar.zst.proxmenux.json</code>, escrito ao lado do arquivo por <code>hb_write_archive_sidecar</code>. Este pequeno arquivo JSON permite que o ProxMenux Monitor identifique o arquivo como um backup de host ProxMenux mesmo que mais tarde seja movido, renomeado ou arquivado em outro lugar.",
"contentTitle": "Conteúdo do sidecar",
"contentBody": "O sidecar armazena a versão do esquema, se o backup veio de uma execução interativa ou de uma tarefa agendada (<code>kind</code>), o ID do trabalho para as execuções agendadas, o modo de perfil usado (<code>default</code> ou <code>custom</code>), o nome de máquina de origem, o nome de base do arquivo original, um timestamp de criação ISO-8601 e o tamanho do arquivo em bytes.",
"whyBody": "A aba Backups do Monitor procura arquivos auxiliares <code>*.proxmenux.json</code> nos diretórios locais configurados, e não arquivos <code>*.tar.zst</code>, pois um <code>.tar.zst</code> sem arquivo auxiliar pode não ser um backup ProxMenux. A busca é rápida (os arquivos JSON são pequenos) e a associação permanece válida após renomear o arquivo, desde que o auxiliar seja renomeado de forma correspondente."
},
"restoreAccess": {
"heading": "Restaurando de um arquivo local",
"body": "O fluxo de restauração ProxMenux descobre arquivos locais digitalizando o alvo local configurado para sidecars e exibindo-os na lista Arquivos. A seleção de um arquivo aciona <code>_rs_check_layout</code>, que extrai o tarball em um diretório de preparação temporária e confirma o layout de três cargas antes de prosseguir. Para extração manual fora de ProxMenux, <code>tar --zstd -xf hostcfg-HOSTNAME-TIMESTAMP.tar.zst -C /tmp/hostcfg</code> produz a mesma árvore que o código de restauração consome."
}
}
@@ -0,0 +1,113 @@
{
"meta": {
"title": "Proxmox Backup Server destino — repositório, encriptação, recuperação ProxMenux",
"description": "O destino PBS grava os backups do host ProxMenux como backups PBS. Documenta a descoberta de repositórios em /etc/pve/storage.cfg, a configuração manual, o envio de .pxar, a criptografia no cliente com arquivo de chave e sua cópia de recuperação opcional protegida por frase secreta, e a recuperação da chave por várias fontes em um host recém-instalado.",
"ogTitle": "Cópia de segurança ProxMenux — destino Proxmox Backup Server",
"ogDescription": "Como o ProxMenux grava backups do host no Proxmox Backup Server com criptografia por arquivo de chave no cliente e uma cópia da chave para recuperação.",
"twitterTitle": "PBS destino de backup □ ProxMenux",
"twitterDescription": "Destino Proxmox Backup Server com criptografia por arquivo de chave e cópia de recuperação protegida por frase secreta."
},
"header": {
"title": "Proxmox Backup Server",
"description": "O destino PBS envia todo o diretório de preparação como um único backup .pxar para um datastore Proxmox Backup Server. A criptografia no cliente com arquivo de chave é opcional, assim como o envio, junto a cada backup, de uma cópia da chave protegida por frase secreta para recuperação.",
"section": "Cópias de segurança e restauro"
},
"recommendedBadge": "Destino recomendado",
"aboutPbs": {
"heading": "O que é Proxmox Backup Server",
"body": "Proxmox Backup Server (PBS) é o próprio produto do servidor de backup da Proxmox, desenvolvido e mantido pela mesma equipe que o autor Proxmox VE. É um servidor de backup dedicado projetado para receber backups de hosts Proxmox VE (VMs, LXCs e — via <code>proxmox-backup-client</code> — diretórios host arbitrários) com deduplicação baseada em blocos, criptografia do lado do cliente e políticas de retenção aplicadas lado servidor. ProxMenux usa PBS como um dos três destinos para backups de host; cada mecanismo específico PBS descrito nesta página (grupos de backup, arquivos <code>.pxar</code>, criptografia de arquivos de chaves <code>--backup-id</code>) é o comportamento padrão PBS."
},
"intro": {
"title": "Um backup por execução, dedup de nível de blocos",
"body": "Um backup PBS cria uma única entrada no datastore, sob o ID <code>host/hostcfg-HOSTNAME/BACKUP-TIME</code>. Os dados formam um arquivo <code>.pxar</code> com a estrutura de três blocos descrita em <em>Como funciona</em>. O PBS deduplica blocos entre todos os backups do datastore, de modo que backups posteriores do mesmo host transferem e armazenam apenas os blocos alterados. Nas tarefas agendadas, o próprio ProxMenux aplica a retenção: após cada execução bem-sucedida, <code>run_scheduled_backup.sh</code> executa <code>proxmox-backup-client prune</code> com <code>--keep-last</code> / <code>--keep-daily</code> / <code>--keep-weekly</code> e os valores configurados na tarefa."
},
"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.",
"sourceRows": [
{
"source": "storage.cfg do Proxmox (deteção automática)",
"path": "/etc/pve/storage.cfg + /etc/pve/priv/storage/NAME.pw",
"content": "Qualquer estrofe <code>pbs:</code> na própria configuração de armazenamento do Proxmox é captada automaticamente. Servidor, datastore, nome de usuário e impressão digital vêm da estrofe. A senha é lida no diretório de credenciais do Proxmox. Nenhuma reentrada necessária no lado ProxMenux — o repositório está disponível assim que estiver configurado no Proxmox."
},
{
"source": "Configuração manual do ProxMenux",
"path": "/usr/local/share/proxmenux/pbs-manual-configs.txt + pbs-pass-NAME.txt + pbs-fingerprint-NAME.txt",
"content": "Adicionado de <em>Configure destinos de backup → destinos de PBS → Adicione PBS</em>. Pede um nome, nome de usuário (<code>root@pam</code> ou <code>user@pbs!token</code>), host ou IP, datastore e senha. A senha re-prompts na entrada vazia — uma gravação vazia persistiria silenciosamente e cada backup subsequente falharia com um erro de autenticação opaco. Este caminho é usado quando o PBS alvo não é registrado como armazenamento Proxmox."
}
],
"menuTitle": "Menu de seleção",
"menuBody": "Ambas as fontes são mostradas em um único menu, cada linha marcada com sua origem (<code>[proxmox]</code> ou <code>[manual]</code>). As entradas cuja senha não pôde ser resolvida são marcadas com um aviso <code>⚠ no password</code> — selecionando-se um aciona uma reentrada de senha antes do backup começar. A impressão digital é passada para <code>proxmox-backup-client</code> através da variável de ambiente <code>PBS_FINGERPRINT</code>; quando ausente, o cliente pede ao operador para aceitar o certificado do servidor de forma interativa no primeiro backup."
},
"backupCommand": {
"heading": "O comando de backup",
"intro": "O envio usa uma única chamada de <code>proxmox-backup-client backup</code>. O ProxMenux usa <code>env</code> para passar ao cliente a senha, a senha de criptografia e a impressão digital como variáveis de ambiente.",
"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": "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>."
},
"encryption": {
"heading": "Criptografia do lado do cliente",
"glossaryHint": "Esta seção usa os termos <em>arquivo de chave</em>, <em>frase secreta</em> e <em>envelope de recuperação</em>. O <glosarioLink>glossário</glosarioLink> resume as diferenças em uma frase por termo.",
"intro": "A criptografia PBS no cliente com arquivo de chave cifra os blocos no host de origem antes do envio. No ProxMenux ela é opcional. Ao ativá-la, o operador escolhe explicitamente sim ou não durante a configuração se deseja enviar ao PBS também uma cópia de recuperação do arquivo de chave protegida por frase secreta; a escolha pode ser alterada depois no Monitor. O arquivo fica sempre no caminho canônico <code>/usr/local/share/proxmenux/pbs-key.conf</code> e é reutilizado sem novas perguntas em todos os backups criptografados posteriores.",
"keyfileTitle": "Configurar o arquivo de chaves",
"keyfileBody": "O diálogo de criptografia aparece no primeiro backup criptografado do host. Primeiro pergunta se deseja criptografar o backup: <em>Não</em> continua sem criptografia, e <em>Sim</em> passa à segunda etapa. Esta depende da existência de um arquivo de chave em <code>/usr/local/share/proxmenux/pbs-key.conf</code>. Se existir, ele é reutilizado sem novas perguntas e o backup continua; os backups posteriores também não perguntam novamente. Caso contrário, um menu oferece duas opções. <em>Gerar um novo arquivo de chave</em> executa <code>proxmox-backup-client key create --kdf none</code>. <em>Usar um arquivo de chave existente</em> detecta automaticamente uma chave gerenciada pelo PVE: se o repositório PBS selecionado estiver registrado no Proxmox com uma chave de criptografia em <code>/etc/pve/priv/storage/&lt;NAME&gt;.enc</code>, o arquivo será copiado sem perguntas para o caminho canônico do ProxMenux. Se nenhuma chave PVE corresponder ao repositório, será solicitado o caminho absoluto onde o operador já colocou o arquivo neste host. Nos dois casos, o arquivo fica no caminho canônico com <code>chmod 600</code>.",
"modesTitle": "Arquivo de chave por host ou compartilhado",
"modesIntro": "Os dois modelos são aceitos e nenhum é obrigatório: o operador escolhe conforme a organização dos seus hosts.",
"modesPerHostTitle": "Arquivo de chave por host (padrão)",
"modesPerHostBody": "Cada host gera seu próprio arquivo de chaves na primeira vez que ele permite criptografia PBS. O isolamento é máximo: comprometer o arquivo de chaves de um host não expõe os backups de nenhum outro. Recomendado para frotas de produção e ambientes onde hospedeiros têm diferentes proprietários ou limites de conformidade.",
"modesSharedTitle": "Arquivo de chaves compartilhado (importação em cada máquina)",
"modesSharedBody": "Um arquivo-chave mestre gerado uma vez e instalado em cada host por meio da opção <em>Usar um arquivo-chave existente</em>. O gerenciamento é mais simples: um único segredo para proteger e qualquer host pode descriptografar os arquivos de qualquer outro (útil para consolidação, exercícios de restauração entre hosts ou verificação de backup centralizada). A desvantagem é que um vazamento do arquivo-chave compartilhado expõe todos os hosts de uma só vez. Recomendado para homelabs e frotas onde todos os hosts têm o mesmo proprietário e limite de confiança.",
"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.",
"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",
"blobUploadConstraintBody": "Uma única chamada de <code>proxmox-backup-client backup</code> criptografa todos os seus arquivos com a mesma chave ou não criptografa nenhum; não permite misturar os dois casos. O backup do host precisa ser criptografado com a chave do host, mas o envelope de recuperação não pode acompanhá-lo no mesmo envio, pois acabaria criptografado com a própria chave que contém. Em um host recém-instalado, seria impossível abri-lo: seria necessária a chave para descriptografar a própria chave. Por isso os dois artefatos são enviados separadamente e aparecem em dois grupos. O cliente PBS criptografa o backup do host com o arquivo de chave, e o ProxMenux criptografa o envelope com a frase secreta antes do envio. Duas camadas de criptografia diferentes protegem dois elementos distintos.",
"blobUploadImageAlt": "PBS UI mostrando os grupos de backup hostcfg-HOSTNAME e hostcfg-HOSTNAME-keyrecovery adjacentes na listagem de datastore.",
"blobUploadImageCaption": "Interface PBS — os grupos de backup associados. O grupo principal contém os backups do host; o grupo -keyrecovery contém o arquivo de chave protegido por frase secreta.",
"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."
},
"restoreAccess": {
"heading": "Obtenção no lado da restauração",
"body": "A restauração localiza os backups do host ProxMenux no PBS listando os grupos do repositório configurado e filtrando pelo padrão do ID. A aba Backups do Monitor exibe a mesma lista. Escolher um backup executa <code>proxmox-backup-client restore</code> com os mesmos repositório, senha e impressão digital, além de <code>--keyfile</code> se estiver criptografado. O arquivo <code>.pxar</code> é extraído em um diretório de preparação que <code>_rs_check_layout</code> encaminha ao processo normal de restauração. Fora do ProxMenux, o mesmo comando extrai o arquivo no caminho desejado para inspecionar a árvore ou realizar uma restauração manual."
},
"references": {
"heading": "Referências",
"intro": "Documentação oficial do Proxmox Backup Server para os componentes usados pelo ProxMenux.",
"items": [
{
"label": "Documentação Proxmox Backup Server",
"href": "https://pbs.proxmox.com/docs/",
"tail": " — o ponto de entrada principal que abrange a instalação, administração, armazenagem, utilizadores e funções."
},
{
"label": "proxmox-backup-client",
"href": "https://pbs.proxmox.com/docs/backup-client.html",
"tail": " — a ferramenta de linha de comando que o ProxMenux usa em cada backup e restauração. Descreve IDs e tipos de backup, arquivos, sintaxe dos repositórios e variáveis de ambiente."
},
{
"label": "Criptografia do lado do cliente",
"href": "https://pbs.proxmox.com/docs/backup-client.html#encryption",
"tail": " — criação do arquivo de chave, modos --kdf e modelo de criptografia que o ProxMenux amplia com uma cópia de recuperação protegida por frase secreta."
},
{
"label": "Gestão de armazenamento de dados",
"href": "https://pbs.proxmox.com/docs/storage.html",
"tail": " — criação e gerenciamento dos datastores que recebem backups do host, incluindo a estrutura do armazenamento de blocos e as permissões."
},
{
"label": "Poda e coleta de lixo",
"href": "https://pbs.proxmox.com/docs/maintenance.html#pruning",
"tail": " — o modelo de retenção de --keep-last / --keep-daily / --keep-weekly aplicado pelo ProxMenux em cada tarefa agendada e como o PBS libera blocos não usados após a remoção de backups antigos."
}
]
}
}