Categoria: Cópias de segurança

Quase todas as empresas acreditam ter cópias de segurança. Muito poucas têm uma cópia que as salva de verdade no dia em que precisam dela. A diferença não se nota no dia a dia: nota-se às três da manhã, quando o servidor não arranca, o ransomware cifrou os ficheiros ou alguém apagou a pasta errada, e é preciso restaurar a sério. É aí que a maioria descobre que o seu backup falhava em silêncio há meses, que ninguém o tinha testado alguma vez ou que estava no mesmo sítio que os dados que acabaram de perder.

Este artigo é sobre isso mesmo: sobre porque é que a cópia que julga ter quase nunca é a que o salva, e sobre como contratar um backup como serviço para empresas lhe tira o problema de cima a sério. Não com mais discos, mas com cópias de segurança geridas, monitorizadas e testadas por alguém cujo trabalho é garantir que, no dia mau, recupera.

A cópia que julga ter vs. a que de facto o salva

Um backup não é um ficheiro que existe. É um processo que tem de funcionar do princípio ao fim: ser criado, ser guardado num sítio seguro e — o mais importante — poder ser restaurado. Quando qualquer um destes três elos se parte sem que ninguém dê por isso, tem a pior combinação possível: a falsa tranquilidade de se julgar protegido quando não está.

Estes são os três finais infelizes que vemos vezes sem conta:

• O backup que falha em silêncio. A tarefa está em erro há semanas ou meses, mas ninguém verifica os alertas. O disco encheu-se, mudou uma palavra-passe, partiu-se uma tarefa agendada. A cópia «existe», mas é de antes de tudo se ter partido.
• O backup que ninguém testa. Copia-se todos os dias, sim. Mas nunca se tentou restaurá-lo. No dia em que é preciso, verifica-se que o ficheiro está corrompido, incompleto ou que faltava justamente a base de dados que interessava.
• O backup que o ransomware cifra. A cópia está num disco USB ligado ao servidor ou numa pasta de rede visível. Quando o ataque entra, cifra os dados e também a cópia. Tinha backup; tinha-o ao lado de tudo o resto.

A cópia que não se testa não existe. E a cópia que o ransomware pode apagar não é uma cópia: é mais um ficheiro à espera da sua vez.

O que é o backup como serviço (BaaS) e porque lhe tira o problema de cima

O backup como serviço (ou BaaS, Backup as a Service) vira a abordagem do avesso. Em vez de a sua empresa comprar discos, configurar software e confiar que alguém se lembre de verificar se está tudo bem, contrata o resultado: os seus dados copiados, vigiados e recuperáveis, e o como fica a cargo de uma equipa especializada.

A chave não é a tecnologia, é a responsabilidade. Um backup gerido não é «instalar o software e pronto». É alguém a monitorizar cada tarefa todos os dias, a agir quando algo falha — antes de você dar por isso — e a comprovar periodicamente que os restauros funcionam. É a diferença entre ter uma ferramenta e ter um serviço que responde pelo resultado.

Para uma PME isto muda por completo a equação. A cópia de segurança deixa de depender de um colaborador com mil coisas em cima se lembrar de a verificar, e passa a fazer parte do seu IT externalizado: um processo profissional, documentado e com alguém por trás. É, literalmente, externalizar o seu IT no ponto onde errar mais dói.

O que deve cumprir um backup a sério (nem toda a cópia serve)

Nem todas as cópias de segurança protegem da mesma forma. Uma cópia a sério — a que aguenta um incêndio, um roubo, uma eliminação acidental e um ataque de ransomware — cumpre um conjunto de requisitos que não são negociáveis. Se o seu backup atual não assinala todas estas caixas, tem um problema, mesmo que ainda não o tenha notado:

• Regra 3-2-1. Pelo menos três cópias dos seus dados, em dois suportes diferentes e com uma fora das suas instalações. Assim, nenhum incidente único — fogo, roubo, falha de disco — leva tudo à frente.
• Cópias imutáveis e isoladas. Pelo menos uma cópia que não se pode modificar nem apagar durante um período, nem sequer com credenciais de administrador. É o que trava o ransomware: mesmo que comprometa a sua rede, não pode tocar nessa cópia.
• Retenção pensada. Não basta a cópia de ontem à noite. Precisa de poder voltar à semana passada ou ao mês passado, porque muitos ataques e erros demoram dias a ser detetados. Uma boa política de retenção dá-lhe versões à escolha.
• Cifragem na origem e no destino. Os dados viajam e são guardados cifrados. Se alguém intercetar a cópia ou aceder ao armazenamento, encontra ruído, não a sua informação.
• Testes periódicos de restauro. O requisito que quase ninguém cumpre e o único que de facto demonstra que o backup serve. Restaurar a fingir, de tempos a tempos, para saber que no dia real vai conseguir.

Cumprir tudo isto à mão, todos os dias, numa empresa que ainda por cima tem de se dedicar ao seu negócio, é extenuante e pouco fiável. Por isso faz tanto sentido que seja um serviço gerido para empresas a tratar disso, em vez de um procedimento caseiro.

Quanto tempo demora a recuperar: RTO e RPO, o que de facto importa

Quando algo cai, ninguém pergunta «temos backup?». A verdadeira pergunta é «quando volto a trabalhar e quantos dados perdi?». Estas duas perguntas têm nome técnico, e são as que deveriam mandar em qualquer decisão sobre cópias de segurança.

• RTO (tempo de recuperação): quanto tempo demora a voltar a estar operacional. Meia hora? Um dia? Três? Cada hora parado tem um custo real no seu negócio: vendas que não fecha, clientes à espera, equipas sem poder trabalhar.
• RPO (ponto de recuperação): quantos dados se pode permitir perder. Se copia uma vez por dia, no pior momento perde até 24 horas de trabalho. Se isso lhe dói, precisa de cópias mais frequentes.

Um backup barato e sem critério costuma ter um RTO péssimo: sim, os dados estão lá, mas restaurá-los e voltar a montar o sistema demora dias. Desenhar o backup ao contrário — partindo de quanto tempo e quantos dados cada parte da sua empresa pode perder — é o que transforma uma cópia num verdadeiro plano de recuperação. E é exatamente isso que faz um serviço gerido: define consigo esses objetivos e monta as cópias para os cumprir.

A oferta da MagicBoxDesk: backup gerido como serviço

Na MagicBoxDesk montamos e gerimos as suas cópias de segurança do princípio ao fim, para que deixe de se preocupar se funcionam. Não lhe vendemos um software e desejamos-lhe sorte: damos-lhe um backup como serviço com alguém a vigiá-lo todos os dias e a comprovar que restaura. Contrata-se com uma mensalidade consoante o volume de dados, sem surpresas, dentro do seu IT externalizado.

Isto é o que o serviço inclui:

• Desenho à medida da sua política de cópias segundo a regra 3-2-1, com os RTO e RPO de que o seu negócio precisa, não um modelo genérico.
• Cópias imutáveis e isoladas à prova de ransomware, cifradas na origem e no destino, com uma cópia sempre fora das suas instalações.
• Monitorização diária de cada tarefa e aviso proativo se algo falha: fica a saber por nós, não por um desastre.
• Testes periódicos de restauro documentados, para que saiba — com provas, não com fé — que no dia mau vai recuperar.
• Restauro assistido quando precisar, com a nossa equipa de suporte a levá-lo de volta à produção o mais depressa possível.
• Uma mensalidade por volume, clara e previsível, sem custos ocultos nem investimento inicial em hardware.

O backup não trabalha sozinho: encaixa com a nossa monitorização 24/7 e com o resto dos nossos serviços de IT geridos, de forma que a sua infraestrutura fica vigiada de ponta a ponta. O que ganha é simples de resumir: tranquilidade, conformidade e a certeza de que um incidente não se transforma numa crise.

Deixe de confiar na sorte com as suas cópias

A pergunta não é se tem backup. É se está seguro de que ele o vai salvar no dia em que precisar. Se para responder tem de cruzar os dedos, já sabe o que há a fazer. Na MagicBoxDesk encarregamo-nos de que as suas cópias funcionem, sejam testadas e aguentem um ataque, para que você trate do seu negócio e não de rezar.

Contrate o seu backup gerido com a MagicBoxDesk. Peça um orçamento sem compromisso e dizemos-lhe exatamente do que precisa para dormir descansado. Se preferir falar connosco, escreva-nos e vemos isso consigo.

A pergunta que de facto importa sobre as suas cópias de segurança não é «estão a ser feitas?». É «quando foi a última vez que restauraram uma a sério?». Nas auditorias, à primeira responde-se com um sim tranquilo e à segunda com um silêncio incómodo. Esse silêncio é o buraco: uma cópia que corre todas as noites sem dar erro parece uma cópia que funciona, e nem sempre é. Só sabe quando a restaura.

Este artigo é sobre a parte que quase ninguém faz: testar o restauro das cópias de segurança. Montar o ensaio, cronometrá-lo e encontrar o que falha a frio, não no dia do incêndio. Porque a cópia que nunca foi restaurada não é uma cópia: é uma promessa por verificar.

A cópia que nunca foi restaurada não é uma cópia

Um trabalho de cópia que termina a verde diz-lhe uma só coisa: que uns dados foram lidos e escritos noutro sítio. Não diz que estão completos, que o ficheiro não está corrompido, que a base de dados é consistente nem que consegue arrancar um sistema com eles. O «verde» mede a escrita, não a sua capacidade de recuperar. Confundi-los é a falsa sensação de segurança mais cara que existe em IT.

O dia em que precisa de restaurar nunca é uma terça-feira tranquila. É às três da manhã, com o ransomware já lá dentro ou o servidor sem arrancar e a direção a perguntar quando se volta a faturar. O pior momento para descobrir que a cópia da base de dados estava a meio, que faltava uma pasta ou que restaurar 2 TB pela sua linha demora três dias. O teste de restauro existe para que essas descobertas aconteçam hoje, a frio e sem custo, e não nessa altura.

Ninguém tem um problema de cópias de segurança. Toda a gente tem um problema de restauros. Só que a maioria ainda não sabe.

O que é um teste de restauro e com que frequência fazê-lo

Um teste de restauro é recuperar a fingir para saber que no dia a sério consegue mesmo: pega numa cópia, levanta-a num ambiente controlado e verifica que os dados estão lá, são consistentes e o sistema funciona. Não é olhar para o relatório nem confirmar que o ficheiro pesa o esperado; é tocar nos dados recuperados e confirmar que servem. E nem todos são iguais: cada nível testa uma coisa diferente e tem a sua frequência sensata.

• Restaurar um ficheiro ou pasta (mensal). O ensaio mais barato e o mais frequente na vida real: alguém apagou algo. Recupere um ficheiro de há uma semana e um de há um mês e confirme que abre. Valida a retenção, não apenas a cópia de ontem à noite.
• Restaurar uma caixa ou conta de correio (trimestral). Teste recuperar uma caixa completa ou mensagens concretas, sobretudo com Microsoft 365 ou Google Workspace, onde muita gente acredita — erradamente — que o fornecedor já lhe faz a cópia.
• Restaurar um servidor ou aplicação completa (trimestral ou semestral). Levantar o servidor de ficheiros, o ERP ou a base de dados em isolado e verificar que arranca e é coerente. É aqui que aparecem as dependências esquecidas: serviços que não sobem, licenças, ligações a outras máquinas.
• Recuperação bare-metal ou do ambiente inteiro (anual). Reconstruir de raiz, como se não restasse nada. O simulacro de desastre a sério: é aqui que se mede de facto o seu RTO e saem os tempos que ninguém tinha cronometrado.

A regra prática: quanto mais crítico e difícil de reconstruir, mais vezes se testa. E sempre que muda algo relevante — um servidor novo, uma migração — há que repetir o ensaio. Uma cópia que funcionava em janeiro pode estar partida desde a migração de março sem que ninguém dê por isso.

Como montar um teste de restauro a sério

Um teste mal feito dá uma tranquilidade ainda pior do que não testar. «Abri um PDF da cópia e via-se» não prova nada. Um ensaio a sério faz-se num ambiente isolado, segue um guião e produz um número medido, não uma sensação. Esta é a nossa checklist:

• Ambiente isolado, nunca produção. Restaura-se numa rede ou máquina separada, sem tocar nos sistemas vivos. Restaurar sobre a produção «para ver se vai» é a melhor forma de transformar um ensaio num incidente real.
• Partir do cenário, não do ficheiro. Defina que desastre simula: apagamento acidental, servidor perdido, ransomware que cifrou a produção e as cópias acessíveis. Restaure como faria nesse dia real.
• Verificar o dado, não que «existe». Que a base de dados abra e seja consistente, que os números batam certo, que a data da cópia seja a esperada. Um ficheiro restaurado que não abre é um ficheiro perdido com mais passos.
• Cronometrar o RTO a sério. Meça desde «decidimos restaurar» até «o serviço está utilizável», incluindo o que ninguém conta: descarregar a cópia de fora, decifrar, reinstalar, reconfigurar. Esse relógio é o seu RTO real, não o do folheto.
• Confirmar o RPO real. Verifique quantas horas de trabalho perde com a cópia que usou. Se copia uma vez por dia, o pior caso são 24 horas. Que esse número seja conhecido e aceite pela direção, por escrito.
• Documentar e comparar com o acordado. Deixe registo do resultado e confronte-o com o RTO/RPO que a empresa disse poder aguentar. Se o plano diz oito horas e o teste diz vinte e seis, tem um problema para resolver hoje, com calma.

Este último ponto é o que torna o exercício útil. Sem um RTO e um RPO acordados com a direção, o teste não tem contra o que medir-se e fica em anedota técnica. Com eles, cada ensaio diz-lhe se está dentro ou fora da margem que o seu negócio aguenta.

Erros típicos que só se veem ao restaurar

Há falhas que nenhum relatório de cópia deteta, porque não ocorrem ao copiar, mas ao recuperar. São invisíveis até ao dia em que restaura; por isso o ensaio tira-as cá para fora antes de fazerem estragos.

• Cópias incompletas. A cópia faz-se, mas não inclui tudo: falta uma base de dados, uma pasta partilhada ou o servidor que foi acrescentado há oito meses e ninguém meteu no trabalho. A verde a vida toda; recupera e falta justamente o que importava.
• Dependências esquecidas. Restaura a aplicação e não arranca porque lhe falta um serviço, uma versão, um certificado ou a máquina vizinha com quem falava. Recuperar um sistema quase nunca é recuperar um só servidor.
• Cifragem e chaves perdidas. A cópia está cifrada — bem — mas a chave estava no mesmo servidor que se perdeu, ou ninguém sabe onde vive. Uma cópia que não consegue decifrar é ruído perfeitamente inútil.
• Dados inconsistentes. A cópia foi tirada com a base de dados em funcionamento e sem um dump consistente: o ficheiro está lá, mas corrompido ou a meio de uma transação. Só descobre ao tentar montá-lo.
• RTO real incomportável. Está tudo e está tudo correto, mas restaurá-lo pela sua linha de internet demora quatro dias e o negócio aguenta um. Tinha a cópia; não tinha o tempo.

Nenhum se resolve comprando mais discos. Resolvem-se a testar: só o ensaio os torna visíveis enquanto ainda os pode corrigir sem pressa nem perdas.

Como o faz a MagicBoxDesk

Testar restauros à mão, com critério e de forma periódica, é precisamente o tipo de tarefa que uma empresa ocupada com o seu trabalho nunca chega a fazer: importante, não urgente, até ao dia em que é urgentíssima. Por isso na MagicBoxDesk tratamos disso nós. O nosso backup gerido inclui restauros testados periodicamente: não lhe entregamos um software e lhe desejamos sorte, mas um serviço que responde pelo resultado. Levantamos as suas cópias em ambiente isolado consoante a criticidade, verificamos que os dados são consistentes, cronometramos o RTO real e entregamos-lhe um relatório com o que funciona e o que há que ajustar antes de ser um problema.

Tudo isto encaixa com a nossa monitorização 24/7, que vigia cada trabalho de cópia e avisa se algo falha — fica a saber por nós, não por um desastre —, e com o resto dos serviços de IT geridos que formam o seu IT externalizado. A diferença é concreta: passa de acreditar que está protegido para ter a prova, com data e tempos medidos.

Deixe de confiar que a sua cópia restaura e comprove-o. Peça um orçamento sem compromisso e montamos os testes de restauro da sua empresa para que no dia mau recupere a sério, não por fé.