[Início](https://servhidden.com/pt) /
[Guias de Hospedagem com Privacidade](https://servhidden.com/pt/guides) /
Backup de VPS: Criptografado, Externo e Restaurável de Verdade






Operações


# Backups de VPS Que Restauram de Verdade



Hospedagem sem KYC tira a rede de segurança junto com a papelada: nenhum backup é retido, os dados são destruídos em até 24 horas após o encerramento, e não existe suporte que termine numa cópia recuperada. Este é o plano de trabalho — o que copiar, para onde levar, como impedir que um invasor apague tudo, e como provar que restaura.


[Ler o guia](#guide-body)
[Perguntas frequentes](#guide-faq)






## Nesta página




- [Guia](#guide-body)

- [Perguntas frequentes](#guide-faq)

- [Guias relacionados](#guide-related)

- [Páginas recomendadas](#guide-cta)






Sem KYC
Somente Cripto
Sem Logs
DMCA ignorado
Root Completo
NVMe SSD





19 min de leitura
Atualizado em Aug 2026

Nesta página

[01O que realmente destrói servidores](#o-que-realmente-destrói-servidores)
[02Snapshot não é backup, e sua hospedagem também não é](#snapshot-não-é-backup-e-sua-hospedagem-também-não-é)
[033-2-1, reescrita para quem nunca mostrou documento](#3-2-1-reescrita-para-quem-nunca-mostrou-documento)
[04Push, pull, e o erro que deixa uma noite ruim comer as duas cópias](#push-pull-e-o-erro-que-deixa-uma-noite-ruim-comer-as-duas-có)
[05Criptografe na origem, depois decida quem fica com a chave](#criptografe-na-origem-depois-decida-quem-fica-com-a-chave)
[06Escolhendo uma ferramenta, em uma tabela](#escolhendo-uma-ferramenta-em-uma-tabela)
[07Tudo o que está rodando não é um arquivo](#tudo-o-que-está-rodando-não-é-um-arquivo)
[08O que fazer backup, e as partes que todo mundo esquece](#o-que-fazer-backup-e-as-partes-que-todo-mundo-esquece)
[09Um restore que você nunca testou é um boato](#um-restore-que-você-nunca-testou-é-um-boato)
[10Automatizando para que continue acontecendo](#automatizando-para-que-continue-acontecendo)
[11A versão resumida](#a-versão-resumida)
[FAQPerguntas frequentes](#guide-faq)
[→Páginas recomendadas](#guide-cta)







Uma estratégia de backup nunca é testada na noite em que o servidor morre. Ela é testada semanas antes, em três decisões silenciosas que ninguém anota: para onde vai a cópia, quem tem permissão para apagá-la, e se alguém já de fato restaurou uma para conferir.

Uma hospedagem que nunca pediu sua identidade abre mão de algo em troca, e este é o lugar certo para dizer isso sem rodeios. Não existe gerente de conta para ligar, nem chamado que ressuscite um volume apagado, e [nossa própria política de retenção](https://servhidden.com/pt/privacy) é direta quanto ao motivo: os dados do servidor são destruídos em até 24 horas após o encerramento, os discos são apagados criptograficamente em vez de formatados, e **nenhum backup é retido**. É a mesma característica que torna a plataforma atraente, vista do outro lado. Tudo o que você queira recuperar depois de uma noite ruim já precisa estar em outro lugar — e é você quem o coloca lá.

## O que realmente destrói servidores

Quase ninguém perde um servidor do jeito que imagina. Falha catastrófica de hardware é real, mas rara, e é o único caso contra o qual uma hospedagem competente já se blinda. As perdas que realmente acontecem são mais banais, e cada uma delas derrota um tipo diferente de cópia — por isso "eu tenho backup" não é resposta enquanto você não disser a qual dessas situações ele sobrevive.

| O que dá errado | Como costuma acontecer | O que te salva |
| --- | --- | --- |
| **A sua própria mão** | Um rm -rf com uma variável de shell vazia, uma migration apontada para produção, um deploy que derrubou a tabela errada | Qualquer cópia fora da máquina de *antes* do erro — ou seja, a retenção precisa alcançar mais para trás do que o tempo que você leva para perceber |
| **Corrupção silenciosa** | Um NVMe morrendo, uma escrita truncada durante um reboot, um banco de dados gravando linhas corrompidas há uma semana | Cópias versionadas com profundidade suficiente para alcançar um ponto íntegro conhecido. Uma cópia espelhada única espelha fielmente o dano |
| **Comprometimento** | Uma chave roubada, uma aplicação sem patch, uma dependência envenenada — e depois, deliberadamente, seus backups | Uma cópia que a máquina comprometida não tinha poder de apagar. Nada além disso conta aqui |
| **Um incidente com o provedor ou o país** | Perda de hardware, uma ação judicial no datacenter, uma conta ou token que você não consegue mais acessar | Uma cópia que não está naquele provedor nem sob aquela jurisdição |
| **Perder a chave** | Uma senha esquecida, um keyfile apagado junto com o servidor que ele protegia, um cabeçalho LUKS que ninguém exportou | **Nada.** Esta é a única linha sem coluna de recuperação, e é mais comum do que falha de hardware |

Leia essa tabela como uma checklist, não como uma lista de medos. Uma cópia noturna para um segundo disco na mesma máquina responde só à primeira linha. Um snapshot no mesmo painel responde às linhas um e dois. Só uma cópia guardada em algum lugar que o servidor não alcança, sob uma chave que você ainda tem, responde às cinco.

Um destino de backup precisa de disco e de um endereço, não de núcleos. A máquina mais barata numa jurisdição diferente já é um destino competente — e a única cópia que sobrevive a um incidente no primeiro provedor.

## Snapshot não é backup, e sua hospedagem também não é

Snapshots são excelentes no que fazem: revertem uma atualização que deu errado, em segundos, sem transferência nenhuma. O que eles não conseguem fazer é sobreviver ao que derrubou o servidor, porque compartilham todos os domínios de falha com ele — o mesmo provedor, a mesma conta, o mesmo token de cobrança, o mesmo país, muitas vezes o mesmo cluster de armazenamento. Um snapshot te protege de *você mesmo*. Um backup te protege de tudo o mais.

Essa distinção importa mais aqui do que numa hospedagem tradicional, porque as redes de segurança de sempre foram removidas de propósito. Ninguém acessa os servidores dos clientes, então ninguém percebe que seu job de backup vem falhando desde março. Não há identidade vinculada à conta, então não existe um caminho humano do tipo "prove quem você é e nós restauramos". E o encerramento é definitivo mesmo: um saldo vencido é um evento de perda de dados, não um evento de cobrança.

**A cláusula das 24 horas é o argumento inteiro.** Nesta plataforma, os dados de um servidor encerrado são destruídos em até um dia, e os discos são apagados criptograficamente em vez de formatados. Não existe undelete, nem uma camada discreta de armazenamento frio, nem um desfecho de suporte que termine em "encontramos uma cópia mais antiga" — porque manter uma significaria reter seus dados depois que você pediu para não retermos. A rede de segurança e a privacidade são a mesma troca, feita uma única vez.

## 3-2-1, reescrita para quem nunca mostrou documento

A regra clássica diz três cópias, em dois tipos de mídia, uma delas fora do local. Ela foi escrita para uma era de fita magnética e disco rígido giratório, e a cláusula da mídia silenciosamente deixou de significar alguma coisa: seu disco de produção é NVMe, o disco do seu destino de backup também é NVMe, e chamar isso de "duas mídias" é uma história que você conta para si mesmo. A cláusula que vale a pena manter é a da distância, e para infraestrutura offshore distância não se mede em quilômetros.

Reescreva como **três cópias, dois provedores, duas jurisdições**. As falhas que derrubam as duas cópias ao mesmo tempo quase nunca são físicas — são uma conta à qual você perdeu acesso, um provedor que teve uma semana ruim, ou um instrumento jurídico que alcança um país e não tem efeito em outro. Dois servidores no mesmo rack são uma cópia com passos extras; dois servidores sob o mesmo regime legal são pouco melhores. Nosso [guia de jurisdições](https://servhidden.com/pt/guides/choosing-an-offshore-jurisdiction) explica como escolher uma segunda que não apenas espelhe a exposição da primeira.

Na prática isso sai barato. Um destino de backup não precisa de núcleos, e mal precisa de rede — precisa de disco e de um endereço. O menor [plano de VPS](https://servhidden.com/pt/vps) em uma das nossas outras [sete localizações](https://servhidden.com/pt/locations) já é um destino competente para restic ou Borg, e para arquivos medidos em terabytes um [servidor dedicado](https://servhidden.com/pt/dedicated) com discos de verdade custa menos por terabyte do que qualquer object storage. Onde o dado é genuinamente grande e raramente lido, a economia favorece o bare metal por uma margem larga.

Uma coisa que as pessoas acertam na produção e erram no destino de backup: pagar da mesma forma. Um segundo servidor comprado com um cartão no seu próprio nome religa discretamente a identidade que você se esforçou para remover do primeiro, e agora ele guarda uma cópia completa de tudo o que está nele. Se o servidor de produção é pago [em Monero](https://servhidden.com/pt/guides/how-to-pay-for-hosting-with-monero), o de backup merece o mesmo tratamento.

A terceira cópia é a que a maioria pula, e é a única imune a todas as falhas remotas ao mesmo tempo: um disco que você segura fisicamente, atualizado de vez em quando, mantido offline. Uma vez por mês já basta para a maioria das pessoas. Custa a atenção de um cafezinho, e é a cópia que sobrevive aos cenários que as outras duas compartilham.

## Push, pull, e o erro que deixa uma noite ruim comer as duas cópias

Este é o arranjo que quase todo mundo monta primeiro. Um job no servidor de produção roda toda noite, guarda uma chave ou um token do destino de backup, conecta e envia (push). Funciona, é simples, e tem uma propriedade que só fica visível no pior dia da vida do servidor: **quem controla a máquina de produção também controla os backups.**

Isso não é hipótese. Apagar ou criptografar os backups da vítima antes de se anunciar é prática padrão para quem faz isso comercialmente — as credenciais estão sentadas num cron job ou num arquivo de ambiente, e encontrá-las leva cerca de um minuto. Uma cópia que seu invasor consegue apagar não é uma segunda cópia. É um espelho da primeira com atraso.

Existem duas soluções limpas, e elas combinam bem com o [hardening básico](https://servhidden.com/pt/guides/first-hour-vps-hardening-checklist) que você já deveria ter feito.

- **Destinos append-only.** As duas ferramentas principais suportam um modo em que o cliente pode adicionar dados, mas não removê-los. O Borg faz isso fixando a chave SSH no destino em borg serve --append-only; o restic faz isso com um servidor REST iniciado com --append-only. O servidor de produção escreve todas as noites e é estruturalmente incapaz de destruir o histórico. A limpeza de snapshots antigos então acontece no destino, numa sessão que a máquina de produção não consegue iniciar.

- **Pull em vez de push.** Inverta a direção: o host de backup conecta na produção, lê e armazena. A produção não guarda nenhuma credencial do destino, então não há nada para roubar. Restrinja a chave usada do lado da produção com restrict e um command= forçado, para que uma chave de backup roubada não vire um shell.

Pull é o modelo mais forte e dá um pouco mais de trabalho para manter; append-only é praticamente de graça se você já usa Borg ou restic. Qualquer um dos dois transforma "o invasor apagou meus backups" de um resultado em uma tentativa. Se você levar uma única coisa deste guia, leve esta seção.

## Criptografe na origem, depois decida quem fica com a chave

As duas ferramentas sérias criptografam na máquina que está sendo copiada, antes de qualquer coisa cruzar a rede. O destino armazena blobs que não consegue interpretar — o que é exatamente o que torna segura a cópia entre provedores diferentes. Seu segundo host não precisa ser confiável, nem simpático; precisa estar acessível e ter disco. Essa única característica é o que transforma "um servidor num país sobre o qual não sei nada" de um risco em infraestrutura.

Esse é um mecanismo diferente de criptografar o próprio disco do servidor, e os dois respondem a perguntas diferentes — nosso guia sobre [criptografia de disco completo em um VPS](https://servhidden.com/pt/guides/full-disk-encryption-on-a-vps) detalha o que a criptografia de disco protege e o que ela não protege enquanto a máquina está ligada. A criptografia de backup é a mais fácil e a mais valiosa das duas, porque o modelo de ameaça é honesto: o dado está em repouso, em um hardware que você não controla, e a chave nunca vai para lá.

O que transfere todo o risco para a custódia da chave. A senha agora é um ponto único de perda total, e é um ponto único pior do que as pessoas esperam, porque perdê-la é silencioso — nada quebra, os backups continuam rodando, e você só descobre no exato momento em que precisava deles. Três hábitos resolvem isso:

- Mantenha a senha no servidor apenas como um arquivo legível somente pelo root, referenciado com --password-file, para que ela nunca apareça numa lista de processos ou num histórico de shell.

- Mantenha uma cópia legível por humanos fora de todas as máquinas envolvidas. Papel numa gaveta genuinamente bate um gerenciador de senhas sincronizado com uma conta que você também pode perder.

- Adicione uma segunda chave ao repositório — restic key add, ou uma chave do Borg exportada — para que uma senha esquecida seja um incômodo, e não o fim do arquivo.

A regra por trás das três: **se a única cópia da chave mora na máquina que o backup existe para substituir, você não tem um backup.** Você tem uma pilha criptografada de blocos e uma história sobre ela.

## Escolhendo uma ferramenta, em uma tabela

A escolha da ferramenta importa menos do que a direção da conexão e o estado da sua chave, por isso ela vem em sexto lugar e não em primeiro. Dito isso, as diferenças são reais, e escolher o formato errado para o trabalho cria retrabalho depois.

| Ferramenta | Criptografa antes de sair | Deduplica | Destino append-only | Onde se encaixa |
| --- | --- | --- | --- | --- |
| **restic** | Sim, repositório inteiro | Sim | Sim, via seu servidor REST | A escolha padrão. Fala SFTP, object storage e seu próprio servidor, então o destino pode ser quase qualquer coisa |
| **BorgBackup** | Sim, repositório inteiro | Sim, a melhor do grupo | Sim, nativamente via SSH | Um destino Linux acessado via SSH. Imbatível quando o dado é grande e repetitivo |
| **rsync com rotações** | Não — o destino vê tudo | Parcial, via hardlinks | Não | Espelhamento para uma máquina que você controla totalmente, quando restaurações parciais instantâneas importam mais que privacidade |
| **rclone** | Só com rclone crypt | Não | Depende do provedor de armazenamento | Mover um arquivo que já existe para object storage, ou entre provedores |
| **Replicação ZFS** | Só com um dataset criptografado | Sim, em nível de bloco | Via permissões de snapshot | Replicar entre duas máquinas ZFS. Muito rápido, muito rígido nas duas pontas |
| **tar com age ou GPG** | Sim, se você criptografar o arquivo | Não | Não se aplica | Arquivos pequenos, ocasionais, guardados para sempre, onde simplicidade vence eficiência |

Para um único servidor, restic para um segundo VPS é o caminho mais curto até algo correto. Para uma seedbox, um arquivo de mídia ou qualquer coisa com muitos arquivos grandes e parecidos, a deduplicação do Borg é a diferença entre um disco cheio e um disco confortável — o [guia de seedbox](https://servhidden.com/pt/guides/seedbox-setup-guide) detalha melhor o lado de armazenamento dessa carga de trabalho.

## Tudo o que está rodando não é um arquivo

O backup corrompido mais comum do mundo é uma cópia direta de arquivo de um banco de dados vivo. Ela completa sem erro nenhum, pesa o tamanho certo, e ao restaurar vira uma tabela que o engine se recusa a abrir. O banco estava no meio de uma escrita quando a cópia passou por ele; o que você salvou é a foto de uma página sendo virada.

Três saídas, em ordem crescente de esforço. Dump: mysqldump --single-transaction gera um dump consistente do InnoDB sem travar quem escreve, e pg_dump faz o mesmo para o PostgreSQL. Snapshot: congele o sistema de arquivos ou tire um snapshot de LVM ou ZFS, copie a partir do snapshot, libere-o — é assim que se lida com conjuntos de dados grandes demais para dar dump toda noite. Ou pare: para um serviço pequeno, dois minutos de indisponibilidade às 4h da manhã é uma estratégia de consistência perfeitamente respeitável, e é a única sem casos extremos.

A mesma lógica vai além dos bancos de dados. A camada gravável de um container é descartável, mas seus volumes não são, e o arquivo docker compose e o ambiente ao lado deles também não — um backup que restaura os dados mas não a definição deixa você reconstruindo a stack de memória. Filas de mensagens, Redis com persistência ativada, e um spool de e-mail sendo escrito por um MTA merecem o mesmo tratamento: parar, tirar snapshot ou dar dump, mas nunca copiar direto e torcer.

## O que fazer backup, e as partes que todo mundo esquece

A maioria das pessoas faz backup do óbvio — o banco de dados e o diretório da aplicação — e reconstrói o resto na mão, sob pressão. É na reconstrução que as horas se vão. Um backup que te devolve a um sistema funcionando, em vez de uma pilha de dados corretos, inclui a camada chata:

- /etc por completo, mais as units e timers do systemd que você escreveu, e quaisquer crontabs que vivam fora dele.

- Certificados TLS e suas chaves privadas, ou no mínimo a chave da conta ACME, para que os certificados renovem em vez de recomeçar do zero.

- Regras de firewall e a lista de pacotes, que juntas reconstroem a forma da máquina mais rápido do que qualquer memória dela.

- Segredos de aplicação e arquivos de ambiente — aqueles deliberadamente excluídos do seu repositório de código, e por isso presentes em nenhum outro lugar.

- Registros DNS exportados como texto, incluindo entradas de DNS reverso e PTR, que vivem no provedor e não no servidor.

**Algumas chaves não são dados — são identidade.** A chave privada de um serviço onion do Tor *é* o endereço: perca-a e o site não consegue voltar com o mesmo [nome .onion](https://servhidden.com/pt/guides/how-to-host-a-tor-hidden-service), não importa mais o que você tenha restaurado. Uma chave de servidor WireGuard significa reemitir toda configuração de cliente que você já distribuiu. A chave DKIM de um servidor de e-mail significa um novo seletor e um recomeço na [entregabilidade](https://servhidden.com/pt/guides/offshore-mail-server-setup). A seed e o estado dos canais de um node Lightning podem significar fundos, não arquivos — o [guia de hospedagem de nodes](https://servhidden.com/pt/guides/crypto-node-hosting-guide) é explícito sobre isso. Copie essas chaves separadamente, mantenha-as offline, e trate-as como mais valiosas do que os dados que protegem.

## Um restore que você nunca testou é um boato

O software de backup se autoavalia, e é honesto sobre a coisa errada. "Snapshot concluído" significa que dados foram gravados num repositório. Isso não diz nada sobre se o repositório pode ser lido numa máquina que não é esta, por uma pessoa que não lembra o que configurou há onze meses.

Comece pelas checagens de integridade baratas — restic check --read-data-subset=5% ou borg check --verify-data numa rotina agendada — e entenda que elas verificam o arquivo, não a sua capacidade de usá-lo. O teste de verdade é diferente e leva uma tarde, uma única vez. Contrate um servidor novo cobrado por hora, numa localização que você não usa normalmente. Restaure nele com nada além do endereço do repositório, a senha, e suas próprias anotações. Suba o serviço. Cronometre tudo. Depois destrua a máquina. Custo total: alguns dólares, e é o único exercício que produz um número em que você pode confiar.

O que ele expõe com confiabilidade nunca são os dados. É o pacote faltando que ninguém anotou, a configuração que vivia fora dos caminhos copiados, a senha que só existiu no histórico de shell do servidor que você está tentando substituir, e a versão da ferramenta que lê o formato do seu repositório. Cada uma dessas coisas é trivial de corrigir com antecedência e péssima de descobrir durante uma interrupção.

Anote os dois números que o teste te dá: quanto tempo um restore levou, e quanto trabalho a rotina pode perder. Essa é a política de backup. Tudo acima é detalhe de implementação a serviço desses dois números.

## Automatizando para que continue acontecendo

Rode o job a partir de um timer do systemd, em vez de cron. Você ganha logs num lugar só, um registro real da última execução, e um agendamento que sobrevive a reboots — nada disso o cron te dá sem trabalho extra. Mantenha a senha fora do próprio arquivo de unit, que qualquer pessoa com acesso ao shell consegue ler direto com systemctl cat.

Depois resolva o modo de falha que realmente pega as pessoas, que não é um erro, e sim o silêncio. Um backup que parou de rodar há seis semanas parece exatamente igual a um que rodou perfeitamente, porque os dois não produzem saída nenhuma. **Alerte sobre ausência, não sobre falha.** Faça o job avisar um monitor quando tiver sucesso, e deixe o monitor reclamar quando o aviso não chegar — e coloque esse monitor em qualquer lugar, menos no servidor que ele observa, já que uma máquina fora do ar não consegue avisar que está fora do ar.

Defina a retenção de forma deliberada, não por padrão. Algo como --keep-daily 7 --keep-weekly 4 --keep-monthly 6 cobre os erros que você percebe hoje à noite e a corrupção que você percebe na primavera, sem crescer para sempre. Rode a limpeza do lado do destino se você já foi para append-only, que é justamente o ponto de ter ido para append-only. O volume de transferência raramente é a restrição na nossa rede — a banda é ilimitada em todos os planos — então programe pensando em consistência, não em cota, e confira o horário contra o seu próprio período de baixo movimento. Os hábitos mais amplos em torno disso tudo estão no [guia de OpSec de servidor](https://servhidden.com/pt/guides/server-opsec-staying-anonymous).

## A versão resumida

Se você não fizer mais nada com esta página, faça estas seis coisas, mais ou menos nesta ordem:

- Coloque uma cópia num segundo provedor, numa segunda jurisdição, paga da mesma forma privada que a primeira.

- Torne essa cópia append-only, ou puxe-a a partir do destino, para que um servidor comprometido não consiga destruí-la.

- Deixe a ferramenta criptografar na origem, e mantenha a chave fora das duas máquinas envolvidas.

- Dê dump nos bancos de dados e pare ou tire snapshot de tudo que estiver rodando; nunca copie o estado ao vivo diretamente.

- Faça backup das chaves de identidade separadamente — onion, WireGuard, DKIM, seeds de node — porque essas não podem ser regeneradas.

- Restaure num servidor descartável uma vez, cronometre, e anote o que estava faltando.

Nada disso é exótico, e nada disso toma um fim de semana. É uma tarde de configuração e um teste, contra uma categoria de perda que encerra projetos. Numa plataforma que deliberadamente não guarda nada sobre você, a cópia que você mesmo fez é a única que existe — que é o custo do arranjo, e um custo justo. [Suba um segundo servidor](https://servhidden.com/pt/vps) numa jurisdição que não seja a sua primeira, e dê ao backup de hoje à noite um lugar para pousar.





Perguntas frequentes

## Backup de VPS — perguntas frequentes





### 01
A ServHidden faz backup do meu VPS?



Não, e isso é deliberado, não uma omissão. Nossa política de retenção estabelece que nenhum backup é retido, que os dados do servidor são destruídos em até 24 horas após o encerramento, e que os discos são apagados criptograficamente em vez de formatados. Guardar uma cópia dos seus dados depois que você pediu para removê-los contradiria a razão de existir da plataforma. Tudo que você quiser que sobreviva ao servidor precisa ser copiado para fora dele por você, idealmente para um segundo provedor numa segunda jurisdição.





### 02
Snapshot é a mesma coisa que backup?



Não. Um snapshot compartilha todos os domínios de falha com o servidor de onde veio — o mesmo provedor, a mesma conta, o mesmo país, muitas vezes o mesmo armazenamento. É excelente para desfazer uma atualização que deu errado, e inútil contra a perda da conta, do provedor ou da máquina. Trate snapshots como um botão de desfazer e backups como seguro; eles resolvem problemas diferentes e você quer os dois.





### 03
restic ou BorgBackup: qual devo usar?



restic se o destino puder ser object storage, SFTP ou algo que você ainda não escolheu, porque ele fala com o maior número de back-ends. BorgBackup se o destino for uma única máquina Linux acessada via SSH e o dado for grande e repetitivo, porque sua deduplicação é a mais forte do grupo. Os dois criptografam na origem antes de qualquer coisa sair da máquina, e os dois suportam um destino append-only, o que importa muito mais do que a escolha entre eles.





### 04
Como impedir que um invasor apague meus backups?



Remova a capacidade, não o motivo. Ou torne o destino append-only, para que as credenciais no servidor de produção possam adicionar dados mas nunca removê-los, ou inverta a conexão para que o host de backup puxe da produção e o servidor de produção não guarde credencial nenhuma. Apagar os backups antes de se anunciar é prática padrão para quem faz isso comercialmente, e uma cópia que seu invasor consegue apagar não é uma segunda cópia.





### 05
Onde deve ficar a segunda cópia do backup?



Num provedor diferente, numa jurisdição diferente, e pago de forma tão privada quanto o seu servidor de produção. Os eventos que derrubam as duas cópias ao mesmo tempo raramente são físicos — são uma conta perdida, um provedor tendo uma semana ruim, ou um instrumento jurídico que alcança um país e não outro. Dois servidores no mesmo rack são uma cópia com passos extras. Como as ferramentas criptografam na origem, o segundo host não precisa ser um em que você confie.





### 06
Com que frequência devo fazer backup?



Trabalhe de trás para frente, a partir de quanto trabalho você aceita refazer. Um blog pode perder um dia sem que ninguém perceba; uma loja não pode perder uma hora de pedidos. Backup toda noite é o padrão certo para a maioria dos setups de servidor único, com dumps de banco de dados mais frequentes se as escritas forem valiosas. O que importa mais do que a frequência é a profundidade da retenção: corrupção costuma ser percebida semanas depois, então mantenha histórico suficiente para alcançar um ponto anterior ao início do problema.





### 07
Um backup criptografado é seguro num servidor que não controlo?



Para o conteúdo, sim — restic e Borg criptografam antes de os dados saírem da origem, então o destino armazena blobs que não consegue ler, e a chave nunca viaja. O que o destino chega a saber é metadado: mais ou menos quanto dado você tem, como ele muda, e quando seus jobs rodam. Isso costuma ser aceitável. Se não for, varie o horário e mantenha o repositório numa máquina cuja titularidade não esteja ligada à de produção.





### 08
O que acontece se eu perder a senha do backup?



O arquivo se foi, permanentemente, sem recurso de ninguém. Essa é a perda total mais comum de todo o assunto, e a única falha sem caminho de recuperação. Mantenha a senha em algum lugar fora de todas as máquinas envolvidas, prefira papel a uma conta que você também pode perder, e adicione uma segunda chave ao repositório para que uma senha esquecida seja um incômodo, não o fim do arquivo.




Guias relacionados

## Continue lendo


[### Como Escolher uma Jurisdição de Hospedagem Offshore em 2026

Compra


Um framework de decisão prático para escolher uma jurisdição offshore: lei de retenção de dados, exposição a MLAT, postura sobre DMCA, velocidade dos tribunais e aplicação real — país a país.


FAQ com 6 perguntas](https://servhidden.com/pt/guides/choosing-an-offshore-jurisdiction)
[### VPS vs Servidor Dedicado para Cargas de Trabalho com Privacidade Crítica

Compra


Quando um VPS é suficiente, quando a multilocação é um risco, e quando o bare metal é a única resposta honesta. Isolamento de hardware, risco de hypervisor e custo vs modelo de ameaça.


FAQ com 6 perguntas](https://servhidden.com/pt/guides/vps-vs-dedicated-for-privacy)
[### VPN Auto-Hospedada em VPS Sem KYC: WireGuard vs OpenVPN

Operações


Por que uma VPN auto-hospedada supera os provedores comerciais e como WireGuard e OpenVPN realmente se comparam em privacidade, desempenho e risco operacional em 2026.


FAQ com 6 perguntas](https://servhidden.com/pt/guides/self-hosted-vpn-wireguard-vs-openvpn)
[### RTX 4090 vs H100 SXM5 para Inferência de IA (e Onde o RTX 5090 se Encaixa)

Compra


Guia de decisão de compra: qual GPU NVIDIA para LLM auto-hospedado, imagem, vídeo, voz e cargas de trabalho de ajuste fino em 2026. RTX 4090 vs RTX 5090 vs H100 SXM5 vs H100 duplo — VRAM, throughput, $/token, quando cada um vence.


FAQ com 6 perguntas](https://servhidden.com/pt/guides/rtx-4090-vs-h100-for-ai-inference)
[### RDP Windows Offshore para Trading Forex com MT4 / MT5 / cTrader

Operações


Guia completo: por que um RDP Windows para trading forex, como escolher uma jurisdição offshore de baixa latência, configuração de MT4 / MT5 / cTrader / Expert Advisor, latência para servidores de corretora e o caminho de checkout sem KYC.


FAQ com 6 perguntas](https://servhidden.com/pt/guides/offshore-windows-rdp-for-forex-trading)
[### Hospedagem DMCA-Ignorada Explicada: O Que Realmente Significa em 2026

Compra


O que a hospedagem "DMCA ignorado" realmente oferece, quais jurisdições de fato a sustentam, os tipos de carga que a necessitam, e as armadilhas de direitos autorais que o termo não cobre.


FAQ com 6 perguntas](https://servhidden.com/pt/guides/dmca-ignored-hosting-explained)
[### Registro Anônimo de Domínio com Cripto: Privacidade WHOIS em 2026

Privacidade


Um guia prático para 2026 sobre como registrar domínios sem revelar sua identidade: regimes WHOIS por TLD, escolha de registrador, opções de pagamento em cripto e os erros operacionais que ainda assim vão te expor.


FAQ com 6 perguntas](https://servhidden.com/pt/guides/anonymous-domain-registration-with-crypto)
[### Pagamentos Cripto para Hospedagem: Monero vs Bitcoin vs USDT

Privacidade


Como a escolha da moeda afeta o que seu host aprende sobre você. Privacidade, taxas, finalidade e exposição à análise de blockchain para XMR, BTC e USDT — com uma recomendação clara.


FAQ com 6 perguntas](https://servhidden.com/pt/guides/crypto-payments-monero-vs-bitcoin-vs-usdt)
[### Hospedagem offshore é realmente anônima? Uma resposta honesta

Privacidade


Hospedagem offshore sem KYC remove a identidade que um provedor comum coleta — mas "anônimo" depende do pagamento, dos logs do provedor e da sua própria segurança operacional. Veja o que é realmente rastreável.


FAQ com 6 perguntas](https://servhidden.com/pt/guides/is-offshore-hosting-truly-anonymous)
[### A primeira hora de hardening do VPS: um checklist

Operações


Um checklist concreto e ordenado para proteger um VPS novo em menos de uma hora: chaves SSH, firewall, fail2ban, atualizações automáticas e a redução da superfície de ataque que barra a maioria dos ataques oportunistas.


FAQ com 6 perguntas](https://servhidden.com/pt/guides/first-hour-vps-hardening-checklist)
[### O Que É Hospedagem Sem KYC? Definição, Legalidade e Como Funciona

Privacidade


A hospedagem sem KYC permite alugar um servidor sem nenhuma verificação de identidade — sem nome, sem e-mail, sem documento. Aqui está exatamente o que isso significa, como funciona tecnicamente, se é legal e como escolher um provedor de verdade.


FAQ com 6 perguntas](https://servhidden.com/pt/guides/what-is-no-kyc-hosting)
[### Hospedagem Offshore É Legal? A Resposta Honesta para 2026

Compra


Hospedagem offshore é legal — para você e para o provedor. Aqui está o que o termo realmente significa, onde a linha legal de fato se situa, os mitos que vale descartar, e como utilizá-la de forma responsável.


FAQ com 6 perguntas](https://servhidden.com/pt/guides/is-offshore-hosting-legal)
[### Como Pagar por Hospedagem com Monero (XMR) — Passo a Passo

Privacidade


Um guia passo a passo para pagar por um VPS ou servidor dedicado com Monero (XMR): por que o XMR é a opção mais privada, como obtê-lo e como funciona o processo de pagamento — da fatura ao servidor em funcionamento em minutos.


FAQ com 6 perguntas](https://servhidden.com/pt/guides/how-to-pay-for-hosting-with-monero)
[### Como Hospedar um Site de Forma Anônima — Guia Prático 2026

Privacidade


Um guia prático e em camadas para hospedar um site sem nenhuma identidade vinculada: a conta, o pagamento, o domínio, a jurisdição, a sua conexão e o conteúdo — cada camada explicada.


FAQ com 6 perguntas](https://servhidden.com/pt/guides/how-to-host-a-website-anonymously)
[### Como Configurar uma VPN WireGuard em um VPS — Guia Passo a Passo

Operações


Monte sua própria VPN privada em um VPS com WireGuard: por que uma VPN auto-hospedada supera as comerciais, o processo completo desde a instalação até o primeiro cliente conectado, e como reforçar a segurança.


FAQ com 6 perguntas](https://servhidden.com/pt/guides/how-to-set-up-wireguard-vpn-on-a-vps)
[### Como Hospedar um LLM em um Servidor GPU — Guia 2026

Operações


Execute seu próprio modelo de linguagem em um servidor GPU alugado: por que hospedar seu próprio LLM supera uma API, qual GPU e modelo escolher, a configuração com Ollama ou vLLM, e quanto custa.


FAQ com 6 perguntas](https://servhidden.com/pt/guides/self-host-an-llm-on-a-gpu-server)
[### Hospedagem Bulletproof vs Hospedagem Offshore — Qual é a Diferença?

Compra


Hospedagem bulletproof e hospedagem offshore são constantemente confundidas — e não são a mesma coisa. Veja a diferença real, por que isso importa e qual das duas você realmente precisa.


FAQ com 6 perguntas](https://servhidden.com/pt/guides/bulletproof-vs-offshore-hosting)
[### Como Comprar um VPS com Bitcoin — Passo a Passo (2026)

Compra


Um guia completo para iniciantes sobre como comprar um VPS com Bitcoin: como obter BTC, escolher um plano, pagar a fatura e o que você recebe — um servidor funcionando sem cartão e sem nome associado.


FAQ com 6 perguntas](https://servhidden.com/pt/guides/how-to-buy-a-vps-with-bitcoin)
[### Melhores Países para Hospedagem com DMCA Ignorado em 2026

Compra


Onde hospedar quando você quer servidores além do alcance fácil das remoções ao estilo americano: as jurisdições que funcionam, o que DMCA ignorado realmente significa e como escolher.


FAQ com 6 perguntas](https://servhidden.com/pt/guides/best-countries-for-dmca-ignored-hosting)
[### Como Hospedar um Serviço Oculto Tor (Site .onion) — Guia 2026

Operações


Configure um serviço onion Tor em um VPS: o que é um serviço oculto, por que é a forma mais robusta de hospedagem anônima, o processo completo de configuração e como mantê-lo verdadeiramente anônimo.


FAQ com 6 perguntas](https://servhidden.com/pt/guides/how-to-host-a-tor-hidden-service)
[### Configuração de Servidor de E-mail Offshore — Hospede Seu Próprio E-mail Privado em 2026

Operações


Execute seu próprio servidor de e-mail privado em um VPS offshore: por que hospedar e-mail você mesmo, o que é necessário, a configuração prática com uma stack de e-mail completa e como garantir a entregabilidade.


FAQ com 6 perguntas](https://servhidden.com/pt/guides/offshore-mail-server-setup)
[### Guia de Hospedagem de Nó de Criptomoeda — Execute um Nó Blockchain em um VPS

Operações


Como hospedar um nó blockchain em um servidor: por que executar seu próprio nó, dimensionamento do servidor para Bitcoin, Ethereum, Monero e outros, a configuração e como manter a privacidade.


FAQ com 6 perguntas](https://servhidden.com/pt/guides/crypto-node-hosting-guide)
[### Hospedagem GPU para Stable Diffusion — Rode Seu Próprio Servidor de Imagens

Operações


Rode o Stable Diffusion no seu próprio servidor GPU: por que hospedar geração de imagens localmente, qual GPU escolher, como configurar com uma interface web e quanto custa em comparação a um serviço hospedado.


FAQ com 6 perguntas](https://servhidden.com/pt/guides/gpu-hosting-for-stable-diffusion)
[### OpSec para Servidores — Como Manter o Anonimato ao Operar um Servidor

Privacidade


Segurança operacional para quem administra um servidor anônimo: os erros que expõem identidades, os hábitos que os previnem e como manter identidades verdadeiramente separadas.


FAQ com 6 perguntas](https://servhidden.com/pt/guides/server-opsec-staying-anonymous)
[### Guia de Configuração de Seedbox — Monte Sua Própria Seedbox Privada em 2026

Operações


Como montar sua própria seedbox em um servidor: o que é uma seedbox, como dimensioná-la, instalar um cliente torrent com interface web e mantê-la privada e segura.


FAQ com 6 perguntas](https://servhidden.com/pt/guides/seedbox-setup-guide)
[### Como Contornar a Censura por DPI com Seu Próprio VPS (Guia 2026)

Privacidade


Sua VPN parou de funcionar? Como contornar a censura por DPI com seu próprio VPS: o que a inspeção profunda de pacotes realmente detecta, qual dos cinco protocolos de 2026 vence qual tipo de bloqueio, e um passo a passo completo de VLESS+REALITY.


FAQ com 6 perguntas](https://servhidden.com/pt/guides/bypass-dpi-censorship-with-your-own-vps)
[### Criptografia de Disco Completo em um VPS: LUKS e o Que Ela Protege

Operações


Como criptografar um VPS com LUKS: volumes de dados, raiz completa com desbloqueio via SSH, as configurações que importam em um servidor pequeno, e o que a criptografia de disco realmente impede.


FAQ com 8 perguntas](https://servhidden.com/pt/guides/full-disk-encryption-on-a-vps)
[### Ocultar o IP do Servidor de Origem: CDNs, Proxies Reversos e o Que Ainda Vaza

Privacidade


Colocar ou não um CDN na frente de um servidor offshore: o que ele esconde, a central de reclamações que você herda, as seis formas como o IP de origem vaza, e como auditar o seu.


FAQ com 8 perguntas](https://servhidden.com/pt/guides/hiding-your-origin-server-ip)
[### Hospedar Servidor Matrix Próprio: Federação e Metadados

Operações


O que um servidor Matrix próprio realmente muda: Synapse ou Conduit, o server_name que você nunca poderá trocar, e a mídia que lota o disco rapidamente.


FAQ com 8 perguntas](https://servhidden.com/pt/guides/self-host-a-matrix-server)
[### Como Migrar um Site para Hospedagem Offshore sem Downtime

Operações


A ordem que torna a migração de host tediosa: baixar o TTL do DNS dias antes, rodar os dois servidores em paralelo, congelar as escritas por minutos em vez de horas — e limpar o rastro de DNS passivo, Certificate Transparency e WHOIS que a mudança deixa para trás.


FAQ com 8 perguntas](https://servhidden.com/pt/guides/migrate-website-to-offshore-hosting)
[### How to Self-Host a Crypto Payment Gateway with BTCPay Server

Operações


Run your own non-custodial checkout on an offshore VPS: BTCPay Server, a pruned Bitcoin node, Lightning and Monero — how to size the disk, why the private keys must never touch the machine, and where KYC quietly reappears at the cash-out.


FAQ com 8 perguntas](https://servhidden.com/pt/guides/self-host-a-crypto-payment-gateway)




## Dê ao backup de hoje à noite um lugar para pousar



Sete jurisdições, banda ilimitada em todos os planos, e servidores a partir de $7.50/mês que funcionam como destinos competentes para restic ou Borg. Sem KYC, sem e-mail, só cripto — tanto para o destino de backup quanto para a produção.


[Ver Planos VPS](https://servhidden.com/pt/vps)
[Servidores Dedicados](https://servhidden.com/pt/dedicated)
[Todas as localizações](https://servhidden.com/pt/locations)


## Structured data (JSON-LD)

```json
{
    "@context": "https://schema.org",
    "@type": "Organization",
    "@id": "https://servhidden.com/#organization",
    "name": "ServHidden",
    "url": "https://servhidden.com",
    "description": "VPS e servidores dedicados offshore em 7 jurisdições privacy-friendly. Sem KYC, sem logs, apenas cripto. Privacidade por arquitetura.",
    "logo": {
        "@type": "ImageObject",
        "url": "https://servhidden.com/ServHidden.webp",
        "width": 512,
        "height": 512
    },
    "foundingDate": "2025",
    "areaServed": [
        {
            "@type": "Country",
            "name": "Iceland"
        },
        {
            "@type": "Country",
            "name": "Panama"
        },
        {
            "@type": "Country",
            "name": "Moldova"
        },
        {
            "@type": "Country",
            "name": "Romania"
        },
        {
            "@type": "Country",
            "name": "Switzerland"
        },
        {
            "@type": "Country",
            "name": "Netherlands"
        },
        {
            "@type": "Country",
            "name": "Russia"
        }
    ],
    "knowsAbout": [
        "Offshore hosting",
        "Offshore VPS",
        "Bare-metal dedicated servers",
        "DMCA-ignored hosting",
        "No KYC hosting",
        "Cryptocurrency payments",
        "Privacy engineering",
        "Token-based authentication",
        "Anonymous domain name registration",
        "No-KYC domain registrar",
        "WHOIS privacy",
        "Cheap .com domains",
        "Crypto-paid domain names",
        "NVIDIA GPU compute",
        "Windows RDP hosting",
        "Agentic commerce"
    ],
    "contactPoint": {
        "@type": "ContactPoint",
        "contactType": "customer support",
        "url": "https://servhidden.com/contact",
        "availableLanguage": [
            "en",
            "ru",
            "zh",
            "es",
            "fr",
            "de",
            "pt",
            "ar",
            "ja",
            "ko",
            "hi",
            "id",
            "it",
            "tr",
            "fa",
            "vi"
        ]
    },
    "sameAs": [
        "https://servhidden.com/canary",
        "https://servhidden.com/press"
    ]
}
```

```json
{
    "@context": "https://schema.org",
    "@type": "WebSite",
    "@id": "https://servhidden.com/#website",
    "url": "https://servhidden.com",
    "name": "ServHidden",
    "publisher": {
        "@id": "https://servhidden.com/#organization"
    },
    "inLanguage": [
        "en",
        "ru",
        "zh",
        "es",
        "fr",
        "de",
        "pt",
        "ar",
        "ja",
        "ko",
        "hi",
        "id",
        "it",
        "tr",
        "fa",
        "vi"
    ]
}
```

```json
{
    "@context": "https://schema.org",
    "@type": "Article",
    "headline": "Backup de VPS: Criptografado, Externo e Restaurável de Verdade",
    "description": "Sua hospedagem não guarda backup. O que realmente destrói servidores, por que backup via push morre junto com a origem, restic vs Borg, e como testar um restore.",
    "image": "https://servhidden.com/assets/img/guides/vps-backup-strategy.webp?v=1787218773",
    "author": {
        "@type": "Organization",
        "@id": "https://servhidden.com/#editorial",
        "name": "ServHidden Editorial",
        "url": "https://servhidden.com/about",
        "description": "Operator-side editorial team writing about offshore hosting jurisdictions, offshore server architecture, self-hosted privacy stacks and crypto payments.",
        "knowsAbout": [
            "Offshore hosting jurisdictions",
            "Data retention law",
            "MLAT and judicial cooperation",
            "WireGuard and OpenVPN deployment",
            "Tor relay operation",
            "Monero and Bitcoin payment privacy",
            "KVM virtualization and bare-metal hosting",
            "DMCA-ignored hosting"
        ],
        "parentOrganization": {
            "@id": "https://servhidden.com/#organization"
        }
    },
    "publisher": {
        "@id": "https://servhidden.com/#organization"
    },
    "datePublished": "2026-08-20T00:00:00+00:00",
    "dateModified": "2026-08-20T00:00:00+00:00",
    "mainEntityOfPage": "https://servhidden.com/guides/vps-backup-strategy",
    "inLanguage": "pt",
    "keywords": "backup de VPS, backup de VPS criptografado, restic vs BorgBackup, regra 3-2-1 de backup, backup externo (off-site), backup append-only, backup de servidor sem KYC, como testar um restore",
    "articleSection": "Operações",
    "wordCount": 3706
}
```

```json
{
    "@context": "https://schema.org",
    "@type": "FAQPage",
    "mainEntity": [
        {
            "@type": "Question",
            "name": "A ServHidden faz backup do meu VPS?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "Não, e isso é deliberado, não uma omissão. Nossa política de retenção estabelece que nenhum backup é retido, que os dados do servidor são destruídos em até 24 horas após o encerramento, e que os discos são apagados criptograficamente em vez de formatados. Guardar uma cópia dos seus dados depois que você pediu para removê-los contradiria a razão de existir da plataforma. Tudo que você quiser que sobreviva ao servidor precisa ser copiado para fora dele por você, idealmente para um segundo provedor numa segunda jurisdição."
            }
        },
        {
            "@type": "Question",
            "name": "Snapshot é a mesma coisa que backup?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "Não. Um snapshot compartilha todos os domínios de falha com o servidor de onde veio — o mesmo provedor, a mesma conta, o mesmo país, muitas vezes o mesmo armazenamento. É excelente para desfazer uma atualização que deu errado, e inútil contra a perda da conta, do provedor ou da máquina. Trate snapshots como um botão de desfazer e backups como seguro; eles resolvem problemas diferentes e você quer os dois."
            }
        },
        {
            "@type": "Question",
            "name": "restic ou BorgBackup: qual devo usar?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "restic se o destino puder ser object storage, SFTP ou algo que você ainda não escolheu, porque ele fala com o maior número de back-ends. BorgBackup se o destino for uma única máquina Linux acessada via SSH e o dado for grande e repetitivo, porque sua deduplicação é a mais forte do grupo. Os dois criptografam na origem antes de qualquer coisa sair da máquina, e os dois suportam um destino append-only, o que importa muito mais do que a escolha entre eles."
            }
        },
        {
            "@type": "Question",
            "name": "Como impedir que um invasor apague meus backups?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "Remova a capacidade, não o motivo. Ou torne o destino append-only, para que as credenciais no servidor de produção possam adicionar dados mas nunca removê-los, ou inverta a conexão para que o host de backup puxe da produção e o servidor de produção não guarde credencial nenhuma. Apagar os backups antes de se anunciar é prática padrão para quem faz isso comercialmente, e uma cópia que seu invasor consegue apagar não é uma segunda cópia."
            }
        },
        {
            "@type": "Question",
            "name": "Onde deve ficar a segunda cópia do backup?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "Num provedor diferente, numa jurisdição diferente, e pago de forma tão privada quanto o seu servidor de produção. Os eventos que derrubam as duas cópias ao mesmo tempo raramente são físicos — são uma conta perdida, um provedor tendo uma semana ruim, ou um instrumento jurídico que alcança um país e não outro. Dois servidores no mesmo rack são uma cópia com passos extras. Como as ferramentas criptografam na origem, o segundo host não precisa ser um em que você confie."
            }
        },
        {
            "@type": "Question",
            "name": "Com que frequência devo fazer backup?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "Trabalhe de trás para frente, a partir de quanto trabalho você aceita refazer. Um blog pode perder um dia sem que ninguém perceba; uma loja não pode perder uma hora de pedidos. Backup toda noite é o padrão certo para a maioria dos setups de servidor único, com dumps de banco de dados mais frequentes se as escritas forem valiosas. O que importa mais do que a frequência é a profundidade da retenção: corrupção costuma ser percebida semanas depois, então mantenha histórico suficiente para alcançar um ponto anterior ao início do problema."
            }
        },
        {
            "@type": "Question",
            "name": "Um backup criptografado é seguro num servidor que não controlo?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "Para o conteúdo, sim — restic e Borg criptografam antes de os dados saírem da origem, então o destino armazena blobs que não consegue ler, e a chave nunca viaja. O que o destino chega a saber é metadado: mais ou menos quanto dado você tem, como ele muda, e quando seus jobs rodam. Isso costuma ser aceitável. Se não for, varie o horário e mantenha o repositório numa máquina cuja titularidade não esteja ligada à de produção."
            }
        },
        {
            "@type": "Question",
            "name": "O que acontece se eu perder a senha do backup?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "O arquivo se foi, permanentemente, sem recurso de ninguém. Essa é a perda total mais comum de todo o assunto, e a única falha sem caminho de recuperação. Mantenha a senha em algum lugar fora de todas as máquinas envolvidas, prefira papel a uma conta que você também pode perder, e adicione uma segunda chave ao repositório para que uma senha esquecida seja um incômodo, não o fim do arquivo."
            }
        }
    ]
}
```

```json
{
    "@context": "https://schema.org",
    "@type": "BreadcrumbList",
    "itemListElement": [
        {
            "@type": "ListItem",
            "position": 1,
            "name": "Início",
            "item": "https://servhidden.com/pt/"
        },
        {
            "@type": "ListItem",
            "position": 2,
            "name": "Guias de Hospedagem com Privacidade",
            "item": "https://servhidden.com/pt/guides"
        },
        {
            "@type": "ListItem",
            "position": 3,
            "name": "Backup de VPS: Criptografado, Externo e Restaurável de Verdade",
            "item": "https://servhidden.com/pt/guides/vps-backup-strategy"
        }
    ]
}
```