Proxmox Backup Server em uma VPS: guia prático

O que o Proxmox Backup Server numa VPS realmente oferece

O Proxmox Backup Server (PBS) numa VPS é um destino externo que utiliza o mesmo protocolo que o cluster Proxmox VE (ambiente virtual) já utiliza. Assim, todas as cópias de segurança depois da primeira são incrementais, deduplicadas entre guests, cifradas antes de saírem das suas instalações e verificáveis posteriormente. Aluga uma VPS com um volume de blocos, instala o PBS em Debian 13, cria um datastore nesse volume e adiciona-o ao Proxmox VE como armazenamento do tipo pbs. A instalação demora dez minutos. Tudo o que acontece depois — namespaces, recolha de lixo, custódia das chaves e uma restauração que tenha realmente executado — é o que determina se a cópia de segurança terá algum valor daqui a um ano.

A razão para utilizar o PBS em vez de copiar ficheiros vzdump para um disco alugado é o armazenamento de chunks. O cliente divide cada disco guest em chunks de cerca de 4 MiB, calcula um hash para cada um e carrega apenas os chunks que o datastore ainda não contém. Numa máquina virtual em execução, o QEMU acompanha os blocos alterados numa dirty bitmap depois da primeira cópia de segurança. A execução seguinte lê apenas esses blocos do disco local. Um guest de 200 GB que altere 3 GB por dia envia cerca de 3 GB por dia. É isso que permite utilizar em conjunto uma ligação de saída doméstica e um volume alugado. É também por isso que uma VPS como destino externo de cópias de segurança é melhor do que um disco suplente em casa de um amigo. Se ainda estiver a decidir onde o próprio hypervisor deve ficar, Proxmox em casa versus uma VPS alugada aborda essa questão separadamente.

Dimensione o volume antes de o alugar

O dimensionamento é um cálculo que faz com os seus próprios valores. Considere o espaço efetivamente utilizado por cada guest, e não o tamanho do respetivo disco virtual. Depois, some a quantidade alterada por dia multiplicada pelo número de dias de retenção. A compressão e a deduplicação melhoram ambos esse valor. Por isso, trate o resultado como um limite máximo, não como uma meta.

[
  {
    "label": "web VM",
    "used_gb": 40,
    "daily_change_gb": 0.8,
    "store_gb": 64
  },
  {
    "label": "mail VM",
    "used_gb": 120,
    "daily_change_gb": 3.0,
    "store_gb": 210
  },
  {
    "label": "file server container",
    "used_gb": 300,
    "daily_change_gb": 1.5,
    "store_gb": 345
  }
]

Essas linhas são um exemplo calculado, não uma medição. Leia o espaço utilizado a partir de df -h dentro de cada guest. Leia a alteração diária a partir do tamanho do segundo e do terceiro backups no log da tarefa do PBS, depois de estes existirem.

O guest de correio do exemplo utiliza 120 GB e altera cerca de 3.0 GB por dia. Por isso, trinta snapshots diários precisam de aproximadamente 210 GB: uma cópia completa mais trinta dias de alterações. Some a última coluna para todos os 3 guests. O total é de aproximadamente 619 GB. Acrescente um quinto para índices, metadados e o espaço necessário para a garbage collection, o que aponta para um volume de 1 TB.

O restante plano é simples. O PBS funciona com 2 GB de RAM e trabalha confortavelmente com 4 GB, porque o processamento mais exigente ocorre no lado do cluster: o nó Proxmox VE lê os discos dos guests e executa a divisão em chunks e o hashing. O VPS escreve chunks e executa as duas tarefas pesadas: garbage collection e verificação. Alugue o datastore como um volume de blocos separado, em vez de utilizar um único disco root grande. Assim, pode aumentar o volume mais tarde sem reconstruir o servidor.

Instalar o Proxmox Backup Server no Debian 13

Em agosto de 2026, a combinação atual é o Proxmox Backup Server 4 no Debian 13, com o codename trixie. Os guias antigos associam o PBS 2 ao Debian 11, e o codename faz parte da definição do repositório. Copiar um nome de suite antigo produz um erro do apt sobre a ausência do ficheiro de release. Comece com uma imagem limpa do Debian 13. Execute tudo abaixo como root ou com sudo conforme escrito.

sudo apt update && sudo apt install -y wget
sudo wget https://enterprise.proxmox.com/debian/proxmox-archive-keyring-trixie.gpg -O /usr/share/keyrings/proxmox-archive-keyring.gpg
sha256sum /usr/share/keyrings/proxmox-archive-keyring.gpg

A soma deve ser 136673be77aba35dcce385b28737689ad64fd785a797e57897589aed08db6e45. Se não for, pare. Um keyring incorreto significa que está prestes a instalar pacotes assinados por uma origem que não verificou.

Escreva /etc/apt/sources.list.d/pbs.sources com o repositório no-subscription, que é o adequado para um servidor sem contrato de suporte:

Types: deb
URIs: http://download.proxmox.com/debian/pbs
Suites: trixie
Components: pbs-no-subscription
Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg

sudo apt update
sudo apt install -y proxmox-backup-server

A interface web responde na porta HTTPS 8007. Inicie sessão como root@pam usando a palavra-passe do sistema root, porque o PBS autentica esse utilizador através do PAM (pluggable authentication modules), as mesmas contas utilizadas pelo sistema operativo. O certificado é autoassinado e o navegador indicará isso. A impressão digital desse certificado é o valor que o Proxmox VE fixa posteriormente, portanto o aviso é esperado e não é um problema que precise de correção.

A porta 8007 disponibiliza um formulário de início de sessão na Internet pública, portanto não a deixe aberta a todos. Um único ficheiro do nftables cobre este acesso. Escrever /etc/nftables.conf limpa o ruleset atual, portanto ignore este passo se outra ferramenta já gerir a firewall neste servidor.

#!/usr/sbin/nft -f
flush ruleset

table inet filter {
  chain input {
    type filter hook input priority filter; policy drop;
    ct state established,related accept
    iif lo accept
    tcp dport 22 accept
    ip saddr 203.0.113.7 tcp dport 8007 accept
  }
}

Aplique-o com sudo systemctl enable --now nftables e mantenha uma segunda sessão SSH aberta enquanto o faz: policy drop, juntamente com um erro de digitação na regra SSH, pode bloquear o acesso ao seu próprio servidor. Substitua 203.0.113.7 pelo endereço a partir do qual o cluster se liga. Se esse endereço for dinâmico, alargue a regra ao intervalo do seu fornecedor ou termine a ligação num túnel. Tenha também em conta que a maioria dos painéis de VPS tem uma firewall de rede separada à frente da máquina, que deve permitir a mesma porta.

Coloque o datastore no seu próprio volume

O datastore não pode ficar no sistema de ficheiros raiz. Quando um datastore enche um sistema de ficheiros raiz partilhado, a cópia de segurança falha e todo o resto do servidor também deixa de funcionar, incluindo o registo de eventos necessário para descobrir o motivo. Anexe o volume de blocos, formate-o, monte-o e só depois crie o datastore dentro do ponto de montagem.

lsblk
sudo mkfs.ext4 -L pbsstore /dev/vdb
sudo mkdir -p /mnt/datastore/store1

Obtenha o nome do dispositivo a partir de lsblk. Na maioria das imagens KVM, é /dev/vdb; noutras, é /dev/sdb. Nunca é seguro assumir o nome. Adicione a montagem a /etc/fstab por etiqueta, para que uma alteração do nome do dispositivo depois de um reboot não aponte o datastore para o disco errado:

LABEL=pbsstore  /mnt/datastore/store1  ext4  defaults,relatime  0  2

sudo systemctl daemon-reload
sudo mount -a
findmnt -no SOURCE,TARGET,OPTIONS /mnt/datastore/store1

findmnt deve apresentar o dispositivo, o caminho e opções que incluam rw,relatime. Há duas falhas ocultas nessa linha. Se a montagem não existir e criar o datastore na mesma, o PBS escreve no sistema de ficheiros raiz por baixo do ponto de montagem. A montagem seguinte, quando for bem-sucedida, oculta esses dados sem os eliminar. O datastore parece então vazio, mas o sistema de ficheiros raiz continua cheio. Se as opções indicarem noatime, o PBS recusa-se a funcionar, porque executa uma verificação de segurança do tempo de acesso quando o datastore é criado e novamente em cada recolha de lixo.

sudo proxmox-backup-manager datastore create store1 /mnt/datastore/store1
sudo proxmox-backup-manager datastore list

Isto cria um diretório .chunks que contém 65536 subdiretórios, com nomes de 0000 a ffff. Um datastore contém centenas de milhares de ficheiros pequenos, não alguns ficheiros grandes. Daqui resultam duas consequências. Copiar um datastore com uma ferramenta comum ao nível dos ficheiros é suficientemente lento para não ser útil. Além disso, um snapshot do volume do fornecedor criado enquanto as cópias de segurança estão a decorrer não é uma cópia consistente do datastore. É pelo mesmo motivo que os snapshots não substituem as cópias de segurança em nenhum outro contexto.

As namespaces evitam colisões entre dois hosts

Por predefinição, um datastore é plano. Os backups recebem nomes como vm/100, ct/101 e host/<name>. Dois clusters que tenham, cada um, um guest com o ID 100 escrevem no mesmo grupo, os seus snapshots ficam intercalados e uma regra de retenção criada para um deles contabiliza os snapshots do outro. As namespaces dão a cada origem a sua própria árvore dentro de um único datastore.

Crie-as no host PBS. O argumento --repository tem o formato [[auth-id@]server[:port]:]datastore, por isso uma namespace local é indicada por root@pam@localhost:store1, e o comando pede a palavra-passe de root.

sudo proxmox-backup-client namespace create --repository 'root@pam@localhost:store1' pve-home
sudo proxmox-backup-client namespace create --repository 'root@pam@localhost:store1' pve-office
sudo proxmox-backup-client namespace list --repository 'root@pam@localhost:store1'

A deduplicação não é afetada por esta separação. Os chunks são partilhados em todo o datastore, por isso dez guests Debian distribuídos por três namespaces continuam a armazenar uma única cópia do sistema base. Essa é a vantagem de usar um datastore com namespaces em vez de um datastore por host: datastores separados significam pools de chunks separados, e pools de chunks separados significam pagar várias vezes pela mesma instalação Debian.

Dê a cada origem a sua própria conta, limitada à sua própria namespace. Um token de API (application programming interface) é uma credencial pertencente a um utilizador e tem as suas próprias permissões. É isso que pretende numa máquina que pode ser roubada.

sudo proxmox-backup-manager user create backup@pbs --email you@example.com
sudo proxmox-backup-manager user generate-token backup@pbs pve-home
sudo proxmox-backup-manager acl update /datastore/store1/pve-home DatastoreBackup --auth-id 'backup@pbs!pve-home'

O comando do token mostra o segredo exatamente uma vez:

Result: {
  "tokenid": "backup@pbs!pve-home",
  "value": "d63e505a-e3ec-449a-9bc7-1da610d4ccde"
}

Copie-o agora, porque o PBS não guarda nenhuma forma do segredo que possa voltar a mostrar. Verifique duas vezes o comando de controlo de acesso. Ele identifica o token, backup@pbs!pve-home, e não o utilizador, porque as permissões do token são calculadas apenas a partir das entradas que identificam o próprio token. Uma entrada apenas para backup@pbs deixa o token sem qualquer acesso, e o primeiro backup falha por falta de permissões, não por um problema visível na rede. O caminho também é importante: um token limitado a /datastore/store1/pve-home não pode ler nem apagar nada na namespace do escritório, por isso um cluster comprometido não pode destruir o histórico de outro site.

Adicionar o VPS como armazenamento de backup no Proxmox VE

Leia primeiro a impressão digital do certificado no host PBS.

sudo proxmox-backup-manager cert info | grep Fingerprint

Depois, em qualquer nó do cluster:

sudo pvesm add pbs pbs-offsite --server pbs.example.com --datastore store1
sudo pvesm set pbs-offsite --username 'backup@pbs!pve-home' --password
sudo pvesm set pbs-offsite --fingerprint 'FINGERPRINT_FROM_CERT_INFO'
sudo pvesm set pbs-offsite --namespace pve-home
sudo pvesm set pbs-offsite --prune-backups keep-all=1

Cole o valor cert info apresentado no lugar do marcador na terceira linha. Passar --password sem valor faz com que pvesm o solicite, para que o segredo do token não fique no histórico da shell. Ele é armazenado em /etc/pve/priv/storage/pbs-offsite.pw, e a própria definição do armazenamento fica em /etc/pve/storage.cfg. Essa definição é replicada para todos os nós do cluster, portanto a configuração é feita uma única vez para todo o cluster.

--prune-backups keep-all=1 indica ao Proxmox VE para não eliminar nada. A retenção deve ser configurada no lado do PBS, como explicado mais abaixo, por uma razão importante: o token não precisa de permissão para eliminar dados. Assim, se um cluster for cifrado por ransomware, não poderá contactar o armazenamento externo e eliminar o histórico que deveria permitir a recuperação.

sudo pvesm status --storage pbs-offsite
sudo vzdump 100 --storage pbs-offsite --mode snapshot

pvesm status apresenta active na coluna de estado, com o espaço total e utilizado do datastore ao lado. inactive significa que o nó não conseguiu concluir uma sessão TLS (transport layer security) na porta 8007. Isso indica um problema de firewall ou de impressão digital, não um problema de credenciais.

O primeiro backup envia tudo, por isso faça os cálculos antes de o iniciar. 200 GB correspondem a 1600 gigabits, e uma ligação ascendente de 100 Mbit transfere 0.1 gigabit por segundo. O tempo mínimo é, portanto, de cerca de quatro horas e meia, e na prática será maior. Inicie-o quando não precisar da largura de banda. Em cada execução seguinte, são enviados apenas os novos chunks.

Criptografia no cliente e onde a chave fica

O VPS é um computador que não lhe pertence. Faça a criptografia no cliente, e o armazenamento terá blocos que o fornecedor não consegue ler.

sudo pvesm set pbs-offsite --encryption-key autogen

Esse comando grava uma nova chave em /etc/pve/priv/storage/pbs-offsite.enc, legível apenas por root, e replicada com o restante de /etc/pve. A partir do backup seguinte, o cliente criptografa cada bloco antes de o enviar. O servidor ainda pode listar os seus snapshots e respetivos tamanhos, mas não consegue ler o respetivo conteúdo.

Agora vem a parte que transforma isto num backup, em vez de num risco. Uma chave gerada não tem uma frase-passe e existe apenas no cluster que protege. Se esse cluster for roubado ou criptografado por outra pessoa, o VPS ficará com dados que ninguém consegue abrir. Copie a chave para fora do cluster no dia em que a criar.

sudo cp /etc/pve/priv/storage/pbs-offsite.enc /root/pbs-offsite.enc
sudo proxmox-backup-client key paperkey /root/pbs-offsite.enc

key paperkey imprime a chave como um documento destinado a ser impresso em papel e guardado noutro local. Trate o próprio ficheiro como um segredo, porque qualquer pessoa que o possua pode descriptografar todos os backups criados com ele. Numa configuração maior, o PBS também suporta uma chave mestra: um par de chaves RSA (Rivest Shamir Adleman) criado com proxmox-backup-client key create-master-key. Cada backup guarda a sua própria chave de criptografia criptografada com a metade pública, enquanto a metade privada permanece offline para recuperação.

Vale a pena conhecer uma consequência deste modelo antes de começar, e não depois. Nos backups criptografados, o digest do bloco é calculado a partir do conteúdo em texto simples combinado com a chave de criptografia. Por isso, dois blocos idênticos criptografados com chaves diferentes produzem digests diferentes e nunca são deduplicados entre si. Alterar a chave faz com que o backup seguinte carregue tudo novamente, e os blocos antigos permanecem até os respetivos snapshots serem removidos e recolhidos. Decida sobre a criptografia antes do primeiro carregamento.

As marcas de pruning, a garbage collection recupera

Esta é a secção que costuma ser ignorada, embora seja a que enche o volume. O pruning de um snapshot remove os respetivos metadados: o manifest, os índices, o log e as notas. Não elimina nenhum chunk. Os chunks são partilhados entre snapshots. Por isso, não é possível saber que um chunk não é utilizado até todos os índices restantes serem lidos. Essa é a função da garbage collection. Um datastore com um agendamento de pruning, mas sem um agendamento de garbage collection, só aumenta de tamanho.

Configure ambos. Primeiro, a retenção, com um job por namespace:

sudo proxmox-backup-manager prune-job create home-daily --store store1 --ns pve-home --schedule '02:30' --keep-daily 14 --keep-weekly 8 --keep-monthly 6
sudo proxmox-backup-manager prune-job list

Depois, o agendamento da collection no datastore, algumas horas depois do job de pruning e fora da janela de backup:

sudo proxmox-backup-manager datastore update store1 --gc-schedule 'Sun 04:27'
sudo proxmox-backup-manager datastore show store1

Confirme uma vez esta separação no host do PBS:

df -h /mnt/datastore/store1
sudo proxmox-backup-manager garbage-collection start store1
df -h /mnt/datastore/store1

Execute o job de pruning e depois df. O valor de utilização não muda. Execute a garbage collection e depois df novamente. Desta vez, o valor muda.

A garbage collection é executada em duas fases. Na primeira, percorre todos os índices do datastore e atualiza o tempo de acesso de cada chunk referenciado por esses índices. Na segunda, elimina os chunks cujo tempo de acesso é anterior ao limite. Esse limite corresponde a 24 horas e 5 minutos antes do início da execução ou ao início do backup mais antigo que ainda esteja a escrever, consoante o que ocorrer primeiro. Essa margem existe porque o Linux monta os sistemas de ficheiros com relatime por predefinição. Essa opção atualiza o tempo de acesso aproximadamente uma vez por dia, em vez de o atualizar a cada leitura. Assim, um chunk escrito há uma hora nunca é eliminado, mesmo que ainda não seja referenciado. O espaço libertado pelo pruning aparece na primeira collection executada mais de um dia depois do último acesso ao chunk. Um datastore que parece não ter recuperado espaço está frequentemente apenas dentro dessa janela.

Num VPS pequeno, este é o job mais pesado executado no servidor, porque faz stat de todos os ficheiros de chunks no volume. O log da tarefa termina com um resumo do que foi removido e do que continua pendente devido ao período de tolerância. Se houver muitos itens pendentes, execute-o novamente no dia seguinte. O PBS disponibiliza gc-atime-safety-check e gc-atime-cutoff como opções de ajuste do datastore. Deve deixá-las inalteradas. Estas opções existem para armazenamento que não consegue registar tempos de acesso. Desativar a verificação de segurança num sistema de ficheiros montado com noatime é uma forma de perder chunks ainda referenciados por snapshots ativos.

A verificação confirma que os chunks continuam legíveis

Um backup que foi carregado sem erros pode deixar de ser legível um ano depois. A verificação volta a ler os chunks e compara-os com os checksums armazenados no índice. Assim, os danos são detetados segundo um agendamento, e não durante uma restauração.

sudo proxmox-backup-manager verify store1 --read-threads 1 --verify-threads 4

Mantenha baixas as contagens de threads num VPS pequeno. A verificação é limitada pelo disco e pela CPU. Caso contrário, irá competir com as restantes tarefas do servidor. Para definir um agendamento, use o separador Verify Jobs do datastore na interface web. Um job semanal que ignore snapshots já verificados e volte a verificar tudo o que tenha mais de 30 dias cobre todo o datastore ao longo do tempo sem repetir trabalho.

Um snapshot que falhe a verificação é marcado como falhado na vista do datastore. Não ignore essa falha. Os chunks são partilhados. Por isso, um único chunk danificado de uma imagem base normalmente faz falhar todos os snapshots que o referenciem. Para corrigir o problema, esqueça os snapshots falhados e execute um novo backup. Os chunks em falta serão carregados novamente. Se as falhas continuarem a aparecer, suspeite do armazenamento subjacente ao datastore. Configure também o monitoramento da saúde do disco no VPS para que a unidade o avise antes do job de verificação.

Testar uma restauração e depois testá-la sem o cluster

Você não sabe se um backup funciona até restaurar um. Os dois testes verificam aspetos diferentes.

Guest completo, no cluster:

sudo pvesm list pbs-offsite
sudo qmrestore 'pbs-offsite:backup/vm/100/2026-08-14T22:00:00Z' 999 --storage local-lvm

A primeira coluna de pvesm list é o ID do volume, e o timestamp faz parte dele. Por isso, copie o seu em vez de escrever o exemplo. Restaure para um ID de guest não utilizado e para outro storage. Depois, inicie-o com a interface de rede desligada. Nunca restaure sobre um guest em execução para verificar se os backups funcionam. Se a restauração falhar a meio, também perderá a cópia funcional.

O segundo teste é o que ninguém executa. Suponha que o edifício onde está o cluster desapareceu e restaure a partir de uma máquina que nunca fez parte dele. Em qualquer máquina Debian 13, adicione o repositório apenas para clientes como /etc/apt/sources.list.d/pbs-client.sources:

Types: deb
URIs: http://download.proxmox.com/debian/pbs-client
Suites: trixie
Components: main
Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg

sudo apt update && sudo apt install -y proxmox-backup-client
export PBS_REPOSITORY='backup@pbs!pve-home@pbs.example.com:store1'
export PBS_PASSWORD='<the token secret>'
export PBS_FINGERPRINT='<the value cert info printed>'
proxmox-backup-client snapshot list --ns pve-home
proxmox-backup-client snapshot files vm/100/2026-08-14T22:00:00Z --ns pve-home
proxmox-backup-client restore vm/100/2026-08-14T22:00:00Z 'ARCHIVE_NAME_FROM_THAT_LIST' ./restore-test --keyfile ./pbs-offsite.enc --ns pve-home

Substitua os três placeholders entre aspas pelos seus próprios valores. Obtenha o nome do arquivo na última linha a partir da saída de snapshot files. Isto comprova algo que o primeiro teste não consegue comprovar: que a sua cópia do arquivo de chave consegue descriptografar dados reais e que consegue controlar o cliente a partir de uma máquina que nunca teve a configuração do seu cluster. Registre os quatro valores necessários: a string do repositório, o segredo do token, a impressão digital e o arquivo de chave. Mantenha-os juntos no local indicado pelo seu plano de recuperação de desastre.

O que a deduplicação faz e não faz com o custo do disco

A deduplicação é real e funciona em todo o datastore. Dez guests Debian partilham uma cópia do sistema base, por isso o segundo guest idêntico quase não acrescenta espaço de armazenamento. Também poupa largura de banda de upload, porque o cliente envia um checksum em vez dos dados de qualquer chunk que o servidor já tenha.

É importante deixar claro o que ela não faz.

• Não reduz dados que sofrem alterações. Uma base de dados que reescreve grandes partes dos seus ficheiros todas as noites produz novos chunks todas as noites, e a retenção multiplica-os.
• Não atravessa um limite entre chaves de encriptação, conforme explicado acima.
• Não atravessa um limite entre datastores, que é precisamente o motivo para usar namespaces.
• Não impede que um volume fique cheio. Quando o datastore fica cheio, os backups falham. As únicas soluções são aumentar o volume ou reduzir a retenção.

Não coloque outra camada de deduplicação por baixo. Os chunks já chegam deduplicados e comprimidos pelo cliente. Por isso, a deduplicação do ZFS por baixo de um datastore usa RAM à procura de correspondências que foram removidas antes da escrita. Usar ext4 ou xfs simples no volume é a escolha correta neste caso.

A interface web mostra um fator de deduplicação para o datastore. Esse número descreve os seus guests e é o único que vale a pena usar no planeamento, porque os rácios publicados descrevem os dados de outra pessoa. Se também precisar de backups ao nível de ficheiros de máquinas que não são guests Proxmox, execute-os em paralelo no mesmo VPS: o PBS é um destino com conhecimento do hypervisor para guests completos, enquanto restic e BorgBackup apontam para diretórios, e os backups do restic para um VPS são adequados para portáteis e servidores autónomos que o PBS nunca se destinou a abranger.

Modos de falha e o que será apresentado

O armazenamento aparece como inativo. pvesm status --storage pbs-offsite apresenta inactive quando o nó não consegue concluir uma sessão TLS na porta 8007. Verifique a firewall do VPS, depois a firewall de rede separada do fornecedor e, por fim, a impressão digital. Uma impressão digital que já não corresponde ao certificado falha de forma visível igual a uma porta bloqueada e muda sempre que esse certificado é substituído.

A primeira cópia de segurança falha por causa das permissões. A entrada de controlo de acesso tem de identificar o token, e não o utilizador, e tem de abranger o namespace para o qual o armazenamento aponta. Confirme ambos no separador de permissões do datastore, na interface web, antes de procurar noutro local.

A recolha de lixo recusa-se a iniciar. A verificação de segurança do tempo de acesso falhou. Isto quase sempre significa que o sistema de ficheiros do datastore está montado como noatime. Execute findmnt -no OPTIONS /mnt/datastore/store1 para confirmar, corrija a opção em /etc/fstab e monte novamente. Não desative a verificação para ultrapassar o erro.

O datastore só aumenta de tamanho. Os trabalhos de pruning são executados, mas nada é recuperado. Ou não existe um agendamento de recolha de lixo, ou cada recolha ocorre dentro da janela de tolerância de 24 horas, porque é executada imediatamente depois das cópias de segurança. Verifique o agendamento com proxmox-backup-manager datastore show store1.

Uma cópia de segurança que antes era rápida demora horas. Uma guest que foi parada, migrada ou restaurada perde o seu dirty bitmap. Por isso, a execução seguinte lê o disco inteiro no lado do cluster, mesmo que carregue muito poucos dados. O log da tarefa mostra uma duração longa com um volume de carregamento reduzido, e a execução seguinte volta a ser rápida. Se todos os trabalhos no VPS forem lentos, a causa normalmente está fora do datastore. O CPU steal time causado por um vizinho ruidoso é o primeiro fator a medir.

FAQ

Por que o datastore do Proxmox Backup Server continua a crescer quando o job de prune é executado?

Porque o prune remove apenas os metadados dos snapshots: o manifest, os índices, o log e as notas. Os chunks permanecem no disco até que a garbage collection elimine aqueles que já não são referenciados por nenhum índice. Configure um agendamento para o datastore com proxmox-backup-manager datastore update store1 --gc-schedule 'Sun 04:27' e confirme executando df -h no caminho do datastore antes e depois de proxmox-backup-manager garbage-collection start store1. Espere um atraso de pelo menos um dia, porque a segunda fase só remove chunks cujo tempo de acesso seja anterior a 24 horas e 5 minutos.

De quanto espaço em disco precisa uma VPS com Proxmox Backup Server?

Some o espaço efetivamente usado por cada guest e depois adicione a alteração diária de cada guest multiplicada pelo número de dias de retenção. Esse total é um limite superior, porque a compressão e a deduplicação trabalham a seu favor. Adicione cerca de um quinto para os índices e a margem de trabalho e arredonde para cima até obter um tamanho de volume que possa adquirir. Volte a verificar após duas semanas, comparando com o uso real na vista do datastore, porque uma estimativa feita antes do primeiro backup está sempre errada numa direção ou na outra.

Onde deve ser armazenada a chave de encriptação do backup?

Em qualquer lugar, desde que não esteja apenas no cluster que protege. O Proxmox VE mantém-na em /etc/pve/priv/storage/<storage>.enc, que é replicado para todos os nós e, portanto, é perdido juntamente com o cluster. Copie-a para fora no primeiro dia, imprima-a com proxmox-backup-client key paperkey e guarde essa cópia noutro edifício. Tenha também em conta que a chave participa no digest dos chunks. Substituí-la mais tarde fará com que o backup seguinte carregue tudo novamente.

Preciso de um datastore por host Proxmox ou devo usar namespaces?

Use um datastore e um namespace por cada host ou cluster de origem. A deduplicação funciona dentro de um datastore, mas não entre datastores. Por isso, dividir por host armazena várias vezes as mesmas imagens base. Os namespaces mantêm os grupos de backup separados. Assim, dois hosts que tenham ambos um guest com o ID 100 não entram em conflito, e um caminho de controlo de acesso no formato /datastore/store1/pve-home limita o token de API de cada host ao seu próprio namespace.

Uma VPS pequena conseguirá acompanhar o ritmo como servidor de backup Proxmox?

Normalmente, sim, num homelab, porque o chunking e o hashing ocorrem no nó Proxmox VE, e não no servidor de backup. A VPS grava chunks e executa os dois jobs pesados: garbage collection e verificação. Atribua-lhe 4 GB de RAM e mantenha baixos os números de threads de verificação. Agende ambos os jobs fora da janela de backup. Se ainda demorarem muito mais do que o disco deveria precisar, meça o steal time antes de comprar um plano maior.