Wiki
Dúvidas Gerais
Por razões de segurança, não é possível modificar uma chave de criptografia depois de configurada na criação da tarefa de backup, onde podemos comparar com a situação de perdermos a chave de um cadeado – não seria possível utilizar outra chave para este cadeado.
Uma chave criptográfica não permite modificação e caso a mesma seja esquecida os dados jamais poderão ser recuperados, pois os dados que estão no servidor de origem são cifrados com esta chave antes mesmo de enviar para a nuvem.
Primeiro Backup
A primeira execução do backup pode-se entender como FULL (completo), pois como ainda não existe nenhum arquivo no destino (nuvem), todos os arquivos existentes na origem serão enviados para a nuvem.
Próximos backups
Nas próximas execuções, apenas os novos arquivos e os arquivos modificados serão enviados para a nuvem, já os arquivos que não sofreram nenhuma modificação não serão reenviados, pois não há nenhuma razão em reenviar este arquivo uma vez que o mesmo não sofreu nenhuma modificação.
Já, se um arquivo sofreu alteração, existem 02 opções para tratar o seu reenvio para a nuvem:
1. Com o InFile Delta habilitado (padrão)
Com esta tecnologia habilitada, se um arquivo sofrer uma alteração, apenas a sua diferença será enviada para a nuvem. Por exemplo: você possui um arquivo de 100MB que já está na nuvem, porém este arquivo sofreu uma modificação de 1MB no servidor, ao executar o backup, em vez do software reenviar o arquivo completamente (100MB), ele enviará apenas a modificação de 1MB.
2. Com o InFile Delta desabilitado
Caso a opção InFile Delta for desabilitada, qualquer alteração que um arquivo sofrer, ele será reenviado por completo para a nuvem.
Vídeo Tutorial: Backup e Restauração File Server (Arquivos e Pastas) – Windows
Vídeo Tutorial: Backup e Restauração File Server (Arquivos e Pastas) – Linux
Video tutorial: Backup e Restauração VMware
Video tutorial: Backup e Restauração Hyper-V
Vídeo Tutorial: Backup e Restauração MSSQL
Video Tutorial: Backup e Restauração MySQL
Vídeo Tutorial: Backup e Restauração Windows “Bare Metal”
Muitas vezes você poderá sentir lentidão no processo de realizar um backup e principalmente no momento de uma restauração. Por isso é importante entender que a performance de um backup depende de 04 fatores básicos:
1. Quantidade de arquivos a ser enviado
2. Volume de dados a ser enviado
3. Performance do servidor para poder compactar e criptografar os arquivos
4. Velocidade de Internet para poder enviar os arquivos
Se você achar que o backup ou restauração está lento, faça este simples teste para entender a capacidade computacional do seu servidor:
Utilize a ferramenta WinZip e compacte um arquivo texto de 100GB. O arquivo de 100GB será compactado em aproximadamente 10GB. Depois faça a descompactação e você irá perceber quantas horas ou mesmo dias irá levar este processo.
O GBackup permite enviar os dados para outras nuvens, como: Amazon, Microsoft Azure, Rackspace, etc.
Arquivos ativos são os arquivos que existem no servidor de origem e na nuvem, ou seja, é o seu backup mais atual.
Arquivos em retenção são os arquivos que já foram apagados ou modificados no servidor de origem e que estão na “Lixeira” da nuvem por um determinado número de dias.
Sim, o backup local é armazenado exatamente igual à nuvem. Para testar, você pode fazer um backup apenas local em um HD externo e depois tentar realizar alguma leitura nos arquivos. Você verá que os arquivos são impossíveis de serem lidos.
Abaixo seguem algumas instruções que devem ser seguidas para que o serviço de backup funcione adequadamente:
– Sempre armazene as suas chaves de criptografia em algum outro local e evite utilizar chaves de criptografia personalizadas pois esta chave será requisitada quando um backup for restaurado. Lembrando que uma chave criptográfica não permite alteração, portanto, se a mesma for esquecida os dados não poderão ser restaurado.
– Atribua um tempo de retenção de no mínimo 30 dias para poder restaurar dados que foram modificados ou excluídos acidentalmente.
– Leia atentamente os relatórios executivos que são enviados diariamente no seu e-mail e corrija os backups que apresentaram erros e valide a última data de realização dos backups finalizados com sucesso para evitar que o backup esteja desatualizado.
– Realize testes de restauração frequentemente, pois você poderá validar se os dados que estão configurados para serem enviados para a nuvem são realmente todos os dados que o cliente precisa que seja feito backup ou se falta selecionar mais origens para serem protegidas.
– Não realize mais de 02 execuções de backup por dia, pois isso pode impactar demasiadamente a performance e Internet do cliente, exceto em exigências de normativas do cliente.
– Evite realizar backup de unidades mapeadas em rede, pois o Windows não permite que arquivos abertos sejam acessados em unidades remotas, portanto, haverá erros no backup. A melhor prática é instalar o agente de backup em cada servidor que possui dados para serem protegidos.
– Se você estiver realizando backup de SQL Server de forma diferencial, nunca utilize mais de uma ferramenta para realizar o backup pois no momento da restauração haverá problemas para identificar qual ferramenta que fez o último backup full válido. A melhor prática é sempre optar pelo backup full de SQL Server
Lentidão no processo do envio dos dados
Para agilizar o processo do primeiro backup (FULL), existe a possibilidade de enviar os dados por meio de mídia externa.
Lentidão no processo do restauração dos dados
Para agilizar o processo de restauração dos dados, existe a possibilidade de receber os dados por meio de mídia externa.
Contato
Se nenhuma das resoluções acima resolver seu problema de backup perdido, entre em contato com nosso Atendimento ao Cliente para solucionar o problema ou através do formulário abaixo.
