docs: review backup and restore documentation in all seven translations

web/messages/pt/docs/backup-restore/creating-backups.json

@@ -0,0 +1,220 @@
+{
+  "meta": {
+    "title": "Criação de backups — fluxo de backup interativo ProxMenux",
+    "description": "O fluxo de backup interativo do ProxMenux: dois pontos de entrada (o menu TUI do Scripts e a interface web do Monitor), três destinos, dois modos de perfil, uma etapa de preparação temporária e uma janela de confirmação. A página descreve a matriz de seis opções, os perfis padrão e personalizado e o que o usuário vê desde a seleção do backup até o arquivo ser salvo no destino.",
+    "ogTitle": "Backup ProxMenux — criando backups",
+    "ogDescription": "O fluxo de backup interativo com três destinos, dois perfis e uma etapa comum de preparação temporária.",
+    "twitterTitle": "Criando backups ProxMenux",
+    "twitterDescription": "Fluxo de backup interativo com três destinos e dois modos de perfil."
+  },
+  "header": {
+    "title": "Criando backups",
+    "description": "O fluxo de backup interativo: escolha um destino e um perfil, confira o resumo de confirmação e acompanhe o salvamento do arquivo. Os dois pontos de entrada compartilham o mesmo backend e produzem arquivos idênticos.",
+    "section": "Cópias de segurança e restauro"
+  },
+  "intro": {
+    "title": "Dois pontos de entrada, funcionalidade idêntica",
+    "body": "A TUI do Scripts e a interface web do Monitor oferecem <strong>exatamente as mesmas funções</strong>. Cada backup — manual ou agendado — passa pela mesma matriz de escolha (três destinos × dois perfis) e chama a mesma função do backend em cada célula (<code>_bk_pbs</code>, <code>_bk_borg</code> ou <code>_bk_local</code>). Os arquivos produzidos pelos dois pontos de entrada são indistinguíveis. A escolha depende da preferência: a TUI é adequada para SSH e scripts; o Monitor oferece controle por cliques junto às visualizações de notificações e acompanhamento dos logs."
+  },
+  "entryPoints": {
+    "heading": "Os dois pontos de entrada",
+    "rows": [
+      {
+        "entry": "ProxMenux Scripts (TUI)",
+        "path": "menu → Utilities → Host Config Backup",
+        "detail": "Fluxo baseado em diálogo, SSH-friendly. O menu principal apresenta as seis opções diretamente. Utiliza <code>backup_menu</code> em <code>backup_host.sh</code>."
+      },
+      {
+        "entry": "ProxMenux Monitor (UI Web)",
+        "path": "Backups tab → Create backup",
+        "detail": "Fluxo guiado por um assistente. As mesmas seis opções são apresentadas em um formulário de duas etapas (destino → perfil). As mesmas funções do backend são chamadas pela API Flask."
+      }
+    ]
+  },
+  "modes": {
+    "heading": "Cópias de segurança manuais vs agendadas",
+    "body": "Os backups podem ser produzidos em dois modos: <strong>manual</strong> (o fluxo interativo descrito nesta página — o usuário escolhe um destino e um perfil de um menu e acompanha o salvamento do arquivo) ou <strong>agendado</strong> (um trabalho sem acompanhamento que roda em um temporizador no estilo cron e aplica a retenção configurada no trabalho). Ambos os modos suportam os mesmos três destinos e os mesmos dois perfis, e ambos estão disponíveis em ambos os pontos de entrada — o menu Scripts TUI e a aba Monitor Backups. Trabalhos agendados usam as mesmas funções de infraestrutura que o fluxo manual através do <code>run_scheduled_backup.sh</code>; os arquivos produzidos são indistinguíveis.",
+    "seeAlso": "A página de trabalhos agendados cobre o fluxo completo, incluindo como criar um trabalho, anexá-lo a um temporizador existente PVE vzdump e configurar os valores de retenção.",
+    "monitorAlt": "Página de backups do ProxMenux Monitor que mostra a nova janela de backup agendada com os campos de destino, perfil, agenda e retenção.",
+    "monitorCaption": "Backup agendado — ProxMenux Monitor. A mesma janela do assistente usada para criar um backup manual inclui, na parte inferior, os campos de agendamento e retenção para execução sem acompanhamento."
+  },
+  "matrix": {
+    "heading": "A matriz de seis opções",
+    "intro": "A escolha determina tanto o backend executado quanto a estratégia de seleção de caminhos. Consulte as páginas de cada destino para os detalhes de configuração de cada célula.",
+    "rows": [
+      {
+        "combo": "1",
+        "destination": "PBS",
+        "profile": "Padrão",
+        "action": "Envia o perfil padrão mais extras persistentes para um repositório PBS configurado."
+      },
+      {
+        "combo": "2",
+        "destination": "Borg",
+        "profile": "Padrão",
+        "action": "Cria um arquivo com o perfil padrão mais extras persistentes no repositório Borg selecionado."
+      },
+      {
+        "combo": "3",
+        "destination": "Local",
+        "profile": "Padrão",
+        "action": "Escreve um arquivo <code>.tar.zst</code> com o perfil padrão mais extras persistentes para o alvo local configurado."
+      },
+      {
+        "combo": "4",
+        "destination": "PBS",
+        "profile": "Personalizado",
+        "action": "Abre o seletor de caminhos antes do envio ao PBS; o usuário marca os caminhos e pode adicionar novos."
+      },
+      {
+        "combo": "5",
+        "destination": "Borg",
+        "profile": "Personalizado",
+        "action": "Abre o seletor de caminhos antes de criar o arquivo Borg."
+      },
+      {
+        "combo": "6",
+        "destination": "Local",
+        "profile": "Personalizado",
+        "action": "Abre o selecionador de caminho antes de escrever o <code>.tar.zst</code> local."
+      }
+    ]
+  },
+  "profiles": {
+    "heading": "Perfil padrão vs personalizado",
+    "defaultTitle": "Perfil padrão",
+    "defaultBody": "O perfil padrão é a lista com curadoria de <code>hb_default_profile_paths</code> (documentada em <em>Como funciona</em> sob <em>Categorias de caminho</em>) além de cada entrada no arquivo de extras persistente <code>/usr/local/share/proxmenux/backup-extra-paths.txt</code>. O usuário confirma as opções de destino e criptografia e o backup prossegue sem mais seleção de caminho.",
+    "customTitle": "Perfil personalizado",
+    "customBody": "O perfil personalizado abre uma lista com todos os caminhos do perfil padrão (desmarcados) e todos os extras persistentes (pré-marcados, com o prefixo <code>[+]</code>). O usuário marca os caminhos para esta execução e pode pressionar <em>Adicionar caminho personalizado</em> para incluir um novo caminho absoluto. Todo caminho adicionado durante esse processo é salvo em <code>backup-extra-paths.txt</code>, para que os próximos backups o incluam automaticamente. Desmarcar um extra persistente o exclui apenas desta execução, sem removê-lo do arquivo — a remoção é feita pela ação separada <em>Gerenciar caminhos personalizados</em>, fora do fluxo de backup.",
+    "customPickerAlt": "Lista de verificação de perfil personalizada que mostra os caminhos de perfil padrão (desmarcados) e extras persistentes (pré-marcados com um prefixo [+]), além de botões para adicionar um novo caminho ou confirmar a seleção.",
+    "customPickerCaption": "Perfil personalizado — o seletor de caminhos. Os caminhos do perfil padrão estão desmarcados; os extras persistentes aparecem pré-marcados com o prefixo [+]. O usuário marca os caminhos para esta execução.",
+    "manageCustomAlt": "Menu de gerenciamento de caminhos personalizados com a lista de extras persistentes e opções para adicionar, remover ou editar.",
+    "manageCustomCaption": "Gerencie caminhos personalizados — o ponto de entrada onde extras persistentes são adicionados ou removidos. Cada caminho listado aqui é incluído automaticamente em backups de modo padrão sem precisar abrir o seletor Personalizado."
+  },
+  "commonPipeline": {
+    "heading": "O que é executado independentemente do destino",
+    "intro": "Depois de definir o perfil, cada backend executa o mesmo processo de preparação temporária antes de seguir para seu próprio método de envio. <code>hb_prepare_staging</code> monta a árvore do arquivo em <code>/tmp/proxmenux-DESTINATION-stage.XXXXXX</code> e preenche cada um dos três blocos de dados.",
+    "steps": [
+      {
+        "step": "1",
+        "name": "Montagem do rootfs",
+        "detail": "Executa <code>rsync -a</code> para cada caminho selecionado em <code>staging_root/rootfs/</code>. O banco de dados pmxcfs em <code>/var/lib/pve-cluster/config.db</code> é capturado separadamente via <code>sqlite3 .backup</code> para produzir um instantâneo consistente sem parar o cluster, e os sidecars <code>.db-wal</code> / <code>.db-shm</code> são excluídos do rsync; quando o <code>sqlite3</code> não está disponível é salvo um arquivo <code>config.db.raw-fallback</code>, que a restauração adota como banco de dados durante a importação. Os subcaminhos voláteis (histórico do bash, caches, lixo) são excluídos do <code>/root/</code>. Caminhos ausentes da fonte são registrados em <code>metadata/missing_paths.txt</code> sem parar o backup."
+      },
+      {
+        "step": "2",
+        "name": "Geração do manifesto",
+        "detail": "<code>build_manifest.sh</code> coordena os seis coletores e grava <code>manifest.json</code> na raiz da área de preparação temporária. Se um coletor falhar, a seção afetada usa um valor padrão vazio documentado; o manifesto continua válido."
+      },
+      {
+        "step": "3",
+        "name": "Inventário de pacotes",
+        "detail": "<code>apt-mark showmanual</code> é capturada literalmente em <code>metadata/packages.manual.list</code>. O estado do componente já está dentro do rootfs restaurado (<code>components_status.json</code>) porque o <code>/usr/local/share/proxmenux/</code> faz parte do perfil padrão."
+      },
+      {
+        "step": "4",
+        "name": "Informações da execução",
+        "detail": "<code>metadata/run_info.env</code> registra a identidade de execução de backup — hostname, timestamp, versão do kernel — usada pela verificação de compatibilidade da restauração para determinar a direção do cross-kernel."
+      },
+      {
+        "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."
+      }
+    ]
+  },
+  "included": {
+    "heading": "O que entra e o que fica fora",
+    "intro": "Cada caminho no perfil resolvido (padrão + extras persistentes + seleção de modo personalizado) é copiado com <code>rsync -aAXH --numeric-ids</code>. Uma lista de exclusão compartilhada aplica-se a cada caminho, e dois diretórios carregam exclusões adicionais específicas do caminho.",
+    "globalTitle": "Exclusões globais (aplicadas a cada caminho)",
+    "globalItems": [
+      "<code>images/</code> — dumps de imagens.",
+      "<code>dump/</code> — saídas vzdump.",
+      "<code>tmp/</code> — ficheiros temporários.",
+      "<code>*.log</code> — ficheiros de registo."
+    ],
+    "rootTitle": "Exclusões <code>/root/</code>",
+    "rootBody": "<code>/root/</code> faz parte do perfil padrão para incluir os scripts e a configuração do usuário no arquivo. Os subcaminhos voláteis são excluídos:",
+    "rootItems": [
+      "<code>.bash_history</code>",
+      "<code>.cache/</code>",
+      "<code>tmp/</code>",
+      "<code>.local/share/Trash/</code>"
+    ],
+    "proxmenuxTitle": "Exclusões <code>/usr/local/share/proxmenux/</code>",
+    "proxmenuxBody": "Este diretório envia apenas o estado do usuário — <code>components_status.json</code>, preferências, cache pós-instalação. O código que o destino já terá a partir de sua própria instalação ProxMenux está excluído para que uma restauração não sobrescreva os binários atuais do alvo com os mais antigos:",
+    "proxmenuxItems": [
+      "<code>restore-pending/</code>, <code>scripts/</code>, <code>web/</code>",
+      "<code>monitor-app/</code>, <code>monitor-app.*/</code>, <code>AppImage/</code>",
+      "<code>images/</code>, <code>json/</code>",
+      "<code>utils.sh</code>, <code>helpers_cache.json</code>",
+      "<code>ProxMenux-Monitor.AppImage*</code>, <code>install_proxmenux*.sh</code>"
+    ],
+    "notInProfileTitle": "Caminhos fora do perfil",
+    "notInProfileBody": "Qualquer coisa não listada no <code>hb_default_profile_paths</code> e não adicionada como um extra personalizado ou persistente não faz parte do backup. Exemplos notáveis:",
+    "notInProfileItems": [
+      "<strong>Discos de VMs e LXC</strong> — manipulado por <code>vzdump</code>, não por esta característica. Os arquivos de configuração de hóspedes sob <code>/etc/pve/nodes/*/qemu-server/*.conf</code> e <code>lxc/*.conf</code> são capturados (eles vivem sob <code>/etc/pve</code>) para que a restauração reproduza o inventário; os próprios discos são re-anexados a partir de um backup existente vzdump/PBS.",
+      "<strong><code>/boot</code> e <code>/boot/efi</code></strong> — binários do kernel, initramfs e a partição UEFI ESP são regeneradas pelo próprio alvo <code>update-initramfs</code>, <code>update-grub</code> ou <code>proxmox-boot-tool refresh</code> após a restauração. O carregador de arranque nunca é copiado na íntegra.",
+      "<strong>Sistemas de arquivos de tempo de execução e sistema</strong> — <code>/proc</code>, <code>/sys</code>, <code>/dev</code> e <code>/run</code> são pseudo-sistemas de arquivos produzidos pelo kernel e udev; eles não são persistidos em nenhum lugar.",
+      "<strong>Binários dos pacotes em <code>/usr/bin</code>, <code>/usr/lib</code>, <code>/lib</code>, <code>/sbin</code></strong> — reinstalados pelo APT do destino a partir de <code>packages.manual.list</code>.",
+      "<strong><code>/var/log/</code>, <code>/var/tmp/</code>, <code>/var/cache/</code></strong> — estado de execução por host, não restaurado.",
+      "<strong><code>/home/USER</code></strong> — não no perfil padrão. Adicione-o como um caminho personalizado quando um sistema carrega diretórios domésticos do usuário que devem sobreviver a uma restauração."
+    ],
+    "customPathsTitle": "Como os caminhos personalizados são tratados",
+    "customPathsBody": "Um caminho personalizado adicionado inline em modo Personalizado ou persistido em <code>backup-extra-paths.txt</code> passa pelo mesmo pipeline <code>rsync</code> como caminhos de perfil padrão. Exclusões globais aplicam-se. Se o caminho personalizado estiver sob <code>/root/</code> ou <code>/usr/local/share/proxmenux/</code>, as exclusões específicas do caminho acima ainda se aplicam. Cada caminho arquivado — padrão ou personalizado — é gravado em <code>metadata/paths_archived.txt</code>. Caminhos que não existem na fonte são gravados em <code>metadata/missing_paths.txt</code> sem parar o backup."
+  },
+  "archiveStructure": {
+    "heading": "Estrutura do arquivo",
+    "intro": "O diretório de preparação temporária produzido por cada infraestrutura segue o mesmo layout, independentemente do destino. O tarball, PBS <code>.pxar</code> ou arquivo Borg armazena esta árvore sem alterações.",
+    "tree": "backup-[timestamp]/\n├── manifest.json                  # structured host state (kernel_params, hardware, storage, guests, components, source_host)\n├── metadata/\n│   ├── packages.manual.list       # output of apt-mark showmanual\n│   ├── run_info.env               # hostname, timestamp, kernel version, pmxcfs method\n│   ├── paths_archived.txt         # exact list of paths that reached rootfs/\n│   └── missing_paths.txt          # paths from the profile absent on source\n└── rootfs/\n    ├── etc/                       # /etc/pve, /etc/network, /etc/systemd/network, /etc/ssh, /etc/apt, ...\n    ├── root/                      # /root without volatile subpaths\n    ├── usr/local/                 # /usr/local/bin, /usr/local/sbin, /usr/local/share/proxmenux (state only)\n    └── var/                       # /var/lib/pve-cluster (config.db via sqlite3 .backup), /var/spool/cron/crontabs"
+  },
+  "confirmation": {
+    "heading": "Resumo da confirmação",
+    "body": "Antes da infra- estrutura escrever qualquer coisa para o destino, o ProxMenux mostra uma janela sumária com o nome do destino, ID de backup ou arquivo, estado de criptografia e a lista de caminhos copiados. Cancelar aqui aborta o backup de forma limpa — o diretório de preparação temporária é removido pelo gancho <code>trap</code> definido na função de infraestrutura e nenhum dado parcial atinge o destino."
+  },
+  "writing": {
+    "heading": "Gravando para o destino",
+    "intro": "Após a confirmação, cada backend executa sua própria etapa de gravação. As páginas dos destinos descrevem o funcionamento; os elementos comuns são o log, o arquivo auxiliar e a notificação de conclusão.",
+    "rows": [
+      {
+        "topic": "Arquivo de registro",
+        "detail": "Cada infra- estrutura escreve sua saída completa para <code>/tmp/proxmenux-DESTINATION-backup-YYYYMMDD_HHMMSS.log</code> e, em caso de falha, oferece abri-la em uma janela de rolagem. O caminho do log é impresso no resumo de conclusão somente quando o arquivo tem conteúdo."
+      },
+      {
+        "topic": "Sidecar (apenas local)",
+        "detail": "<code>hb_write_archive_sidecar</code> solta um <code>*.proxmenux.json</code> ao lado do arquivo local para que o monitor o identifique como um backup de host ProxMenux mesmo depois de mover ou renomear."
+      },
+      {
+        "topic": "Notificação (conclusão/falha)",
+        "detail": "<code>hb_notify_lifecycle \"complete\"</code> ou <code>\"fail\"</code> é acionado com a duração, o tamanho do arquivo e — em caso de falha — a última linha do log que parece indicar um erro."
+      }
+    ]
+  },
+  "finishedScreens": {
+    "heading": "Como é uma cópia de segurança terminada",
+    "intro": "O mesmo evento de conclusão é exibido pelos dois pontos de entrada. O TUI escreve um bloco de resumo para o terminal; a aba Backups do Monitor mostra a execução na lista de arquivos com o tamanho, a duração e os crachás de status.",
+    "scriptsAlt": "ProxMenux Scripts TUI mostrando um backup final do host — destino, ID de backup, caminho de instantâneo, tamanho de dados, duração e estado de criptografia.",
+    "scriptsCaption": "Cópia de segurança terminada — ProxMenux Scripts (TUI). O bloco de conclusão imprime o destino, backup ID, instantâneo resultante ou nome do arquivo, tamanho dos dados, duração e estado de criptografia.",
+    "monitorAlt": "Página de backups ProxMenux Monitor mostrando uma entrada de backup de host terminada com tamanho, duração, crachá de método e indicador de criptografia.",
+    "monitorCaption": "Backup concluído — aba Backups do ProxMenux Monitor. O novo backup aparece na lista de arquivos com o indicador do método de destino, tamanho, duração e — quando aplicável — o ícone de cadeado da criptografia."
+  },
+  "whereNext": {
+    "heading": "Para onde ir a seguir",
+    "items": [
+      {
+        "label": "Destinos",
+        "href": "/docs/backup-restore/destinations",
+        "tail": " — detalhes de configuração para Local, PBS e Borg."
+      },
+      {
+        "label": "Trabalhos agendados",
+        "href": "/docs/backup-restore/scheduled-jobs",
+        "tail": " — executar o mesmo backup sem acompanhamento em um cronograma em vez de interativamente."
+      },
+      {
+        "label": "Restauração",
+        "href": "/docs/backup-restore/restoring",
+        "tail": " — o fluxo que consome o que esta página produz."
+      }
+    ]
+  }
+}

web/messages/pt/docs/backup-restore/cross-kernel.json

@@ -0,0 +1,170 @@
+{
+  "meta": {
+    "title": "Restauro entre kernels diferentes — deteção, filtragem segura e adaptação | ProxMenux",
+    "description": "Como ProxMenux restaura um backup de host em um alvo executando uma versão diferente do kernel principal. Documenta como a direção do descompasso é detectada, o filtro seguro-subset que salta caminhos de inicialização-críticos quando o alvo executa um kernel mais novo do que o backup, e a hidratação quatro fases do kernel-agnóstico que reaplica a sintonia do usuário como IOMMU, IDs VFIO e tokens personalizados cmdline sem copiar arquivos de kernel-ligados verbatim.",
+    "ogTitle": "ProxMenux Backup – restauração e hidratação do kernel cruzado",
+    "ogDescription": "Restauração entre versões do kernel que considera a direção da mudança, com filtro seguro e hidratação independente do kernel.",
+    "twitterTitle": "Restauro entre kernels diferentes | ProxMenux",
+    "twitterDescription": "Como ProxMenux lida com uma restauração quando o kernel alvo difere do backup."
+  },
+  "header": {
+    "title": "Restauração do kernel cruzado",
+    "description": "Como o ProxMenux lida com uma restauração quando o host alvo executa um kernel diferente daquele gravado no backup — especialmente quando o alvo executa um kernel mais recente. Documenta como a diferença é detectada, como caminhos críticos de inicialização que podem quebrar o alvo são filtrados, e como a configuração do próprio usuário é reaplicada sem copiar arquivos ligados ao kernel verbatim.",
+    "section": "Cópias de segurança e restauro"
+  },
+  "intro": {
+    "title": "Cada salto do kernel é tratado de forma diferente",
+    "body": "O kernel de um host Proxmox é identificado por uma string de versão como <code>6.17.13-2-pve</code>. Os dois primeiros números (<strong>6.17</strong> neste exemplo) definem a versão principal: quando eles mudam, alguns arquivos de configuração escritos para o kernel anterior podem não ser válidos no novo. Quando a restauração detecta que o backup e o alvo têm diferentes versões principais do kernel, os ramos de fluxo baseados na direção do salto — se o backup é mais antigo ou mais recente do que o alvo — porque os dois casos têm modos de falha opostos. Backups mais recentes do que o destino restaurar limpamente como-is (bench-verified em vários saltos do kernel). Backups mais antigos do que o alvo precisam de um filtro para evitar quebrar a inicialização do alvo com configuração escrita para um kernel que desde então mudou."
+  },
+  "directionCheck": {
+    "heading": "Verificação da direcção",
+    "intro": "Durante a verificação de compatibilidade, <code>hb_compat_check</code> compara o kernel registrado no manifesto do backup com o kernel atual do alvo (<code>uname -r</code>) e classifica a restauração em um dos três casos, armazenados na variável interna <code>HB_COMPAT_KERNEL_DIRECTION</code>:",
+    "rows": [
+      {
+        "direction": "same",
+        "condition": "A versão principal do kernel corresponde entre backup e alvo.",
+        "behavior": "O fluxo total de restauração corre inalterado. Sem filtro extra, sem hidratação, sem aviso especial na UI."
+      },
+      {
+        "direction": "bk_newer",
+        "condition": "O kernel de backup é mais novo do que o do alvo (por exemplo: o backup foi feito no kernel 7.0 e o alvo executa o kernel 6.17).",
+        "behavior": "O fluxo completo permanece inalterado, como em <code>same</code>, sem filtro. Nos testes relatados, os drivers foram reinstalados para o kernel de destino, a configuração IOMMU foi aplicada e as VMs iniciaram com passthrough de GPU."
+      },
+      {
+        "direction": "bk_older",
+        "condition": "O kernel do backup é MAIS ANTIGO que o de destino (por exemplo: backup no 6.17, destino no 7.0).",
+        "behavior": "O filtro seguro e a hidratação em quatro fases abaixo são ativados. A restauração prossegue — o alvo reproduz a fonte, mas os arquivos de inicialização críticos não são copiados literalmente."
+      }
+    ]
+  },
+  "whyBkNewerIsSafe": {
+    "heading": "Por que um backup com um kernel mais novo do que o alvo restaura inalterado",
+    "body": "Quando a restauração corre contra um alvo com um kernel <em>mais antigo</em> do que o registrado no backup, cada mecanismo que a restauração depende é independente da versão do kernel. Os instaladores de driver GPU e outros instaladores de dispositivos PCI detectam o kernel em execução com <code>uname -r</code> e compilam DKMS contra qualquer que seja o alvo. O pacote APT install puxa binários construídos para a distribuição do alvo. Os tokens cmdline IOMMU como <code>intel_iommu=on</code> são estáveis nas principais versões do kernel. O backup carrega caminhos escritos sob um kernel mais recente, mas esses caminhos (listas-negra de módulos, padrões GRUB, configuração initramfs) ainda são sintaxe válida no antigo - kernels ignoram tokens que não reconhecem em vez de falhar. Este caso é, na prática, equivalente a uma restauração do mesmo núcleo, e o ProxMenux trata-o como tal."
+  },
+  "safeSubsetFilter": {
+    "heading": "O filtro de segurança (apenas quando o kernel alvo é mais novo)",
+    "intro": "Quando o kernel alvo é mais novo do que o backup, a verificação de compatibilidade adiciona 16 Caminhos críticos de arranque de <code>hb_unsafe_paths_cross_version</code> para <code>RS_SKIP_PATHS</code>. Estes caminhos são excluídos da restauração porque escrever uma versão deles de um kernel mais antigo sobre um alvo executando um mais recente causou pânico do kernel em testes de banco. Os caminhos abrangem cinco categorias:",
+    "categoryRows": [
+      {
+        "category": "Gestor de arranque",
+        "paths": "<code>/etc/default/grub</code>, <code>/etc/kernel</code>",
+        "reason": "GRUB predefinições ligadas à ordem anterior do kernel, e estado proxmox-boot-tool (cmdline, ESP UUIDs, ganchos) que referencia caminhos e identificadores da instalação mais antiga."
+      },
+      {
+        "category": "Módulos de kernel e artefatos de inicialização",
+        "paths": "<code>/etc/modules-load.d</code>, <code>/etc/modprobe.d</code>, <code>/etc/initramfs-tools</code>",
+        "reason": "Listas de autocarregamento que podem referenciar módulos renomeados entre majors de kernel, opções de módulo que podem não se aplicar, ganchos initramfs escritos para o kernel antigo."
+      },
+      {
+        "category": "Stack de armazenamento e identidade do sistema de arquivos",
+        "paths": "<code>/etc/fstab</code>, <code>/etc/multipath</code>, <code>/etc/iscsi</code>, <code>/etc/udev/rules.d</code>, <code>/etc/zfs</code>",
+        "reason": "UUIDs que podem não existir nesta instalação, drivers multicaminho que mudam entre kernels, parâmetros iSCSI que evoluem, regras udev que podem se ligar a subsistemas inexistentes, estado ZFS (<code>zpool.cache</code> + <code>hostid</code>) que podem bloquear o pool como estrangeiro."
+      },
+      {
+        "category": "Fontes APT",
+        "paths": "<code>/etc/apt</code>",
+        "reason": "As suítes de código fonte APT podem desencadear uma redução de pacotes críticos na próxima atualização."
+      },
+      {
+        "category": "systemd",
+        "paths": "<code>/etc/systemd/system</code>, <code>/etc/systemd/journald.conf</code>, <code>/etc/systemd/logind.conf</code>, <code>/etc/systemd/system.conf</code>, <code>/etc/systemd/user.conf</code>",
+        "reason": "Sobrescritas de unidades e links .wants ligados à versão principal antiga do systemd; chaves de configuração que podem não ser válidas na versão nova."
+      }
+    ],
+    "outroBody": "O filtro é executado ANTES da janela de confirmação para que o utilizador veja a lista exacta dos caminhos que serão ignorados, categorizados pela razão. A restauração continua — tudo o resto (configuração VM/LXC, rede, /etc/pve, usuários, cron, ProxMenux estado, pacotes, drivers, /root) é restaurado normalmente."
+  },
+  "hydration": {
+    "heading": "Hidratação independente do kernel",
+    "intro": "O filtro omite arquivos críticos; a hidratação reaplica ajustes selecionados: cmdline IOMMU, IDs VFIO, <code>GRUB_TIMEOUT</code> personalizado e listas de bloqueio nvidia. Executa se o kernel de destino for mais novo. A mesclagem cmdline preserva chaves do destino e adiciona módulos ausentes. Valores GRUB e arquivos permitidos podem substituir conteúdo diferente no destino. Repetir as mesmas entradas é idempotente.",
+    "phaseRows": [
+      {
+        "phase": "1a — Via GRUB",
+        "detail": "Para hosts GRUB (instalações ext4/lvm). <code>_rs_hyd_grub</code> mescla os parâmetros de <code>manifest.kernel_params.cmdline_extra</code> do backup em <code>GRUB_CMDLINE_LINUX_DEFAULT</code> do destino, ignorando chaves já presentes. Depois restaura as chaves permitidas <code>GRUB_*</code> (<code>GRUB_TIMEOUT</code>, <code>GRUB_TIMEOUT_STYLE</code>, <code>GRUB_DEFAULT</code>, <code>GRUB_TERMINAL</code>, <code>GRUB_DISABLE_OS_PROBER</code>, <code>GRUB_SERIAL_COMMAND</code>, <code>GRUB_GFXMODE</code>, <code>GRUB_GFXPAYLOAD_LINUX</code>) de <code>/etc/default/grub</code> do backup se seus valores diferirem do destino."
+      },
+      {
+        "phase": "1b — systemd-boot / ZFS",
+        "detail": "Para systemd-boot (normalmente ZFS na raiz). <code>_rs_hyd_kernel_cmdline</code> mescla parâmetros do usuário de <code>cmdline_extra</code> em <code>/etc/kernel/cmdline</code> do destino, preservando os parâmetros de inicialização <code>root=</code>, <code>boot=</code> e <code>rootflags=</code> do destino."
+      },
+      {
+        "phase": "2 — fusão /etc/modules",
+        "detail": "<code>_rs_hyd_modules</code> adiciona os módulos de <code>manifest.kernel_params.modules_loaded_at_boot</code> que estão na lista branca (<code>vfio</code>, <code>vfio_pci</code>, <code>vfio_iommu_type1</code>, <code>vfio_virqfd</code>, <code>kvm</code>, <code>kvm_intel</code>, <code>kvm_amd</code>, <code>nvidia</code>, <code>nvidia_drm</code>, <code>nvidia_modeset</code>, <code>nvidia_uvm</code>, <code>i915</code>, <code>xe</code>) E ainda não está presente no objectivo <code>/etc/modules</code>."
+      },
+      {
+        "phase": "3 — Cópia de ficheiros na lista branca",
+        "detail": "<code>_rs_hyd_files</code> copia arquivos criados pelo usuário dos rootfs de estadiamento para o alvo ao vivo quando o conteúdo difere. A lista branca abrange arquivos VFIO/nvidia/blacklist sob <code>/etc/modprobe.d</code>, <code>/etc/modules-load.d</code>, e a regra de ligação ProxMenux VFIO + nvidia regras udev sob <code>/etc/udev/rules.d</code>. Arquivos distro-proprietários (<code>pve-blacklist.conf</code>, <code>mdadm.conf</code>, <code>nvme.conf</code>) são intencionalmente excluídos — seu conteúdo evolui entre lançamentos."
+      },
+      {
+        "phase": "4 — Forçar regeneração após a inicialização",
+        "detail": "As quatro fases escrevem diretamente para o alvo vivo fora do processo de restauração normal. Para fazer com que os tokens/módulos/arquivos fundidos façam efeito na próxima inicialização, o <code>HB_HYDRATION_APPLIED=1</code> propaga-se através do <code>plan.env</code> ao <code>apply_pending_restore.sh</code>, que força o <code>NEEDS_INITRAMFS=1</code> e o <code>NEEDS_GRUB=1</code> independentemente do que estava na lista de aplicações. O expedidor pós-boot regenera initramfs e atualiza o carregador de boot."
+      }
+    ]
+  },
+  "planCommit": {
+    "heading": "Plano vs commit — o utilizador vê uma antevisão primeiro",
+    "body": "A hidratação funciona em dois modos. Antes da janela de confirmação, o ProxMenux executa o <code>_rs_apply_bk_older_hydration</code> no modo <code>plan</code>: calcula exatamente o que seria mesclado, povoa o <code>RS_HYDRATION_SUMMARY</code> com um bloco verde listando cada ação e retorna sem escrever. O diálogo de confirmação mostra que o bloco verde ao lado da lista amarela dos caminhos excluídos, para que o usuário veja ANTES o que será reaplicado automaticamente. Depois que o usuário confirma, o ProxMenux executa novamente o mesmo helper no modo <code>commit</code> — as mesmas fases, a mesma lógica, mas desta vez cada fase escreve para o alvo ao vivo. Cancelar a janela de confirmação deixa o alvo intocado."
+  },
+  "flowDiagram": {
+    "heading": "O fluxo quando o kernel alvo é mais novo do que o backup",
+    "intro": "Os passos adicionados quando o kernel alvo é mais novo sentam-se dentro do fluxo de restauração normal. Tudo o resto — aplicar, preparar, instalar o pacote, enviar pós-boot — é executado de forma idêntica a uma restauração do mesmo kernel.",
+    "diagram": "  ┌────────────────────────────────────────────────────────────┐\n  │ hb_compat_check                                             │\n  │   HB_COMPAT_KERNEL_DIRECTION = bk_older                     │\n  └───────────────────────────┬────────────────────────────────┘\n                              │\n                              ▼\n  ┌────────────────────────────────────────────────────────────┐\n  │ Add 16 boot-critical paths to RS_SKIP_PATHS                 │\n  │   /etc/default/grub, /etc/kernel, /etc/modules-load.d, ...  │\n  └───────────────────────────┬────────────────────────────────┘\n                              │\n                              ▼\n  ┌────────────────────────────────────────────────────────────┐\n  │ _rs_apply_bk_older_hydration \"plan\"                         │\n  │   Compute what would be merged                              │\n  │   Populate RS_HYDRATION_SUMMARY (green block)               │\n  │   No writes                                                 │\n  └───────────────────────────┬────────────────────────────────┘\n                              │\n                              ▼\n  ┌────────────────────────────────────────────────────────────┐\n  │ Confirmation dialog                                         │\n  │   Amber: paths skipped by safe-subset filter                │\n  │   Green: tokens/files reapplied by hydration                │\n  │   User accepts or cancels                                   │\n  └───────────────────────────┬────────────────────────────────┘\n                              │ (accepted)\n                              ▼\n  ┌────────────────────────────────────────────────────────────┐\n  │ _rs_apply_bk_older_hydration \"commit\"                       │\n  │   Phase 1a/1b: merge cmdline tokens + GRUB keys             │\n  │   Phase 2: append modules to /etc/modules                   │\n  │   Phase 3: copy whitelisted vfio/nvidia files               │\n  │   Set HB_HYDRATION_APPLIED=1                                │\n  └───────────────────────────┬────────────────────────────────┘\n                              │\n                              ▼\n  ┌────────────────────────────────────────────────────────────┐\n  │ Rest of the restore runs normally                           │\n  │   _rs_apply hot (skips RS_SKIP_PATHS)                       │\n  │   _rs_prepare_pending_restore (writes plan.env with         │\n  │     HB_HYDRATION_APPLIED=1)                                 │\n  │   packages.manual.list install                              │\n  │   Reboot                                                    │\n  │   apply_pending_restore.sh (forces NEEDS_INITRAMFS=1,       │\n  │     NEEDS_GRUB=1 because of the hydration flag)             │\n  │   apply_cluster_postboot.sh                                 │\n  │     update-initramfs -u -k all                              │\n  │     update-grub / proxmox-boot-tool refresh                 │\n  │     component --auto-reinstall                              │\n  └────────────────────────────────────────────────────────────┘"
+  },
+  "concreteExamples": {
+    "heading": "Exemplos concretos",
+    "intro": "O passe de hidratação não é abstrato — produz resultados observáveis e corretos para cenários comuns. Dois exemplos que a hidratação manuseia automaticamente:",
+    "rows": [
+      {
+        "scenario": "Passagem GPU (VFIO)",
+        "detail": "Fonte: <code>intel_iommu=on iommu=pt</code> no cmdline, <code>vfio</code>/<code>vfio_pci</code>/<code>vfio_iommu_type1</code> no <code>/etc/modules</code>, um <code>/etc/modprobe.d/vfio.conf</code> com <code>options vfio-pci ids=10de:2216</code>, e um <code>/etc/modprobe.d/blacklist-nvidia.conf</code>. A hidração funde os tokens cmdline com o GRUB ou o kernel cmdline do alvo, adiciona os módulos vfio ao <code>/etc/modules</code> e copia os dois arquivos modprobe do usuário. Na próxima inicialização, o IOMMU está ativo, os módulos VFIO são carregados, o GPU está ligado ao vfio-pci e o VM vem com o trabalho de passagem."
+      },
+      {
+        "scenario": "Por omissão personalizada do GRUB",
+        "detail": "Fonte: <code>GRUB_TIMEOUT=1</code> e <code>GRUB_DISABLE_OS_PROBER=true</code>. Hydration lê ambas as chaves do <code>/etc/default/grub</code>, vê que elas diferem dos padrões da instalação recente, e reescreve essas duas linhas no arquivo do alvo (deixando tudo, incluindo o <code>GRUB_DISTRIBUTOR</code>, intocado)."
+      }
+    ]
+  },
+  "callout": {
+    "warningTitle": "O que a hidratação não reaplica quando o kernel alvo é mais novo",
+    "warningBody": "A hidratação reaplica apenas a configuração ProxMenux sabe ser segura em todas as versões do kernel: tokens IOMMU, IDs VFIO, chaves GRUB permitidas e módulos de uma lista fixa (<code>vfio*</code>, <code>nvidia*</code>, <code>i915</code>, <code>xe</code>, <code>kvm*</code>). Qualquer coisa fora desse conjunto — ganchos de initramfs personalizados sob <code>/etc/initramfs-tools/hooks/</code>, arquivos não listados em <code>/etc/modprobe.d/</code>, sobreposições de unidades systemd criadas pelo usuário — permanece excluída. A razão é concreta: esses arquivos podem chamar de interfaces internas do kernel (a APIs de módulo, layout <code>/sys</code>, ganchos <code>udev</code>) que mudam entre as versões principais, e aplicá-las literalmente sobre o kernel mais novo pode impedir que o alvo arranque. Quando a reprodução exata da cadeia de inicialização é necessária, a restauração deve ser executada em um host com a mesma versão principal do kernel que o backup."
+  },
+  "codeReference": {
+    "heading": "Onde vivem os mecanismos",
+    "intro": "Para os desenvolvedores que procuram rastrear ou estender o comportamento do cross-kernel:",
+    "rows": [
+      {
+        "component": "Detecção da direcção",
+        "location": "<code>hb_compat_check</code> em <code>lib_host_backup_common.sh</code>. Define <code>HB_COMPAT_KERNEL_DIRECTION</code>."
+      },
+      {
+        "component": "Lista de caminhos do filtro seguro",
+        "location": "<code>hb_unsafe_paths_cross_version</code> em <code>lib_host_backup_common.sh</code>. Emite <code>path\\treason</code> linhas usadas tanto pelo filtro CLI como pelo endpoint da Web <code>/api/host-backups/restore/prepare</code>."
+      },
+      {
+        "component": "Fases de hidratação",
+        "location": "<code>_rs_hyd_grub</code>, <code>_rs_hyd_kernel_cmdline</code>, <code>_rs_hyd_modules</code>, <code>_rs_hyd_files</code> em <code>backup_host.sh</code>. Orquestrado por <code>_rs_apply_bk_older_hydration</code>."
+      },
+      {
+        "component": "Regeneração forçada após a inicialização",
+        "location": "<code>apply_pending_restore.sh</code> lê <code>HB_HYDRATION_APPLIED</code> de <code>plan.env</code> e força <code>NEEDS_INITRAMFS=1</code>/<code>NEEDS_GRUB=1</code>."
+      },
+      {
+        "component": "Visualização da Web",
+        "location": "<code>/api/host-backups/restore/prepare</code> em <code>flask_server.py</code>. Carrega a biblioteca auxiliar, executa <code>_rs_apply_bk_older_hydration</code> no modo plano, retorna as ações para o modal Web."
+      }
+    ]
+  },
+  "whereNext": {
+    "heading": "Para onde ir a seguir",
+    "items": [
+      {
+        "label": "Restauração",
+        "href": "/docs/backup-restore/restoring",
+        "tail": " — o fluxo completo de restauração que integra os mecanismos desta página."
+      },
+      {
+        "label": "Como funciona",
+        "href": "/docs/backup-restore/how-it-works",
+        "tail": " — manifesto e coletores que produzem o bloco <code>kernel_params</code> lido pela hidratação."
+      }
+    ]
+  }
+}

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

@@ -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."
+      }
+    ]
+  }
+}

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

@@ -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."
+      }
+    ]
+  }
+}

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

@@ -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."
+  }
+}

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

@@ -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."
+      }
+    ]
+  }
+}

web/messages/pt/docs/backup-restore/glossary.json

@@ -0,0 +1,230 @@
+{
+  "meta": {
+    "title": "Glossário — Cópia de segurança e restauração ProxMenux",
+    "description": "Termos do sistema de backup e restauração ProxMenux: criptografia, arquivo de chaves, frase-senha, envelope de recuperação, PBS, blocos, rootfs, manifesto, executor e hidratação entre versões do kernel.",
+    "ogTitle": "Glossário das cópias de segurança e do restauro | ProxMenux",
+    "ogDescription": "Definições claras dos termos usados na documentação de backup e restauração ProxMenux.",
+    "twitterTitle": "Glossário das cópias de segurança e do restauro | ProxMenux",
+    "twitterDescription": "Senha, arquivo de chaves, envelope de recuperação, rootfs, manifesto, PBS, blocos — todos definidos em um só lugar."
+  },
+  "header": {
+    "title": "Glossário",
+    "description": "Termos usados através da documentação de backup e restauração, com sua definição.",
+    "section": "Cópias de segurança e restauro"
+  },
+  "intro": {
+    "body": "Os termos são agrupados por tema. Cada entrada dá o termo e uma definição curta."
+  },
+  "groups": [
+    {
+      "title": "Criptografia e recuperação de chaves",
+      "intro": "Vocabulário para o bloco de criptografia PBS. Envolve dois segredos distintos: um arquivo binário e uma frase-passe escrita.",
+      "entries": [
+        {
+          "id": "passphrase-recuperacion",
+          "term": "Senha de recuperação",
+          "def": "Senha de texto que o usuário escolhe para proteger o <a href=\"#sobre-recuperacion\">envelope de recuperação</a>. Ele é solicitado duas vezes com uma verificação de correspondência, e só é usado para criptografar o envelope e para decifrá-lo se o arquivo de chaves alguma vez precisa ser recuperado. <strong>Não é a frase-passe que desbloqueia o próprio arquivo de chaves</strong>, e nunca é enviado para PBS. Durante um backup normal, ele nunca deixa o hospedeiro."
+        },
+        {
+          "id": "clave-cifrado",
+          "term": "Arquivo de chaves (chave de criptografia)",
+          "def": "Arquivo de chave usado por proxmox-backup-client para criptografar os <a href=\"#chunk\">blocos</a> antes do envio ao PBS. Sem a chave correspondente, os dados criptografados não podem ser lidos. O ProxMenux o salva em <code>/usr/local/share/proxmenux/pbs-key.conf</code> com modo <code>600</code>. Proteja-o: o <a href=\"#sobre-recuperacion\">envelope de recuperação</a> permite recuperá-lo se for perdido."
+        },
+        {
+          "id": "contrasena-keyfile",
+          "term": "Frase- senha do ficheiro de chaves (frase- senha do KDF)",
+          "def": "Senha opcional que o próprio arquivo de chaves pode carregar, distinta da frase-passe <a href=\"#passphrase-recuperacion\">de recuperação</a>. Ele só existe quando o arquivo de chaves foi criado com <code>--kdf scrypt</code> (normalmente um arquivo de chaves importadas). Sem ele, o arquivo de chaves não pode ser desbloqueado para uso. ProxMenux persiste em forma criptografada no host para que os backups agendados possam ser executados sem um prompt interativo."
+        },
+        {
+          "id": "sobre-recuperacion",
+          "term": "Envelope de recuperação",
+          "def": "O <a href=\"#clave-cifrado\">ficheiro de chaves</a> protegido por uma camada adicional: é encriptado com a <a href=\"#passphrase-recuperacion\">frase-passe de recuperação</a> através de <a href=\"#aes-256-cbc\">AES-256-CBC</a> e <a href=\"#pbkdf2\">PBKDF2</a> antes de sair do host. É esta versão protegida que é enviada para o PBS no grupo <code>-keyrecovery</code>. Sem a frase-passe, o conteúdo permanece inacessível: descarregá-lo do PBS não revela o ficheiro de chaves."
+        },
+        {
+          "id": "cifrado-cliente",
+          "term": "Criptografia do lado do cliente",
+          "def": "Modelo de criptografia em que os dados são criptografados na máquina de origem antes de serem enviados. O PBS só recebe e armazena texto cifrado; nem mesmo um administrador PBS com acesso a datastore pode lê-lo sem o arquivo de chaves. O ProxMenux baseia-se neste modelo e adiciona o <a href=\"#sobre-recuperacion\">envelope de recuperação</a> no topo."
+        },
+        {
+          "id": "kdf-none",
+          "term": "--kdf none",
+          "def": "Opção para <code>proxmox-backup-client key create</code> que produz um arquivo de chaves sem senha anexada. O arquivo de chaves pode ser usado diretamente sem um prompt, o que é essencial para trabalhos agendados sem acompanhamento. Isto é o que o ProxMenux usa por padrão ao gerar um novo arquivo de chaves."
+        },
+        {
+          "id": "kdf-scrypt",
+          "term": "--kdf scrypt",
+          "def": "Opção para <code>proxmox-backup-client key create</code> que produz um arquivo de chaves protegido por uma <a href=\"#contrasena-keyfile\">frase-senha do arquivo de chave</a>. Cada uso do arquivo de chaves requer desbloqueá-lo com essa frase-passe. O ProxMenux aceita este estilo de arquivo de chaves na importação e armazena a frase-passe criptografada para que os backups agendados ainda possam ser executados sem acompanhamento."
+        },
+        {
+          "id": "aes-256-cbc",
+          "term": "AES-256-CBC",
+          "def": "Cifra simétrica padrão. ProxMenux usa-o (via <code>openssl enc -aes-256-cbc</code>) para embrulhar o <a href=\"#clave-cifrado\">keyfile</a> com a <a href=\"#passphrase-recuperacion\">frase-senha de recuperação</a> e produzir o <a href=\"#sobre-recuperacion\">envelope</a>."
+        },
+        {
+          "id": "pbkdf2",
+          "term": "PBKDF2",
+          "def": "Função criptográfica que transforma uma frase-passe tipo humano em uma chave binária adequada para criptografia. Atrasa as tentativas de força bruta aplicando muitas iterações. ProxMenux usa-o com iterações 600 000 e um sal aleatório ao criptografar o envelope de recuperação."
+        }
+      ]
+    },
+    {
+      "title": "Estrutura de backup",
+      "intro": "Termos que descrevem o que vive dentro de um backup, independentemente do destino.",
+      "entries": [
+        {
+          "id": "rootfs",
+          "term": "rootfs / sistema de ficheiros root",
+          "def": "Uma cópia plana do sistema de arquivos do host fonte, produzido pela <code>rsync</code> sobre o perfil <a href=\"#perfil-defecto\">default</a> mais qualquer caminho <a href=\"#rutas-personalizadas\">custom</a>. Não é uma imagem de disco inteiro: apenas caminhos que contêm configuração ou estado Proxmox não pode regenerar por conta própria são copiados."
+        },
+        {
+          "id": "manifiesto",
+          "term": "Manifesto (manifest.json)",
+          "def": "Documento estruturado JSON descrevendo o host fonte no momento do backup: hardware, armazenamento, kernel, componentes instalados ProxMenux e inventário de VMs e LXCs. É produzido por seis coletores de dados independentes. O fluxo de restauração usa-o para comparar fonte e alvo."
+        },
+        {
+          "id": "staging",
+          "term": "Diretório de preparação",
+          "def": "Diretório temporário onde ProxMenux monta os três blocos (rootfs, metadados e manifestos) antes de embalá-los e enviar para o destino. É removido automaticamente quando o backup termina, mesmo ao abortar."
+        },
+        {
+          "id": "perfil-defecto",
+          "term": "Perfil padrão",
+          "def": "Conjunto selecionado de caminhos copiados por padrão em cada backup: configuração PVE, rede, SSH, kernel, apt, ferramentas ProxMenux e outros. É definido no código e documentado na página <em>Como funciona</em>."
+        },
+        {
+          "id": "rutas-personalizadas",
+          "term": "Caminhos personalizados",
+          "def": "Caminhos extras que o usuário adiciona no topo do perfil <a href=\"#perfil-defecto\">default</a>. Persistente (armazenada em <code>backup-extra-paths.txt</code>) ou por execução (escolhida em modo Personalizado)."
+        }
+      ]
+    },
+    {
+      "title": "Destinos e armazenagem",
+      "intro": "Termos ligados ao local onde o backup chega — servidor PBS, arquivo local ou repositório Borg — e como o PBS organiza os dados.",
+      "entries": [
+        {
+          "id": "repositorio-pbs",
+          "term": "Repositório PBS",
+          "def": "Combinação de Proxmox Backup Server + <a href=\"#datastore\">datastore</a> + usuário que recebe o backup. Identificado pela string <code>user@realm@host:datastore</code>. Um único servidor PBS pode hospedar vários repositórios."
+        },
+        {
+          "id": "datastore",
+          "term": "Armazenamento de dados",
+          "def": "Armazenamento específico em um servidor PBS para backups e seus blocos. Cada datastore fica em um sistema de arquivos do servidor PBS e tem permissões e políticas próprias."
+        },
+        {
+          "id": "chunk",
+          "term": "Bloco (chunk) / desduplicação de blocos",
+          "def": "PBS divide cada backup em blocos de tamanho variável, identifica cada pedaço pelo seu hash e armazena cada pedaço apenas uma vez, mesmo que apareça em muitos backups diferentes. Isto significa que os backups sucessivos da mesma máquina — ou através de hosts semelhantes — ocupam muito pouco espaço adicional."
+        },
+        {
+          "id": "fingerprint",
+          "term": "Impressão digital",
+          "def": "Impressões digitais criptográficas do certificado PBS do servidor TLS. Permite ao cliente verificar se está a falar com o servidor pretendido sem depender de uma autoridade pública de certificação. ProxMenux passa para <code>proxmox-backup-client</code> através da variável de ambiente <code>PBS_FINGERPRINT</code>."
+        },
+        {
+          "id": "grupo-copia",
+          "term": "Grupo de backup",
+          "def": "Container lógico dentro do PBS sob o qual se acumulam sucessivos backups do mesmo ativo. Cada novo backup compartilha deduplicação com os anteriores no mesmo grupo. ProxMenux usa dois grupos por host quando a criptografia está habilitada: um para o backup do host e outro com um sufixo <code>-keyrecovery</code> para o <a href=\"#sobre-recuperacion\">envelope de recuperação</a>."
+        },
+        {
+          "id": "backup-id",
+          "term": "ID de backup",
+          "def": "Nome do <a href=\"#grupo-copia\">grupo de backup</a>. ProxMenux padrão para <code>hostcfg-HOSTNAME</code> e permite que o usuário editá-lo antes do upload; caracteres não suportados são despojados automaticamente."
+        },
+        {
+          "id": "pxar",
+          "term": ".pxar",
+          "def": "Formato de arquivo PBS-native para diretórios. Ele se comporta como um arquivo tar otimizado para desduplicação de blocos: ao invés de armazenar um arquivo opaco, PBS quebra seu conteúdo em pedaços reutilizáveis."
+        }
+      ]
+    },
+    {
+      "title": "Execução e agendamento",
+      "intro": "Termos usados pelo sistema ProxMenux-jobs programados.",
+      "entries": [
+        {
+          "id": "runner",
+          "term": "Executor",
+          "def": "O script <code>run_scheduled_backup.sh</code> que executa um backup agendado. Ele lê a configuração do trabalho, lança o backend correspondente (Local, PBS ou Borg), aplica retenção no sucesso e envia as notificações configuradas."
+        },
+        {
+          "id": "trabajo-programado",
+          "term": "Trabalho agendado",
+          "def": "Configuração persistente de uma cópia de segurança recorrente. Mantém o destino, credenciais, criptografia, programação e retenção. Vive em <code>/var/lib/proxmenux/backup-jobs/&lt;id&gt;.env</code>."
+        },
+        {
+          "id": "modo-adjunto",
+          "term": "Anexar modo",
+          "def": "Tarefa sem temporizador próprio. Um hook job-end PVE de <code>vzdump</code> a executa após os backups dos convidados quando o armazenamento coincide. A tarefa pai fornece destino e retenção inicial, mas o hook compara armazenamento, não ID pai. Outra tarefa no mesmo armazenamento também pode acioná-la. Somente Local e PBS."
+        },
+        {
+          "id": "timer-systemd",
+          "term": "Temporizador Systemd",
+          "def": "Mecanismo systemd padrão que dispara um comando em um calendário. ProxMenux cria um temporizador por <em>independente</em> trabalho programado; <a href=\"#modo-adjunto\">attach-mode</a> trabalhos não usam temporizador, eles rodam através do script-hook PVE."
+        },
+        {
+          "id": "retencion",
+          "term": "Retenção (keep-last, keep-daily…)",
+          "def": "Política que decide quais backups mais antigos manter e qual podar. Definido por trabalho com parâmetros como <code>keep-last</code>, <code>keep-daily</code>, <code>keep-weekly</code>, <code>keep-monthly</code>. Aplicado pelo executor após cada backup bem sucedido."
+        }
+      ]
+    },
+    {
+      "title": "Restaurar",
+      "intro": "Termos do fluxo de restauração.",
+      "entries": [
+        {
+          "id": "restauracion-universal",
+          "term": "Restauração universal",
+          "def": "O fluxo de restauração ProxMenux não apenas extrai o sistema de arquivos: ele lê o manifesto para detectar diferenças entre fonte e alvo, reproduz a configuração do sistema e executa novamente os instaladores para os componentes gerenciados ProxMenux. O objetivo é reproduzir o host de origem, não apenas o arquivo."
+        },
+        {
+          "id": "hidratacion",
+          "term": "Hidratação entre versões do kernel",
+          "def": "Etapa de restauração que combina as configurações do usuário na origem (parâmetros IOMMU, IDs VFIO, ajustes específicos e chaves GRUB) com a configuração nova de inicialização do destino, sem copiar literalmente arquivos ligados ao kernel de origem. Executa quando o kernel de destino é mais novo que o do backup."
+        },
+        {
+          "id": "cross-kernel",
+          "term": "Restauração do kernel cruzado",
+          "def": "Restaurar onde o kernel do alvo difere (normalmente é mais novo do que) da fonte. Requer o passe <a href=\"#hidratacion\">hydration</a> para evitar arrastar arquivos incompatíveis com o kernel do alvo."
+        },
+        {
+          "id": "instalador-postboot",
+          "term": "Instalador pós-inicial",
+          "def": "Componentes reinstalados após a primeira inicialização do host restaurado ( drivers NVIDIA, drivers Coral TPU, ferramentas AMD GPU, ferramentas Intel GPU). Cada instalador corre contra o kernel do alvo, então o host restaurado não depende do kernel da fonte estar presente."
+        },
+        {
+          "id": "compatibility-check",
+          "term": "Verificação de compatibilidade",
+          "def": "Comparação entre o manifesto da fonte e o estado do alvo que o ProxMenux realiza no início da restauração. Ele decide quais partes são copiadas verbatim, que precisam de hidratação e que são recriadas por um instalador."
+        },
+        {
+          "id": "equipo-recien-instalado",
+          "term": "Instalação fresca",
+          "def": "Host recém-reinstalado do zero, sem <a href=\"#clave-cifrado\">arquivo de chave</a> local. Para restaurar um backup criptografado, primeiro recupere a chave do <a href=\"#sobre-recuperacion\">envelope</a> armazenado no PBS usando a <a href=\"#passphrase-recuperacion\">frase-senha de recuperação</a>."
+        }
+      ]
+    }
+  ],
+  "whereNext": {
+    "heading": "Onde se segue",
+    "items": [
+      {
+        "label": "Como funciona",
+        "href": "/docs/backup-restore/how-it-works",
+        "tail": " — quando o rootfs, o manifesto e o inventário da aplicação se encaixam num backup."
+      },
+      {
+        "label": "Destino Proxmox Backup Server",
+        "href": "/docs/backup-restore/destinations/pbs",
+        "tail": " — quando a criptografia do lado do cliente, o arquivo de chaves, a frase-passe de recuperação e o envelope são documentados em profundidade."
+      },
+      {
+        "label": "Restauração",
+        "href": "/docs/backup-restore/restoring",
+        "tail": " — fluxo de restauração e uso do manifesto."
+      }
+    ]
+  }
+}

web/messages/pt/docs/backup-restore/how-it-works.json

@@ -0,0 +1,205 @@
+{
+  "meta": {
+    "title": "Como o backup ProxMenux funciona internamente — rootfs, manifestos, aplicativos",
+    "description": "Descrição detalhada do que um backup ProxMenux contém: os rootfs produzidos pelo rsync do perfil de caminho padrão, o manifesto estruturado construído por seis coletores independentes e o inventário de aplicativos que impulsiona a reinstalação automática de pacotes e componentes após uma restauração.",
+    "ogTitle": "Como o backup ProxMenux funciona internamente",
+    "ogDescription": "Os três blocos de um backup ProxMenux: rootfs, manifesto e aplicativos.",
+    "twitterTitle": "Como funcionam as cópias de segurança ProxMenux | ProxMenux",
+    "twitterDescription": "As três cargas de um backup ProxMenux e como a restauração reproduz o host fonte deles."
+  },
+  "header": {
+    "title": "Como funciona",
+    "description": "A estrutura interna de um backup ProxMenux — sistema de arquivos, manifesto e inventário de aplicativos — e como a restauração usa os três para reproduzir o host de origem em um destino que pode ter outro kernel.",
+    "section": "Cópias de segurança e restauro"
+  },
+  "intro": {
+    "title": "Um arquivo, três blocos",
+    "body": "Cada backup cria três blocos bem definidos em um único diretório de preparação. O arquivo enviado ao destino (<code>.tar.zst</code> local, backup PBS ou arquivo Borg) mantém essa estrutura. A restauração usa os três: <strong>o manifesto</strong> é consultado antes das alterações para detectar diferenças e decidir o que excluir; <strong>rootfs</strong> fornece os arquivos de configuração, aplicados em execução ou após reiniciar; <strong>o inventário de aplicativos</strong> orienta a instalação de pacotes e a reinstalação de componentes após o boot. Cada bloco pode ser inspecionado ou extraído separadamente."
+  },
+  "layout": {
+    "heading": "Disposição do arquivo",
+    "intro": "Cada arquivo segue o mesmo layout de árvore, independentemente do destino. O subdiretório <code>metadata/</code> contém as cargas estruturadas; o subdiretório <code>rootfs/</code> contém a cópia do sistema de arquivos.",
+    "treeCaption": "O diretório de preparação criado durante o backup. Todos os destinos recebem a mesma árvore no formato nativo: tar para backups locais, blocos PBS para PBS e segmentos Borg para Borg.",
+    "tree": "backup-[timestamp]/\n├── manifest.json                  # structured host state\n├── metadata/\n│   ├── packages.manual.list       # apt-mark showmanual\n│   ├── run_info.env               # backup run identity + kernel version + pmxcfs method\n│   ├── paths_archived.txt         # exact list of paths that reached rootfs/\n│   └── missing_paths.txt          # paths from the profile absent on source\n└── rootfs/\n    ├── etc/                       # /etc/pve, /etc/network, /etc/systemd/network, /etc/ssh, …\n    ├── root/                      # /root (with volatile subdirs excluded)\n    ├── usr/local/                 # /usr/local/bin, /usr/local/share/proxmenux, …\n    └── var/                       # /var/lib/pve-cluster (config.db via sqlite3 .backup), /var/spool/cron/…"
+  },
+  "rootfs": {
+    "heading": "A carga útil do rootfs",
+    "intro": "A árvore <code>rootfs/</code> é uma <strong>cópia simples do sistema de arquivos</strong> criada pelo <code>rsync</code> a partir do host de origem. Contém um <strong>perfil padrão</strong> de caminhos selecionados para restaurar o Proxmox e os <strong>caminhos personalizados</strong> adicionados à tarefa ou sessão interativa. A seleção é intencionalmente restrita a caminhos que <em>guardam configuração</em> ou <em>guardam um estado que o Proxmox não consegue recriar sozinho</em>.",
+    "defaultProfileTitle": "O perfil por omissão",
+    "defaultProfileBody": "O perfil padrão é definido por <code>hb_default_profile_paths</code> em <code>lib_host_backup_common.sh</code>. Abrange oito categorias fixas e, quando necessário, o estado ZFS, que juntas descrevem um host Proxmox funcional:",
+    "categoriesTitle": "Categorias de localização",
+    "categoryRows": [
+      {
+        "category": "Núcleo PVE",
+        "paths": "/etc/pve, /var/lib/pve-cluster, /etc/vzdump.conf",
+        "why": "Conteúdo do sistema de ficheiros de cluster e valores por omissão do vzdump. O banco de dados pmxcfs (<code>config.db</code>) é capturado como um instantâneo consistente via <code>sqlite3 .backup</code> sem parar o cluster, e os sidecars <code>.db-wal</code> / <code>.db-shm</code> são excluídos do rsync. Quando o <code>sqlite3</code> não está disponível, é criado <code>config.db.raw-fallback</code>, que a restauração usa automaticamente como banco de dados."
+      },
+      {
+        "category": "Identidade do host e rede",
+        "paths": "/etc/hostname, /etc/hosts, /etc/timezone, /etc/resolv.conf, /etc/network, /etc/systemd/network",
+        "why": "Tudo que o host precisa para entrar na rede com a mesma identidade. Os arquivos <code>.link</code> em <code>/etc/systemd/network</code> fixam nomes de NIC em seus MAC, portanto, reinstalações e alterações de hardware não renomeiam interfaces."
+      },
+      {
+        "category": "Acesso e autenticação",
+        "paths": "/etc/ssh, /etc/sudoers, /etc/sudoers.d, /etc/pam.d, /etc/security",
+        "why": "SSH chaves, regras de sudo e configuração PAM. Perder estas trava o usuário fora da máquina restaurada."
+      },
+      {
+        "category": "Kernel e inicialização",
+        "paths": "/etc/default/grub, /etc/kernel, /etc/modules, /etc/modules-load.d, /etc/modprobe.d, /etc/sysctl.conf, /etc/sysctl.d, /etc/udev/rules.d, /etc/fstab, /etc/iscsi, /etc/multipath",
+        "why": "Tokens IOMMU, lista negra do módulo, IDs do dispositivo VFIO, tabela de montagem, configuração da pilha de armazenamento."
+      },
+      {
+        "category": "Shell e definições regionais",
+        "paths": "/etc/environment, /etc/bash.bashrc, /etc/inputrc, /etc/profile, /etc/profile.d, /etc/locale.gen, /etc/locale.conf",
+        "why": "Configuração do shell, variáveis de ambiente, configuração de geração local."
+      },
+      {
+        "category": "Gerenciamento de pacotes e cron",
+        "paths": "/etc/apt, /etc/cron.d, /etc/cron.{daily,hourly,weekly,monthly}, /etc/cron.allow, /etc/cron.deny, /var/spool/cron/crontabs",
+        "why": "Fontes APT para resolução consistente de pacotes, tarefas agendadas definidas pelo usuário."
+      },
+      {
+        "category": "Estado e ferramentas do ProxMenux",
+        "paths": "/etc/proxmenux, /etc/systemd/system, /etc/log2ram.conf, /etc/logrotate.conf, /etc/logrotate.d, /etc/lm-sensors, /etc/sensors3.conf, /etc/fail2ban, /etc/snmp, /etc/postfix, /etc/wireguard, /etc/openvpn, /etc/grafana, /etc/influxdb, /etc/prometheus, /etc/telegraf, /etc/zabbix",
+        "why": "Ferramentas opcionais, mas comuns Proxmox. Caminhos ausentes são observados em <code>metadata/missing_paths.txt</code> sem parar o backup."
+      },
+      {
+        "category": "Binários & root do ProxMenux",
+        "paths": "/usr/local/bin, /usr/local/sbin, /usr/local/share/proxmenux, /var/lib/proxmenux, /root (subdires voláteis excluídos)",
+        "why": "Binários instalados em ProxMenux e configuração por usuário sob <code>/root</code>. Os caminhos voláteis (<code>.bash_history</code>, <code>.cache/</code>, <code>tmp/</code>, <code>.local/share/Trash/</code>) são excluídos da cópia. O <code>/var/lib/proxmenux</code> mantém as tarefas de backup programadas e o estado de host mantido pelo ProxMenux; o estadiamento da restauração, as cópias de rollback e os marcadores pós-restore são excluídos, porque pertencem ao host que executa uma restauração."
+      },
+      {
+        "category": "Estado ZFS (condicional)",
+        "paths": "/etc/zfs",
+        "why": "Apenas incluído quando o host de origem roda ZFS. Contém <code>zpool.cache</code> e <code>hostid</code>."
+      }
+    ],
+    "customTitle": "Estendendo o perfil com caminhos personalizados",
+    "customBody": "Além do perfil padrão, o ProxMenux oferece duas maneiras de incluir caminhos adicionais em um backup. Eles compõem sem conflito e ambos se aplicam a backups interativos e trabalhos agendados.",
+    "customExtrasTitle": "1. Extras persistentes (por máquina)",
+    "customExtrasBody": "Um arquivo de texto no <code>/usr/local/share/proxmenux/backup-extra-paths.txt</code> contém uma lista de caminhos absolutos que o usuário marcou como \"incluir sempre\" nesta máquina. Quando um backup é executado no modo <strong>Default</strong>, o ProxMenux adiciona esses caminhos ao perfil padrão automaticamente sem perguntar. O arquivo é editado a partir da interface — nenhuma edição manual necessária — e persiste através de reiniciais e atualizações. Um caminho absoluto por linha; <code>#</code> comentários são permitidos.",
+    "customModeTitle": "2. Modo personalizado (por execução)",
+    "customModeBody": "O lançamento de um backup no modo <strong>Custom</strong> substitui a aplicação automática do perfil padrão por uma lista de verificação mostrando todos os caminhos: as entradas de perfil padrão e os extras persistentes (prefixados com <code>[+]</code> e pré-selecionados). O usuário seleciona ou desmarca entradas para essa execução específica, e também pode pressionar <em>Adicionar caminho personalizado</em> para inserir um novo caminho — que é então persistido para o arquivo extras para backups futuros.",
+    "customMissingTitle": "Caminhos ausentes da fonte",
+    "customMissingBody": "Qualquer caminho do perfil (padrão ou adicionado) que não exista no host fonte é gravado em <code>metadata/missing_paths.txt</code> dentro do arquivo. O backup não falha nem para — o usuário vê um resumo de caminhos arquivados e caminhos faltando no final. Na prática, isso acontece para caminhos de ferramentas opcionais como <code>/etc/wireguard</code> ou <code>/etc/prometheus</code> quando essas ferramentas não estão instaladas."
+  },
+  "manifest": {
+    "heading": "O bloco do manifesto",
+    "intro": "<code>manifest.json</code> é um documento JSON estruturado que descreve o host de origem no momento do backup. É produzido por <strong>seis coletores independentes</strong> orquestrados por <code>build_manifest.sh</code>. Cada coletor é somente leitura, produz um fragmento JSON bem definido, e cai de volta para um padrão vazio seguro se falhar — o manifesto ainda é utilizável se uma seção estiver incompleta.",
+    "orchestratorCaption": "Os seis coletores compõem o manifesto. Cada colecionador corre em seu próprio subprocesso; uma falha em um cai de volta para um padrão seguro documentado e avisa, mas não aborta o backup.",
+    "collectorRows": [
+      {
+        "collector": "collect_source_host.sh",
+        "produces": "source_host",
+        "content": "Hostname, versão PVE (<code>pveversion</code>), versão PBS se o host executar o papel do servidor de backup, kernel (<code>uname -r</code>), modo de inicialização (efi/bios), tipo de sistema de arquivos raiz, modelo CPU + arquitetura, memória em KB."
+      },
+      {
+        "collector": "collect_hardware.sh",
+        "produces": "hardware_inventory",
+        "content": "GPUs (com o mapeamento do instalador do fornecedor e ProxMenux), TPUs (Coral USB + M.2 com detecção de <code>lsusb</code>/<code>lspci</code>), NICs (com a associação MAC, slot PCI e ponte), dispositivos sem fio. As entradas GPU têm uma heurística <code>passthrough_eligible</code>."
+      },
+      {
+        "collector": "collect_storage.sh",
+        "produces": "storage_inventory",
+        "content": "ZFS pools (com pool disco do tipo + membro resolvido para <code>/dev/disk/by-id/*</code>, <code>/dev/disk/by-partuuid/*</code> ou em bruto <code>/dev/sdX</code> caminhos dependendo de como cada pool foi originalmente criado), LVM grupos de volume + finos pools, discos físicos com SMART capacidade, PVE <code>storage.cfg</code> entradas, montagens externas."
+      },
+      {
+        "collector": "collect_kernel.sh",
+        "produces": "kernel_params",
+        "content": "Parâmetros adicionados pelo operador em <code>/proc/cmdline</code>, sem os itens padrão como <code>BOOT_IMAGE=</code>, <code>root=</code>, <code>ro/rw</code>, <code>quiet</code> e <code>splash</code>; módulos carregados na inicialização de <code>/etc/modules</code>; caminhos dos arquivos <code>/etc/modprobe.d/*.conf</code> com diretivas efetivas (<code>options</code>, <code>blacklist</code>, <code>install</code>, <code>alias</code>, <code>softdep</code>)."
+      },
+      {
+        "collector": "collect_proxmenux_state.sh",
+        "produces": "proxmenux_installed_components",
+        "content": "Lê <code>/usr/local/share/proxmenux/managed_installs.json</code> (registo de tudo que ProxMenux instalou) e <code>installed_tools.json</code>. Cada entrada mantém o caminho do instalador (<code>menu_script</code>) para que a restauração possa desencadear o mesmo fluxo de instalação."
+      },
+      {
+        "collector": "collect_guests.sh",
+        "produces": "vms_lxcs_at_backup",
+        "content": "Enumera VMs (<code>qm list</code>) e LXCs (<code>pct list</code>) presentes na hora de backup — VMID, nome, estado atual. Apenas o inventário: os dados reais dos hóspedes são da responsabilidade do <code>vzdump</code> / PBS."
+      }
+    ],
+    "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."
+  },
+  "applications": {
+    "heading": "O inventário de aplicativos",
+    "intro": "Dois inventários catalogam o software acrescentado aos pacotes básicos do Proxmox VE: a lista de pacotes em <code>metadata/</code> e o registro de componentes em rootfs, detalhados abaixo. A restauração usa APT ou os instaladores do ProxMenux para reproduzir o software do usuário conforme o método original de instalação.",
+    "packagesTitle": "packages.manual.list",
+    "packagesBody": "Uma lista alfabética em texto simples produzida por <code>apt-mark showmanual</code> com os pacotes APT <em>instalados explicitamente</em> no host de origem. As dependências do sistema Proxmox VE básico são excluídas; o APT do destino as instala automaticamente. Durante a restauração, <code>_rs_run_complete_extras</code> lê a lista e aplica um <em>filtro contra remoções em cascata</em> em três etapas: <code>dpkg -s</code> identifica pacotes já instalados, outras versões principais de bibliotecas são detectadas e <code>apt-get install --simulate</code> verifica o risco de remoções em cascata. Os pacotes restantes são instalados com <code>apt-get install -y</code>.",
+    "componentsTitle": "components_status.json (parte dos rootfs)",
+    "componentsBody": "Um registro JSON sob <code>/usr/local/share/proxmenux/</code> que registra cada componente ProxMenux instalou com seu estado exato: versão, bandeiras ProxMenux específicas (para NVIDIA: <code>patched</code> booleano; para Coral: versão DKMS). Este arquivo vive dentro dos rootfs — não em <code>metadata/</code> — porque é <em>lido depois</em> que rootfs foi copiado para o alvo. O expedidor pós-boot (<code>apply_cluster_postboot.sh</code>) itera sobre suas entradas e executa o gancho <code>--auto-reinstall</code> de cada componente, que lê o estado gravado e reproduz a instalação contra o kernel atual do alvo.",
+    "componentInstallersTitle": "Instaladores de componentes",
+    "componentInstallersBody": "Quatro instaladores ProxMenux atualmente expõem um ponto de entrada <code>--auto-reinstall</code>:",
+    "installerRows": [
+      {
+        "component": "nvidia_driver",
+        "installer": "gpu_tpu/nvidia_installer.sh",
+        "action": "Lê-se <code>version</code> + <code>patched</code>. Transfere exatamente o mesmo arquivo de execução NVIDIA, constrói módulos DKMS contra o kernel do alvo, reaplica o patch ProxMenux se a fonte o tiver."
+      },
+      {
+        "component": "coral_driver",
+        "installer": "gpu_tpu/install_coral.sh",
+        "action": "Lê a versão do driver Coral. Compila o módulo DKMS contra o kernel do alvo."
+      },
+      {
+        "component": "amdgpu_top",
+        "installer": "gpu_tpu/amd_gpu_tools.sh",
+        "action": "Lê a versão gravada. Baixa novamente o <code>.deb</code> exato da versão GitHub."
+      },
+      {
+        "component": "intel_gpu_tools",
+        "installer": "gpu_tpu/intel_gpu_tools.sh",
+        "action": "O APT instala o pacote. Idempotente se já presente de <code>packages.manual.list</code>."
+      }
+    ]
+  },
+  "restoreFlow": {
+    "heading": "Como a restauração consome as três cargas",
+    "intro": "A restauração é um processo de seis etapas. Cada etapa lê um subconjunto específico do arquivo e atualiza o host alvo. Nenhuma etapa requer que o host de origem seja acessível — o arquivo é totalmente auto-suficiente.",
+    "stagesCaption": "Estágio 1 usa o manifesto para decidir o que tocar. Estágio 2 copia rootfs caminhos que são seguros para aplicar em um sistema em execução. O estágio 3 encena os caminhos arriscados para a próxima inicialização. Fase 3b importa conjuntos de dados ZFS não-root cujos discos estão todos presentes. Estágio 4 lida com pacotes. O estágio 5 é executado após a reinicialização e reinstala componentes contra o kernel do alvo.",
+    "stageRows": [
+      {
+        "stage": "1",
+        "name": "Verificação de compatibilidade",
+        "reads": "manifest.json",
+        "action": "Corre <code>hb_compat_check</code>. Compara hardware fonte vs. alvo (NICs, IDs de armazenamento), versão PVE e versão principal do kernel. Define <code>HB_COMPAT_KERNEL_DIRECTION</code> (<code>same</code>, <code>bk_newer</code> ou <code>bk_older</code>) e povoa <code>RS_SKIP_PATHS</code> com exclusões de hardware-drift e cross-kernel."
+      },
+      {
+        "stage": "2",
+        "name": "Aplicação em execução",
+        "reads": "rootfs/ (somente caminhos seguros)",
+        "action": "<code>_rs_apply … hot</code> copia entradas <code>hb_classify_path</code>=<code>hot</code> diretamente para o alvo ao vivo. Qualquer coisa sob <code>/etc/pve</code>, <code>/etc/network</code> ou caminhos classificados como <em>reboot</em>/<em>dangerous</em> é adiada."
+      },
+      {
+        "stage": "3",
+        "name": "Preparações pendentes",
+        "reads": "rootfs/ (reboot + caminhos perigosos)",
+        "action": "<code>_rs_prepare_pending_restore</code> prepara os caminhos de risco em <code>/var/lib/proxmenux/pending-restore/</code>, grava <code>plan.env</code>, <code>apply-on-boot.list</code> e <code>rs-skip-paths.txt</code> e ativa <code>proxmenux-restore-onboot.service</code> para a próxima inicialização."
+      },
+      {
+        "stage": "3b",
+        "name": "Importação de pools de dados",
+        "reads": "manifest.storage_inventory + estado ZFS do destino",
+        "action": "<code>_rs_import_data_pools</code> tenta importar cada pool ZFS que não contém a raiz e tem todos os discos presentes no destino. Com hostid de outro host, tenta novamente com <code>zpool import -f</code>. Se faltar um disco, o pool é ignorado com aviso. O resultado por pool é registrado em <code>/var/log/proxmenux/restore-datapools-&lt;timestamp&gt;.log</code>."
+      },
+      {
+        "stage": "4",
+        "name": "Instalar pacote",
+        "reads": "metadata/packages.manual.list",
+        "action": "<code>_rs_run_complete_extras</code> executa o filtro de segurança em cascata e chama <code>apt-get install -y</code> com a lista de pacotes sobreviventes. Saída completa vai para <code>/var/log/proxmenux/restore-apt-*.log</code>."
+      },
+      {
+        "stage": "5",
+        "name": "Após o arranque",
+        "reads": "rootfs (já aplicado) + components_status.json",
+        "action": "Após reiniciar, <code>apply_pending_restore.sh</code> reproduz os caminhos diferidos e <code>apply_cluster_postboot.sh</code> executa <code>update-initramfs</code>, <code>update-grub</code> (ou <code>proxmox-boot-tool refresh</code>) e itera sobre <code>components_status.json</code> disparando o gancho <code>--auto-reinstall</code> de cada componente."
+      }
+    ]
+  },
+  "whyItWorks": {
+    "heading": "Por que dividir o backup em três blocos",
+    "body": "A divisão segue o <strong>ciclo de vida</strong> dos dados. O sistema de arquivos é transferido com <code>rsync</code>: rápido, transparente e atômico por arquivo. O estado de configuração a interpretar antes das alterações é <strong>JSON estruturado</strong>, legível separadamente, versionável por esquema e comparável automaticamente com o estado do destino. O software a reinstalar é descrito em um <strong>inventário</strong> de nomes e versões; o gerenciador de pacotes e os instaladores do ProxMenux escolhem os binários adequados. Cada bloco atende ao próprio objetivo. Juntos, buscam uma restauração coerente com tolerância a falhas: um manifesto corrompido deixa rootfs recuperável, um pacote ausente não impede instalar componentes e uma falha em uma entrada não interrompe a seguinte."
+  }
+}

web/messages/pt/docs/backup-restore/index.json

@@ -0,0 +1,93 @@
+{
+  "meta": {
+    "title": "ProxMenux Backup e restauração — Visão geral | Backup e restauração completos do host para Proxmox VE",
+    "description": "ProxMenux Backup & Restore captura o estado completo de um host Proxmox – sistema de arquivos, manifesto de configuração estruturado e pacotes/componentes instalados – e o reproduz no mesmo host ou em um host diferente. O backup e a restauração são independentes: não há dependências externas e as restaurações entre kernels são suportadas por meio de um filtro de subconjunto seguro com reconhecimento de direção e hidratação independente do kernel.",
+    "ogTitle": "ProxMenux Backup e restauração — Visão geral",
+    "ogDescription": "Backup e restauração completos do host para Proxmox VE com manifesto estruturado, lista de pacotes e reinstaladores de componentes.",
+    "twitterTitle": "ProxMenux Backup e restauração | ProxMenux",
+    "twitterDescription": "Backup e restauração completos do host para Proxmox VE com manifesto estruturado, lista de pacotes e reinstaladores de componentes."
+  },
+  "header": {
+    "title": "Backup e restauração",
+    "description": "Backup e restauração de host completo para Proxmox VE. Captura o sistema de arquivos, a configuração e os componentes instalados em um único arquivo e reproduz o host na mesma instalação do Proxmox ou em uma instalação diferente, sem dependências externas.",
+    "section": "Backup e restauração"
+  },
+  "intro": {
+    "title": "O que é, em um parágrafo",
+    "body": "Uma cópia do ProxMenux guarda o estado completo de um host Proxmox: <strong>o sistema de ficheiros</strong>, com os diretórios relevantes em <code>/etc</code>, <code>/root</code> e <code>/var/lib/pve-cluster</code> e os caminhos personalizados opcionais; <strong>um manifesto estruturado</strong> em JSON com o hardware detetado, parâmetros do kernel, configuração de rede, estado do ZFS, utilizadores e entradas cron; e <strong>um inventário de aplicações</strong>, com os pacotes que o APT marca como instalados manualmente e os componentes instalados pelo ProxMenux, incluindo as versões exatas. Os três destinos suportados — arquivo local, Proxmox Backup Server (recomendado) e Borg — recebem o mesmo conteúdo autónomo. Qualquer um permite reconstruir o host de destino sem que o host de origem tenha de estar acessível durante o restauro."
+  },
+  "video": {
+    "heading": "Vídeo passo a passo",
+    "intro": "Prefere assistir o Backup e Restauração em ação antes de configurá-lo? Este passo a passo abrange uma demonstração completa do recurso em ProxMenux.",
+    "title": "ProxMenux — Passo a passo sobre backup e restauração",
+    "caption": "Vídeo externo em YouTube. Reproduz no modo de privacidade aprimorada (sem cookies até você apertar play)."
+  },
+  "whatItIsNot": {
+    "heading": "O que não é",
+    "intro": "Esta secção abrange a cópia de segurança e o restauro <strong>do host</strong>: a instalação do Proxmox, não as aplicações e os sistemas convidados que nela são executados.",
+    "items": [
+      "<strong>Não é uma ferramenta de backup de VM/CT.</strong> Esta funcionalidade não guarda os discos nem o estado da RAM dos sistemas convidados; essa é a função do <code>vzdump</code>. Os <strong>ficheiros de configuração</strong> dos convidados (<code>/etc/pve/nodes/&lt;node&gt;/qemu-server/*.conf</code> e <code>lxc/*.conf</code>) <strong>são</strong> guardados. Após o restauro, o inventário reaparece e os discos podem ser restaurados ou associados a partir de um backup existente no PBS ou em armazenamento local.",
+      "<strong>Não é uma operação sobre todo o cluster.</strong> Cada nó cria a sua própria cópia. A pertença ao cluster é guardada em <code>/etc/pve</code> para permitir reintegrar um nó restaurado, mas recuperar todo o cluster exige coordenar o restauro dos vários nós.",
+      "<strong>Não é uma imagem completa do disco.</strong> Os binários do kernel, o initramfs e a partição de arranque não são guardados. Durante o restauro, o ProxMenux utiliza os ficheiros de arranque do host de destino, regenerados automaticamente por <code>update-initramfs</code> e pela ferramenta do gestor de arranque, e instala os controladores adequados ao kernel em execução no destino."
+    ]
+  },
+  "threePillars": {
+    "heading": "Os três pilares de um backup",
+    "intro": "Um arquivo ProxMenux é estruturado em torno de três cargas independentes. A restauração usa as três em conjunto para reproduzir o host de origem em um destino que pode nem ter o mesmo kernel instalado.",
+    "diagramCaption": "Cada backup envia as mesmas três cargas, independentemente do destino. A restauração consome todos os três: rootfs para estabelecer arquivos, manifesto para detectar desvios e diferenças entre kernels e inventário de aplicativos para reinstalar pacotes e componentes no próprio kernel do destino.",
+    "pillar1Label": "Sistema de ficheiros",
+    "pillar1Detail": "rootfs/\n(rsync de /etc,\n/etc/systemd/network,\n/root, mais um\ninstantâneo sqlite3\nde /var/lib/pve-cluster,\n+ caminhos opcionais)",
+    "pillar2Label": "Manifesto",
+    "pillar2Detail": "manifest.json\n(hardware, parâmetros\ndo kernel, rede,\nZFS, usuários, cron,\npools ZFS, armazenamento)",
+    "pillar3Label": "Aplicativos",
+    "pillar3Detail": "packages.manual.list\n+ components_status.json\n(pacotes APT manuais + instaladores\nProxMenux com versões)"
+  },
+  "restoreIsUniversal": {
+    "heading": "A restauração reproduz o host de origem, não o arquivo",
+    "body": "A restauração de um backup ProxMenux não extrai apenas o sistema de arquivos. O fluxo de restauração lê o manifesto para detectar desvios entre a origem e o destino (diferenças de hardware, renomeações de NIC, versão do kernel, identidade do pool ZFS), reproduz o sistema de arquivos e aciona o instalador de componente correto para cada serviço que foi instalado na origem (driver NVIDIA, Coral TPU, ferramentas de GPU AMD, ferramentas Intel GPU). Cada instalador é executado no <strong>kernel atual do destino</strong>, portanto, o host restaurado não depende da presença do kernel da origem. Quando o kernel do destino é mais recente que o do backup, um passo de <strong>hidratação</strong> independente do kernel mescla o próprio ajuste do usuário (tokens IOMMU, IDs de dispositivos VFIO, peculiaridades personalizadas, chaves GRUB) na nova configuração de inicialização do destino sem copiar arquivos vinculados ao kernel literalmente."
+  },
+  "twoInterfaces": {
+    "heading": "Duas interfaces, um back-end",
+    "intro": "Cada etapa do fluxo de trabalho de backup e restauração está disponível em dois pontos de entrada. Ambos chamam a mesma biblioteca shell, produzem arquivos idênticos e leem o mesmo registro de tarefas.",
+    "cliLabel": "ProxMenux Scripts (TUI)",
+    "cliDetail": "menu → Utilitários →\nBackup/restauração de host\n\nFluxo baseado em diálogo,\nSSH amigável, programável\npara uso não supervisionado.",
+    "webLabel": "ProxMenux Monitor (Web UI)",
+    "webDetail": "Aba Backups na\ninterface web do Monitor.\n\nRestauração com um clique,\nacompanhamento dos logs ao vivo,\nintegração com notificações e o\nvisualizador de diferenças da reversão."
+  },
+  "whereNext": {
+    "heading": "Para onde ir a partir daqui",
+    "intro": "Cada subseção abaixo aborda detalhadamente um aspecto do fluxo de trabalho. Comece com <em>Como funciona</em> se o objetivo é entender o que o arquivo contém e por quê. Vá para <em>Destinos</em> para configurar o destino da cópia. Leia <em>Restauração</em> e <em>Restauração entre kernels</em> para o lado da recuperação.",
+    "items": [
+      {
+        "label": "Como funciona",
+        "href": "/docs/backup-restore/how-it-works",
+        "tail": "— os três payloads (rootfs, manifesto, aplicações) em detalhes, com os coletores que os produzem e o formato de cada arquivo."
+      },
+      {
+        "label": "Destinos",
+        "href": "/docs/backup-restore/destinations",
+        "tail": "— comparação entre local, Proxmox Backup Server (recomendado) e Borg, e como configurar cada um."
+      },
+      {
+        "label": "Criando backups",
+        "href": "/docs/backup-restore/creating-backups",
+        "tail": "— backups únicos, perfil de caminho padrão, adição de caminhos personalizados, criptografia para PBS."
+      },
+      {
+        "label": "Trabalhos agendados",
+        "href": "/docs/backup-restore/scheduled-jobs",
+        "tail": "— novos trabalhos versus anexação a um trabalho PVE vzdump existente, formatos de agendamento, modal de detalhes do trabalho."
+      },
+      {
+        "label": "Restauração",
+        "href": "/docs/backup-restore/restoring",
+        "tail": "— as três ações em um arquivo (visualizar, baixar, restaurar), restauração completa versus restauração personalizada, o despachante pós-inicialização e por que os últimos dez minutos são importantes."
+      },
+      {
+        "label": "Restauração entre kernels",
+        "href": "/docs/backup-restore/cross-kernel",
+        "tail": " — comportamento que considera a direção da mudança de versão quando o kernel do destino difere do kernel do backup, filtro de subconjunto seguro e quatro fases de hidratação."
+      }
+    ]
+  }
+}

web/messages/pt/docs/backup-restore/scheduled-jobs.json

@@ -0,0 +1,152 @@
+{
+  "meta": {
+    "title": "Trabalhos agendados — temporizadores, modo de anexação, retenção ProxMenux",
+    "description": "Trabalhos de backup programados do host ProxMenux. Dois modos de criação (horário systemd próprio ou anexar a um trabalho existente PVE vzdump), valores de retenção aplicados por trabalho via proxmox-backup-client/borg/local prune, layout de armazenamento sob /var/lib/proxmenux/backup-jobs, e o script de execução que produz arquivos idênticos ao fluxo interativo.",
+    "ogTitle": "Cópia de segurança ProxMenux — tarefas agendadas",
+    "ogDescription": "Backups de host agendados não vigiados com modo de anexação, retenção e os mesmos três destinos do fluxo interativo.",
+    "twitterTitle": "Trabalhos agendados | ProxMenux",
+    "twitterDescription": "Trabalhos de backup agendados sem acompanhamento com modo de anexação e retenção."
+  },
+  "header": {
+    "title": "Trabalhos agendados",
+    "description": "Trabalhos de backup da máquina não vigiados. Dois modelos de criação: um novo trabalho independente com sua própria programação, ou um trabalho anexado a uma tarefa existente PVE vzdump que herda o cronograma e retenção dessa tarefa. Ambos produzem arquivos idênticos ao fluxo interativo.",
+    "section": "Cópias de segurança e restauro"
+  },
+  "intro": {
+    "title": "Os dois modelos de trabalho programados",
+    "body": "Um trabalho programado pode ser criado seguindo um dos dois modelos:",
+    "modelsList": [
+      "<strong>Novo trabalho independente</strong> — ProxMenux define o horário de trabalho com seu próprio temporizador systemd, independente de qualquer outra tarefa no host. Compatível com os três destinos: Local, PBS e Borg.",
+      "<strong>Anexar a uma tarefa existente PVE vzdump</strong> — o trabalho não tem agendamento próprio; ele é executado automaticamente sempre que a tarefa pai PVE vzdump que já faz backup das VMs e LXCs nesta máquina dispara. Herda a programação e a retenção da tarefa dos pais. Compatível com Local e PBS (Borg não é suportado porque PVE não tem agendador nativo para Borg)."
+    ]
+  },
+  "attachBadge": {
+    "title": "Modo de anexação — recomendado quando já existe uma tarefa PVE vzdump",
+    "body": "Se já existe uma tarefa vzdump PVE para as VMs e LXCs do nó, anexar o backup do host faz com que ele seja executado depois do backup dos convidados, no <strong>mesmo ciclo de backup</strong>. Na restauração, as configurações dos convidados vêm do backup do host (em <code>/etc/pve</code>) e os discos vêm dos backups vzdump desse ciclo. Isso ajuda a coordenar a recuperação do nó inteiro, mas não é um snapshot atômico: alterações durante o ciclo podem deixar diferenças entre a configuração do host e o estado dos discos dos convidados."
+  },
+  "frequencyBadge": {
+    "title": "Frequência recomendada",
+    "body": "Para maximizar a compatibilidade entre um backup do host e sua restauração futura, faça backups frequentes. Quanto mais próxima a cópia estiver do estado atual do host, menos diferenças de configuração, pacotes e componentes a restauração precisará conciliar."
+  },
+  "modes": {
+    "heading": "Os dois modos",
+    "rows": [
+      {
+        "mode": "Novo trabalho agendado",
+        "backends": "Local, PBS, Borg",
+        "schedule": "Expressão <code>OnCalendar</code> própria (sintaxe de calendário systemd, por exemplo <code>daily</code> ou <code>Mon..Fri 03:00</code>).",
+        "retention": "Solicitado separadamente: <code>keep-last</code>, <code>keep-hourly</code>, <code>keep-daily</code>, <code>keep-weekly</code>, <code>keep-monthly</code>, <code>keep-yearly</code>. Aplicado pelo script de execução após cada backup bem sucedido."
+      },
+      {
+        "mode": "Anexar a uma tarefa PVE vzdump",
+        "backends": "Local, PBS (Borg não tem agendador do lado PVE)",
+        "schedule": "Herdado da tarefa PVE principal. Nenhum temporizador systemd é instalado no lado do ProxMenux.",
+        "retention": "Herdada da configuração <code>prune-backups</code> da tarefa principal (mapeada um a um para as variáveis <code>KEEP_*</code> do script de execução via <code>hb_pve_prune_to_keep_env</code>)."
+      }
+    ]
+  },
+  "attachDetail": {
+    "heading": "Como funciona o modo de anexação",
+    "intro": "O PVE grava as tarefas <code>vzdump</code> em <code>/etc/pve/jobs.cfg</code>, com uma seção por tarefa indicando o armazenamento dos backups de VM e LXC. O modo de anexação exige um backend suportado pelo ProxMenux (Local ou PBS). O backup do host é executado pelo hook job-end após o fim da tarefa de backup dos convidados.",
+    "steps": [
+      {
+        "step": "1",
+        "detail": "Durante a criação do trabalho, ProxMenux lista tarefas PVE pai compatíveis via <code>hb_pve_list_vzdump_jobs_for_backend</code>. O utilizador escolhe uma."
+      },
+      {
+        "step": "2",
+        "detail": "O <code>.env</code> do trabalho é escrito com <code>PVE_PARENT_JOB</code>, <code>PVE_STORAGE</code> e os valores herdados <code>KEEP_*</code>; nenhum temporizador systemd é criado."
+      },
+      {
+        "step": "3",
+        "detail": "<code>hb_install_vzdump_hook</code> registra um hook em <code>/etc/vzdump.conf</code>. Na fase job-end de qualquer tarefa vzdump, compara o <code>$STOREID</code> recebido com o <code>PVE_STORAGE</code> de cada trabalho anexado e habilitado, chamando o script de execução para as correspondências. A associação é feita pelo armazenamento, não pelo ID da tarefa principal selecionada."
+      },
+      {
+        "step": "4",
+        "detail": "O arquivo é salvo no mesmo armazenamento dos backups vzdump: <code>path/dump/</code> para Local ou o repositório PBS configurado na entrada de armazenamento PVE."
+      }
+    ],
+    "outroBody": "O modo de anexação não tem temporizador próprio. Desabilitar ou excluir a tarefa PVE principal selecionada interrompe esse disparo, mas outra tarefa vzdump usando o mesmo armazenamento ainda pode acionar o backup do host. Desabilite ou exclua o próprio trabalho ProxMenux para impedir isso. Ao ser desabilitada, a entrada permanece no disco e pode ser reativada ou anexada novamente."
+  },
+  "storageLayout": {
+    "heading": "Arquivos que compõem um trabalho",
+    "intro": "Cada trabalho agendado é totalmente descrito por três ou quatro arquivos no disco. Lendo-os dá a configuração completa do trabalho sem depender da interface.",
+    "rows": [
+      {
+        "path": "/var/lib/proxmenux/backup-jobs/JOB_ID.env",
+        "content": "Infraestrutura, ID de backup ou destino, agenda (novo modo) ou pai PVE (modo de Attach), sinalizador habilitado, valores de retenção <code>KEEP_*</code>, ponteiros de credenciais."
+      },
+      {
+        "path": "/var/lib/proxmenux/backup-jobs/JOB_ID.paths",
+        "content": "Um caminho absoluto por linha — a seleção congelada resolvido a partir do perfil no tempo de criação de emprego. A edição do ficheiro volta a executar o trabalho com a nova selecção no próximo temporizador."
+      },
+      {
+        "path": "/etc/systemd/system/proxmenux-backup-JOB_ID.timer + .service",
+        "content": "Apenas modo novo. O serviço invoca o <code>run_scheduled_backup.sh JOB_ID</code>. O timer agenda-o com <code>Persistent=true</code> (execuções perdidas recuperadas na próxima inicialização) e um pequeno <code>RandomizedDelaySec=120</code> para espalhar carga quando vários trabalhos compartilham a mesma expressão OnCalendar."
+      },
+      {
+        "path": "/etc/vzdump.conf script-hook",
+        "content": "Somente modo de anexação. Instalado uma vez por <code>hb_install_vzdump_hook</code>; compara <code>PVE_STORAGE</code> de cada trabalho anexado com <code>$STOREID</code>, passado pelo PVE ao hook."
+      }
+    ]
+  },
+  "runner": {
+    "heading": "O que um trabalho faz quando dispara",
+    "intro": "Cada trabalho — novo ou anexado — executa a mesma sequência de três passos:",
+    "steps": [
+      "<strong>Prepare o backup.</strong> Lê a configuração do trabalho (destino, perfil, caminhos) e monta a árvore de arquivos exatamente da mesma forma que o fluxo interativo faz. O resultado é o mesmo arquivo que um backup manual com essas configurações produziria.",
+      "<strong>Escreva o destino.</strong> Envia ou escreve o arquivo para o destino configurado — um arquivo <code>.tar.zst</code> local, um backup PBS, ou um arquivo Borg — usando exatamente as mesmas ferramentas e credenciais que um backup manual para o mesmo destino usaria.",
+      "<strong>Aplicar retenção.</strong> Remove backups antigos do destino, mantendo as contagens <code>keep-last</code> / <code>keep-daily</code> / <code>keep-weekly</code> configuradas no trabalho. A poda é realizada pelo próprio destino: PBS aplica sua própria retenção, Borg executa <code>borg prune</code>, e para ProxMenux Local apaga os arquivos que caem fora da janela <code>keep-last</code>."
+    ]
+  },
+  "management": {
+    "heading": "Gestão de tarefas",
+    "intro": "O menu de agendamento (Scripts TUI) e a aba Monitor Backups expõem as mesmas ações em qualquer trabalho.",
+    "rows": [
+      {
+        "action": "Executar agora",
+        "detail": "Chama imediatamente o script de execução, sem esperar o temporizador ou o hook vzdump. Útil para verificar a configuração sem aguardar a próxima execução agendada."
+      },
+      {
+        "action": "Activar / Desactivar",
+        "detail": "Novo modo: <code>systemctl enable/disable --now</code> o temporizador. Modo Anexar: altera o sinalizador <code>ENABLED</code> no env de trabalho — o script gancho honra-o na próxima execução PVE."
+      },
+      {
+        "action": "Editar",
+        "detail": "Abre novamente o destino, agenda, perfil e avisos de retenção e reescreve os arquivos de trabalho. Preserva a identificação do trabalho."
+      },
+      {
+        "action": "Excluir",
+        "detail": "Remove o env do trabalho, o arquivo de caminhos, o temporizador e o serviço systemd (modo novo) e desativa a associação ao hook (modo de anexação). Não altera os arquivos já existentes no destino."
+      },
+      {
+        "action": "Ver registo",
+        "detail": "Mostra em tempo real <code>/var/log/proxmenux/backup-jobs/JOB_ID-YYYYMMDD_HHMMSS.log</code> — um arquivo de log por execução. O executor também emite uma linha de status compacta para journald no serviço systemd."
+      }
+    ]
+  },
+  "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."
+  },
+  "whereNext": {
+    "heading": "Para onde ir a seguir",
+    "items": [
+      {
+        "label": "Criando backups",
+        "href": "/docs/backup-restore/creating-backups",
+        "tail": " — o fluxo interactivo que partilha a infra-estrutura com o agendador."
+      },
+      {
+        "label": "Destinos",
+        "href": "/docs/backup-restore/destinations",
+        "tail": " — a configuração por infra-estrutura utilizada tanto pelo fluxo interactivo como pelo agendador."
+      },
+      {
+        "label": "Restauração",
+        "href": "/docs/backup-restore/restoring",
+        "tail": " — o fluxo que utiliza os backups produzidos pelos trabalhos."
+      }
+    ]
+  }
+}