BackupExec 16 - Melhores praticas em português v1 - Best Practices

Mensagem por **tiagotoledo** » quinta mar 01, 2018 5:41 pm

BackupExec16_Melhores_Praticas_PT_Tiago_Toledo.zip: (2.39 MiB) Transferido 241 vezes

Melhores praticas
Geral
• Para backup em maquinas fisicas é preciso instalar o agente;
• Em HOST vmware o backup é feito atraves de APIs especificas;
• Aplicações que precisam de GRT é preciso instalar o agente;
• Para restore do dado para o local original é preciso instalar o agente;
• Ao adicionar o HOST HyperV no BkpExec o agente é instalado;
• Restore:
o File and Folder backup to a point-in-time
 Procure os conjuntos de backup para localizar arquivos, pasta ou volumes.
BackupExec usa o conjunto de backup que você seleciona, bem como quaisquer conjuntos relacionados, para restaurar os dados para o momento em que o conjunto de backup foi criado.
o File and Folder backup from a backup set
 Procure os conjuntos de backup para localizar arquivos, pasta ou volumes. O BackupExec restaura somente os dados do conjunto de backup selecionado.
Hardware – Recomendações
CPU
• Atualmente, o processo de deduplicação do Backup Exec não é capaz de usar vários núcleos.
o Portanto, você deve usar CPUs com núcleos menores, porém mais rápidos do que aqueles com mais núcleos, mas mais lentos.
o Desligue Hyper Threading no BIOS (para acelerar os núcleos).

Memoria
A memória é fundamental para o Backup Exec.
• Para que a deduplicação funcione, você pode calcular a memória livre necessária (não usada pelo sistema operacional ou de outras aplicações) da seguinte maneira:
o 1,5 GB de RAM por armazenamento de deduplicação de TB
o Adicione mais 8 GB para o sistema operacional
o Exemplo: um servidor de backup possui 20 TB de armazenamento de desduplicação. Portanto, ele precisará de 20 x 1,5 + 8 = 38 GB de RAM.
Uma vez que o tamanho de um armazenamento de deduplicação no Backup Exec é limitado a 64 TB, a RAM máxima necessária para servidores Backup Exec é de 64 x 1,5 + 8 = 104 GB.
Rede
Muitas vezes, a conexão de rede do servidor de backup é o gargalo na infra-estrutura.
Especialmente, ao fazer backups diretamente em fitas, mantenha a seguinte tabela em mente:

Tunning de Rede
o Use uma rede dedicada para backups, se possível.
o Verifique a resolução de nomes está correta ou use o arquivo de hosts para forçar o Backup Exec a usar o link de rede "privado".
o Use o NIC teaming, mas não superestimar o desempenho de links de rede em equipe:
o 1 Gbit-Link geralmente transportará cerca de 71 MB / Sec.
o Uma equipe de 2 Gbit costumará transportar cerca de 124 MB / seg.
o Uma equipe de 4 Gbit costumará transportar cerca de 215 MB / seg. (Quatro NICs em equipe terão cerca de 25% de perda de desempenho devido ao processo de agrupamento)
o Defina velocidade de rede fixa e duplex em todos os servidores, bem como nos switches.
o Para o Windows Server 2008/R2: turn off offloading Chimney Offload and Receive Side Scaling: http://support.microsoft.com/KB/951037
netsh int tcp set global chimney=disabled
netsh int tcp set global rss=disabled
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\EnableTCPA = 0
Fique de olho no ambiente
• Considerações de desempenho de rede (latência)
o Assegure menos de um por cento (1%) de perda de pacote durante a transmissão.
o Assegure uma latência de "ida e volta" de destino de 250ms ou menos.
o Os problemas de conexão afetarão as taxas de sucesso do trabalho.

• Latência e largura de banda não é o mesmo
o Você pode ter uma linha de rede ampla para a internet, mas sua latência ainda irá levar a taxas de backup "lentas".

• Certifique-se de testar a usabilidade do otimizador de WAN de terceiros antes de usá-los para backup, restauração ou deduplicação do cliente, porque estas não são configurações testadas e só são suportadas como uma configuração alternativa.

Coisas para se ter na mente
Nem todas as 10 portas GBE são as mesmas
Para usar várias portas de 10 GbE em uma switch, o switch não deve oferecer apenas essas portas, mas também possui a capacidade do backplane para transportar o tráfego que chega às portas.
Exemplo: o Cisco Catalyst 6500 só pode transportar 2x20 Gbit/seg por cartão de linha, de modo que cartões com 8x10 GBE são 100% com overbooking, cartões com 16x10 GBE 200%.

Verificar
• A verificação integrada do Backup Exec não o livra da necessidade de:
 Fazer testes de restauração aleatória.
 Verifique se os arquivos que você restaurou são legíveis/utilizáveis.

• Verificar um volume de desduplicação significa que todos os arquivos do (s) conjunto (s) de backup precisam ser re-hidratados para serem verificados.
Exemplo: você faz backup de 1 TB de dados e consegue um índice de 5: 1, então serão armazenados 200 GB de novos dados. Durante uma corrida de verificação, a cada 1 TB de dados eles devem ser reidratados e lidos.

• Verifique o armazenamento baseado em nuvem significa que todos os dados devem ser lidos, o que irá garantir um custo extra = $ (o mesmo que uma restauração).

• O Verificar não verifica o conteúdo de um arquivo, apenas o CHECKSUM.

• Para trabalhos de 3 estágios onde o último estágio é fita, recomendamos usar a verificação somente nesta última etapa.
Desduplicação
• Nem todos os dados podem ser deduplicados bem:
o Ou seja, os arquivos de log do Exchange contêm> 90% de dados exclusivos. Portanto, se a sobrecarga de fazer a desduplicação for uma preocupação, recomendamos segmentar backups incrementais do Exchange para backup-to-disk em vez de um armazenamento de desduplicação.
o Também a tentativa de desduplicar arquivos de mídia (vídeo, imagens e música) não será muito eficiente.

• Para backups habilitados para GRT, os backups completos e incrementais precisam usar o mesmo tipo de dispositivo!

• O backup em um armazenamento de desduplicação é menos eficiente que o Backup-To-Disk
o A mudança de "Backup-to-Disk-to-Tape" para "Backup-to-Dedup-to-Tape" pode, em alguns casos, estender a janela de backup além do que é prático para servidores de Backup Exec de menor desempenho

• Especialmente a tentativa de ler a partir de um armazenamento de deduplicação (ou seja, para copiar dados para fita ou verificar) ao mesmo tempo, onde os trabalhos de backup estão sendo executados diminuirá drasticamente o desempenho do dispositivo de armazenamento.

• O termo "Duplicação otimizada" descreve a tecnologia que o Backup Exec usa para replicar dados entre dois armazenamentos de desduplicação conectados a dois servidores de backup diferentes de uma forma que apenas esses blocos são replicados e que ainda não existem no armazenamento de destino.

• Para simplificar, isso significa que um servidor de backup faz um backup em um armazenamento de desduplicação conectado localmente e depois executa uma segunda etapa na política de backup para copiar (duplicar) os dados para um segundo armazenamento de desduplicação hospedado em um servidor de backup diferente. O efeito que é conseguido enviando apenas sobre a rede os blocos que o armazenamento de desduplicação de recepção não tem é comparável ao que um trabalho de backup de duplicação do lado do cliente faz.

• Para que isso funcione, o ambiente deve ter uma Enterprise Server Option ("ESO") licenciada e um Central Admin Server (CAS) instalado. O CAS pode ser um dos servidores envolvidos no trabalho de duplicação, mas não precisa, pois também pode ser de um MBES para outro MBES.

• Para usar uma rede dedicada apenas para o trabalho Duplicate otimizado entre dois servidores Backup Exec, crie duas entradas no arquivo HOSTS de cada servidor usando os nomes NetBIOS (somente) de ambos os servidores BE eo endereço IP estático para a rede desejada usar.

Conta do Backup Exec
Compreendendo as contas do Backup Exec
• A conta do sistema Backup Exec que será na maioria dos casos também a conta de logon padrão. Isto é, quando você cria um trabalho, ele usará, por padrão, esta conta como padrão para fazer logon nos recursos selecionados.

• A conta do sistema Backup Exec e a conta utilizada para os serviços do Backup Exec devem ser as mesmas.

• Recomendaria não usar o <domain>\Administrator, pois esta conta pode ter restrições impostas em alguns aplicativos que podem impedir backups e restaurações bem-sucedidos.

• Em vez disso, copie a conta do Administrador e nomeie-o algo significativo, Ex. BEadmin - Para referência: https://www.veritas.com/support/en_US/a ... TECH130255

Versões do sistema operacional Windows e capacidades AD GRT
Para executar um backup habilitado para GRT de um Servidor Active Directory do Windows Server, você deve usar um servidor Backup Exec que use a mesma ou uma versão mais recente do sistema operacional Windows Server como o controlador de domínio do Active Directory.
Depois de restaurar objetos de usuário do Active Directory, você deve atribuir-lhes novas senhas e, em seguida, reativar as contas de usuário.
As restaurações GRT do Active Directory não exigem que o controlador de domínio seja executado no modo de restauração dos serviços de diretório (DSRM), em vez disso, eles podem ser executados online.

Tunning BackupExec
Mover Catálogos
Mova a pasta "Catálogos" para um volume contínuo (ou seja, o armazenamento Backup-To-Disk ou, na melhor das hipóteses, outro armazenamento rapido com IO dedicado com capacidade adequada).
Nota: se você alterar a localização do catálogo desta forma, você terá que mover os arquivos do local antigo para o novo manualmente, pois isso não é feito automaticamente.
• Notas:
o Os backups de 1 TB geram aprox. 50 GB de catálogos.
o Mover os catálogos mitiga os seguintes riscos:
 Executando espaço em disco no volume do sistema
 No caso de reinstalar/atualizar o sistema operacional, os dados do catálogo não são afetados.

Mover GRT-Temp
Restaurações GRT de um dispositivo de armazenamento de fita/OST/VTL/Cloud precisam ser encenadas para um caminho de disco local. Este é o caminho de restauração e recuperação instantânea. O caminho de backup pode na maioria dos casos ficar como padrão, mas certifique-se de que ele é excluído de antivírus e malware.
O caminho de localização de teste padrão é C:\Temp.
Altere o caminho Restaurar e Recuperação Instantânea para um volume que tenha espaço suficiente para o estágio.
Notas:
Multiplique o tamanho total dos conjuntos de backup que você está restaurando em pelo menos 1,25. Por exemplo. Recuperar um banco de dados Exchange de 500 GB de fita requer pelo menos aproximadamente 625 GB.
Mover o local mitiga os seguintes riscos: executando espaço em disco no volume do sistema.
Mover arquivos de registro de tarefas (usando BE Utility)
Considere mover a pasta "Logs de tarefas" para um volume diferente.
Notas:
A pasta de destino deve existir, senão o movimento falhará.
Mover os logs do trabalho mitiga os seguintes riscos: Executando espaço em disco no volume do sistema e no caso de reinstalar/atualizar o sistema operacional, os dados de registro de tarefas não são efetuados.

Configurações de manutenção do banco de dados
• Mude o tempo de manutenção do banco de dados até um momento antes do início dos backups para fazer backup das alterações de configuração.
• Revise quanto tempo você realmente exige logs de tarefas (a configuração padrão na maioria dos casos é suficiente).
• Recomendamos ativar "Executar verificação de consistência de banco de dados" para manter a saúde.
• Otimize o tamanho do banco de dados: para evitar que as tabelas do banco de dados "inchadas" sejam redundantes em formação.

Chave de criptografia de banco de dados do Backup Exec
• Exporte a chave de criptografia do banco de dados.
• Defina um caminho para onde deseja exportar a chave.
• Você pode marcar a marca de seleção que o Backup Exec mantém registro do caminho de exportação, se desejar.
Nota: você deve fornecer a chave, sempre que quiser importar o banco de dados para um ambiente do Backup Exec.

Desligue o software Antivírus/Malware (conhecido por afetar os backups habilitados para GRT).
Recomendamos excluir as seguintes pastas de qualquer tipo de proteção contra vírus (Tempo real e exames programados):
• Pasta Catálogos
• Logs pasta
• Caminhos temporários GRT (ambos)
• Dados\pasta de banco de dados
• Todas as pastas de backup-a-disco
• O armazenamento de desduplicação
Nota: Tenha em mente que os backups baseados em fita (armazenados offline) não podem ser infectados por malware como Cryptolockers (Locky Ransomware).
VMware backups

https://www.veritas.com/support/en_US/article.000085311

Fazendo Backup de Servidores de Banco de Dados
Ao fazer backup de servidores de banco de dados baseados em agentes como Exchange, SharePoint, SQL, Oracle, Enterprise Vault ou Active Directory, tenha em mente os seguintes tópicos:
Para cada servidor crie (pelo menos) duas políticas de trabalho:
• Um para o sistema operacional e o estado do sistema para fins SDR (semanalmente ou menos).
• Um para o banco de dados e seus recursos relacionados (Diariamente ou mais).
• Agende as políticas de forma que elas não sejam executadas em paralelo, pois isso levará a problemas de VSS e trabalhos com falha.
Ao fazer backup (baseados em host), os servidores SQL e você tem aplicativos em outros servidores que usam bancos de dados no SQL (remoto), considere o seguinte:
• Ao fazer backups baseados no host, a instância mais pequena que você pode selecionar, é a VM.
• Em outras palavras, você não pode desmarcar nenhum dos itens dentro de uma VM durante os backups baseados no host.
• Uma vez que o SQL é um aplicativo VSS, todos os bancos de dados são sinalizados como também foram copiados durante o host.
• Isso pode levar a backups inconsistentes do aplicativo executado na outra VM, porque "outra pessoa" fez o backup de seu banco de dados SQL (e talvez até truncara os arquivos de log) sem informar o aplicativo.
• Se você estiver executando esses aplicativos, você deve excluir o servidor SQL de todos os backups baseados no host e protegê-lo apenas por meio de uma política de backup baseada em agente.
Exchange DAG - Nó preferido para backups
Escolha um nó DAG para fazer todos os backups dos bancos de dados, independentes, se eles estiverem ativos ou passivos.
Pode reduzir drasticamente o tempo necessário para fazer um backup de um DAG amplamente distribuído, quando o nó mais próximo e/ou mais performante para o servidor Backup Exec é definido como preferido.
Toma prioridade sobre o backup de regraing de configurações de trabalho do banco de dados ativo ou passivo.
Fazendo backup do Oracle (no Windows)
Ao fazer backup de servidores de banco de dados Oracle, tenha em mente os seguintes tópicos:
• Instale o Backup Exec Remote Agent no servidor Oracle.
• Abra o Backup Exec Agent Utility no Backup Exec Server.
• Clique em "Alterar configurações".
• Na guia "Oracle", clique em "novo".
• Selecione a (s) instância (s) que deseja proteger e insira um nome de usuário e uma senha com direitos SYSDBA nessa instância.
• Na guia "Acesso ao banco de dados", ative a caixa de seleção "Ativar o Backup Exec Server ...".
• Especifique um nome de usuário e senha para um usuário que tenha permissões administrativas nesse servidor.
Nota: Você pode usar a conta do sistema Backup Exec (BESA) aqui.
• Se necessário, altere a porta IP usada para acessar a instalação do Oracle.
• No servidor de backup, clique no botão Backup Exec, selecione "Configuração e Configurações" e clique em "Configurações do Backup Exec".
• No painel esquerdo, clique em "Oracle".
• Digite o nome do servidor Oracle no qual a instância está instalada.
o Nota: especifique exatamente o nome, como é mostrado na guia "Backup e restauração". Ose Backup Exec pode não ser capaz de combinar as duas entradas.
• Clique em "Adicionar".
• Digite o nome de usuário e a senha que você digitou na guia "Acesso ao banco de dados" no servidor Oracle antes.
• Crie uma política de trabalho para fazer backup das instâncias do Oracle.

Fazendo backup do Backup Exec Server
Em caso de restauração de desastres, a máquina mais importante para recuperar será seu servidor de backup.
Para se preparar para esse cenário, você deve fazer o seguinte:
• Crie um backup SDR de todos os componentes do servidor de backup e exclua apenas os volumes que contêm armazenamentos B2D e de deduplicação. (Como fazer backup de sua pasta de armazenamento de desduplicação será explicada mais tarde)
• Configure o caminho de armazenamento alternativo para arquivos SDR nas configurações do Backup Exec para apontar para um compartilhamento de rede.
• Deixe o backup funcionar para um dispositivo B2D localizado fora do servidor de backup (unidade USB ou compartilhamento de rede) ou (melhor) para um dispositivo de fita (Locky Ransomware).
• Crie um meio de inicialização SDR incluindo todos os drivers de dispositivo necessários para o hardware do servidor de backup.
• Nota: SDR Restores of the Backup Server de armazenamento de deduplicação não são possíveis, pois o banco de dados de desduplicação não está disponível no ambiente de pré-inicialização SDR.

Para fazer backup de sua pasta de armazenamento de desduplicação em fita, faça o seguinte:
• Crie uma nova política de backup.
• Dê um nome marcante (ou seja, "<nome do servidor> Dedup").
• Desmarque todos os itens na lista de seleção removendo a marca de seleção no nível do nome do servidor.
• Inclua o recurso "Shadow Copy Components" clicando em sua marca de seleção.
• Selecione um dispositivo de fita (recomendado) como alvo para o trabalho.

Disco – Recomendações
• Para obter melhorias de desempenho significativas, aumente o número de discos no volume. Os testes mostraram que duplicar a quantidade de discos em um volume RAID 5 (de 6 a 12) triplicou o desempenho geral!

• Então, melhor use muitos discos pequenos do que alguns mais grandes.

Nota: se o número de discos estiver no "dez", você precisa pensar em usar o RAID 6 em vez disso, pois o risco de uma falha simultânea de duplo disco aumentará pelo número de discos usados.

• O melhor para desempenho e redundância é RAID 1 para o volume do sistema (SO) - (tipo de disco: SSD).

• O melhor para desempenho e redundância é o RAID 5 para o volume de armazenamento (tipo de disco: SAS).

Nota: A velocidade de rotação das unidades no volume de armazenamento quase não tem impacto no desempenho.

• Use controladores de armazenamento com tanto cache de gravação quanto possível (≥2 GB). Mais cache leva a um melhor desempenho. Ex: HP Smart Array Controller Technology.

• Não use controladores RAID sem cache de gravação em buffer (módulo flash ou bateria).
Por razões de segurança, a maioria dos controladores RAID usam seus módulos de cache apenas para operações de leitura, quando nenhuma bateria ou módulo de retrocesso está presente, porque sem esse módulo, uma perda de energia para o servidor quase que certamente resultaria em uma perda de dados imprevisível.

• Nunca use controladores RAID para se conectar a unidades de fita, use sempre HBA dedicado.

• Certifique-se sempre de que o firmware dos controladores de armazenamento esteja atualizado.

Backup-To-Disk
• Crie todos os arrays com um tamanho de stripe de 64 kB.

• Formatar todos os volumes no Windows com um tamanho de bloco de 64 kB.

• Se possível, anexe várias matrizes a controladores ou buses diferentes no servidor de backup.

• Não use RAIDs de software para combinar vários arrays em um maior; Use pools de armazenamento dentro do Backup Exec.

Backup-To-Deduplicação
• Crie todos os arrays com um tamanho de stripe de 64kB.

• Formatar todos os volumes no Windows com um tamanho de bloco de 64 kB.

• Não subestime o tamanho do banco de dados de deduplicação (PostgreSQL). Pode atingir até 8% do tamanho do armazenamento de deduplicação.

• Certifique-se de que o armazenamento de desduplicação não esteja ficando sem espaço em disco, pois isso pode resultar em um armazenamento de desduplicação danificado.

Recomendamos a criação de um arquivo fictício no volume que pode ser excluído quando o espaço em disco está sendo executado.

Use o seguinte comando para criar um arquivo de 100 GB:

#fsutil file createnew <letra da unidade>: \DeleteOnlyIfDedupSpaceLow.txt 104857600000

Quando o volume para o armazenamento de desduplicação foi estendido, os serviços precisam ser reiniciados para reconhecer a alteração.

O Backup Exec exclui automaticamente os conjuntos de mídia/backup expirados e disponibiliza o espaço disponível para a Pasta de Deduplicação.

Este processo automatizado ocorre a cada doze horas (12:20 & 00:20).
O arquivo de log SCHED_QUEUEPROCESS.LOG (localizado em DeduplicationFolderPath \ Log \ Spad) grava quando o processamento de fila é iniciado.

O processo também pode, se necessário, ser iniciado manualmente.

Veja instruções detalhadas aqui:
Recuperação de espaço manual para armazenamento de deduplicação no Backup Exec
VERITAS Artigo 000017049: http://www.veritas.com/docs/000017049

Atenção: O processo de recuperação necessita de algum espaço temporário para ser executado. Portanto, se o armazenamento de deduplicação ficou sem espaço em disco, o processo de limpeza não pode ser executado.

Performance de disco
Para descobrir qual é o desempenho do disco nos volumes usados para dispositivos baseados em disco de backup, você pode usar a ferramenta independente NBPerfchck.exe.
Também pode ser usado para descobrir, a performance da rede quando copiamos um arquivo para um armazenamento remoto.
Mantenha os resultados do teste como parte de sua documentação de implantação e use-os como uma linha de base em caso de problemas.
A Veritas recomenda um nível mínimo de desempenho de disco de 130 MB/seg para operações de leitura e gravação B2D e Deduplicação. Idealmente tudo acima de 200 MB/seg é bom.
VERITAS Artigo 000095782: http://www.veritas.com/docs/000095782

Virtualização

• Não faça backup para o mesmo hardware de armazenamento que as VMs estão usando;

• Não use discos virtualizados como destinos de backup, use discos físicos apresentados pelo SAS/FC/iSCSI;

• Todas as configurações do Backup Exec suportadas em um ambiente físico tradicional também serão suportadas em qualquer ambiente virtual sem qualificação.
VERITAS Artigo: http://www.veritas.com/docs/000080758
Práticas recomendadas do Hyper-V
• Se os Serviços de Integração do Hyper-V não estiverem em execução, o Backup Exec deve colocar a VM em um estado salvo para fazer o backup.

Nota: Isto significa que a VM está fora de serviço.

Requisitos para usar o agente para Microsoft Hyper-V: http://www.veritas.com/docs/000058755

• Instale o Backup Exec Remote Agent nas VMs que deseja fazer backup com GRT para aplicativos.

• Protegendo Volumes Compartilhados do Cluster
o NÃO selecione CSVs e VMs na mesma lista de seleção, pois isso levará a erros VSS.

• Backups incrementais
o Se você estiver usando o "método de processamento mais rápido" para os backups Incremental, verá um desempenho de backup melhor, mas há mais espaço em disco nos volumes de armazenamento do Hyper-V usados, para criar a árvore de snapshot necessária para este método. Ambos os métodos de backup não têm impacto nos backups completos.

FAQ
• Q: É possível e suportado instalar BE em um host autônomo do Hyper-V e fazer backup do próprio host, bem como das VMs hospedadas??
A: Sim, isso é tecnicamente suportado e funcionando bem, desde que não haja nenhum software adicional em execução no host, como o Exchange Server.
Consulte os guias de licenciamento da Microsoft e da Veritas sobre as licenças necessárias..

• Q: Is É possível e suportado instalar BE em um host em cluster Hyper-V e fazer backup do próprio host, bem como as VMs hospedadas?
A: Não, isso não é suportado..

• Q: Posso instalar o servidor de backup como uma máquina virtual e fazer backup de outras VMs?
A: Sim, isso é possível.

• Q: Um armazenamento de fita pode ser anexado a um Backup Exec Server virtualizado?
A: Sim, conecte-os por iSCSI, em vez de usar SCSI pass-through conectados ao host.
(SCSI pass-through só é suportada como uma configuração alternativa).

• Q: É possível e suportado fazer backup de máquinas virtuais Hyper-V diretamente do armazenamento (SAN)?
A: Não, isso não é suportado atualmente.
Práticas recomendadas para VMware
• Mantenha o VMware Tools atualizadas, pois elas são um pré-requisito necessário para fazer o backup de VMs através do host.

• Se você deseja instalar o Backup Exec Remote Agent, não instale o VSS Provider incluído nas ferramentas do VMware, pois ele entrará em conflito com o Backup Exec.
VERITAS Artigo: http://www.veritas.com/docs/000009506

Durante a instalação inicial do Remote Agent, o Backup Exec removerá o provedor do VMware VSS. VERITAS Artigo: http://www.veritas.com/docs/000042539

• Instale o Backup Exec Remote Agent em todas as VMs que você deseja fazer backup com GRT para aplicativos (o nível de arquivo GRT não exige que o Remote Agent seja instalado).

• Apresente os SAN LUNs que contêm as VMs ao servidor de backup.
Como fazer backup do ESX (i) usando o transporte SAN: http://www.veritas.com/docs/000012638

• O transporte SAN não é recomendado para a restauração de disco provisionado thin, uma vez que é provavelmente mais lento do que NBD.

• Modo de transporte
o Se o servidor Backup Exec for virtualizado, Hotadd, é o método de backup mais eficiente a ser usado.
o Hotadd não está disponível para restaurações, tem que usar NBD/NBDSSL.
o O armazenamento em disco do Backup Exec não deve usar o mesmo armazenamento de dados que hospeda as VMs das quais você está fazendo backup.
o Se estiver usando dispositivos de fita com um Backup Exec Server virtualizado, conecte-os por iSCSI em vez de usar dispositivos de passagem SCSI conectados ao host. (SCSI pass-through só é suportado como uma configuração alternativa).

Verificar
• A verificação integrada do Backup Exec não o isenta da necessidade de:
o Fazer testes de restauração aleatórios.
o Verifique se os arquivos restaurados são legíveis / utilizáveis.
• Verificar em um volume de desduplicação significa que todos os arquivos do (s) conjunto (s) de backup devem ser re-hidratados para serem verificados.
o Exemplo: Você faz backup de 1 TB de dados e consegue uma proporção de 5: 1, então 200 GB de novos dados serão armazenados. Durante uma execução de verificação, todo o 1 TB de dados tem de ser reidratada e lida.
• Verifique se o armazenamento baseado em nuvem significa que todos os dados devem ser lidos, o que implicará um custo extra = $ (o mesmo que uma restauração).
• Verificar NÃO verifica o CONTEÚDO de um arquivo, apenas seu CHECKSUM.
• Para tarefa de 3 estágios onde o último estágio é fita, recomendamos usar a verificação somente nesta última etapa.
•

OST Applicance
• Open Storage Technology (OST) "é uma interface de software que permite ao Backup Exec gerenciar armazenamentos externos em termos de rastreamento do que está acontecendo.

Em outras palavras, o processo de deduplicação em si é terceirizado para o appliance de hardware, enquanto o Backup Exec ainda obtém todas as informações e catálogos necessários para fazer restaurações.

Esta terceirização tem muitas vantagens, mas também desvantagens

• O lado claro:
• OST fornece um mecanismo de desduplicação baseado em hardware que remove a carga do servidor de backup. Replicação compatível com aplicativos.

• Isso aproveita os recursos de replicação de hardware para copiar dados entre sites, mas gerencia o processo por meio de políticas definidas no Backup Exec.

• Devido à integração apertada, o acesso do Backup Exec aos dados replicados é transparente e permite restaurações diretas de todas as réplicas, onde quer que estejam localizadas.

• Como os appliances OST possuem seu próprio gerenciamento de armazenamento, eles não se limitam ao tamanho máximo de 64 TB, já que os armazenamentos internos de desduplicação do Backup Exec são atuais.

• Devido ao seu hardware e firmware especializados, os aparelhos OST são frequentemente mais eficazes do que os armazenamentos internos de desduplicação (baseados no Windows).

• O lado escuro:

• As restaurações a partir de backups habilitados para GRT precisam ser encenadas durante o processo de restauração, semelhante à restauração da fita.

• Portanto, uma quantidade apropriada de armazenamento local no servidor de backup precisa estar disponível durante restaurações (aproximadamente 1,2 a 1,5 vezes o tamanho do maior contêiner backed up [vmdx, edb etc.])

• A replicação entre dispositivos OST só é suportada, se ambos os aparelhos são do mesmo fornecedor e utilizar o mesmo plug-in OST.

• A disponibilidade e compatibilidade da desduplicação do lado do cliente está limitada aos recursos do plug-in OST fornecido pelo fornecedor de armazenamento.

• O custo dos próprios aparelhos OST.
SQL Agent
• Inclua o seguinte na tarefa de backup:
o Full SQL database backups
o Windows System State
o System drive backups of the hard drive or drives where Microsoft SQL resides
o System drive backups of the hard drive or drives where the Microsoft SQL databases reside
• Excluir todos os arquivos de banco de dados de uma verificação antivírus;
• Use backups diferenciais para maximizar sua janela de backup.
• Executar backups de log de transações se o banco de dados estiver configurado para o modelo de recuperação completo para impedir crescimento de arquivo de log ilimitado.
• Use a tecnologia de snapshot com as tarefas de backup que usam dispositivos de desduplicação.
• A Veritas recomenda que você execute verificações regulares de consistência de banco de dados para verificar a integridade de o banco de dados.

Você deve especificar as seguintes opções de backup e restauração SQL para a verificação de consistência:
o Verificação de consistência antes do backup - Verificação física apenas
o Continuar com backup se a verificação de consistência falhar
o Verificação de consistência após a restauração - Verificação física apenas
• Para garantir a recuperação após um desastre, execute tarefas de restauração de teste periódicas e verifique se elas estão incluídas no plano de preparação para desastres.
• Práticas recomendadas para segurança e acesso a banco de dados com o SQL Agent
o Certifique-se de que a conta de usuário do Windows que você usa para fazer backup das instâncias do SQL tem privilégios de administrador do sistema.
o Certifique-se de que o Backup Exec tem direitos para as seguintes chaves de registro:
 HKEY_LOCAL_MACHINE\Software\Microsoft\Microsoft SQL Server
 HKEY_LOCAL_MACHINE\Software\Microsoft\MSSQL
Alta disponivilidade
• Muitos aplicativos e bancos de dados podem ser implantados como uma instalação autônoma ou como uma instância altamente disponível que é distribuída em vários servidores físicos ou virtuais.

• Ao fazer backup de bancos de dados e aplicativos em servidores autônomos, você pode decidir se deseja fazer backup dos recursos por meio do host de virtualização ou por meio de um agente instalado dentro do servidor de aplicativos virtual.

• A implantação de aplicativos altamente disponíveis significa que o aplicativo é executado como uma espécie de instância virtual que pode ser hospedada por qualquer um dos membros do sistema em cluster.

• Como o Backup Exec tem que trazer o aplicativo em um estado consistente para ser feito backup, ele deve "falar" com a instância virtual em vez de um dos nós do cluster.

• Essas instâncias altamente disponíveis serão exibidas no Backup Exec como uma entrada de recursos dedicada no painel BACKUP AND RESTORE.

• Para proteger totalmente um banco de dados ou um cluster de aplicativos, é necessário:
o As unidades locais de todos os nós de cluster para restaurá-los em caso de falha local (ou seja, um erro do sistema operacional).
o O aplicativo em um trabalho separado usando seu próprio registro de recurso.

• Exemplo: Para proteger um Exchange-DAG de dois nós, você terá que fazer backup de três objetos diferentes:
o Nó A (unidade (s) de disco rígido local e estado do sistema).
o Nó B (unidade (s) de disco rígido local e estado do sistema).
o O recurso em cluster próprio (DAG) (que incluirá o arquivo de informações)

• Portanto, mesmo se a instância de aplicativo altamente disponível estiver sendo executada em servidores virtuais, não será possível fazer backup usando o Agente para VMware um Hyper-V, pois isso processaria as VMs uma a uma, sem proteger o aplicativo.

Instant GRT
O GRT instantâneo reduz o tempo total que o trabalho de backup leva para completar coletando informações mínimas do catálogo, no entanto, ainda suporta uma restauração granular dos itens.

• As atualizações não alteram o padrão e as configurações existentes.

• Se um novo tipo de dispositivo (por exemplo, desduplicação) for criado, o padrão será Instant GRT.

• A operação Instant GRT é aplicável para backups habilitados para GRT para dados do Active Directory, Exchange, SharePoint, Hyper-V ou VMware (física e virtual).

• O GRT instantâneo sempre foi usado para backups do Active Directory baseados em agentes.

• O GRT instantâneo não é aplicável para trabalhos de backup em fita.
• Se você criar um trabalho de gravação em GRT para dados de Exchange, SharePoint, Hyper-V ou VMware, uma operação de catálogo completo é executada como parte do trabalho de backup.

• Todos os conjuntos de dados de backup do Instant GRT devem estar no mesmo tipo de armazenamento em disco.

• Se você usar um dispositivo RDX, assegure-se de que o conjunto completo de backup (completo e incremental) esteja no "um" cartucho.

• Se não for possível, faça backup em um dispositivo de armazenamento B2D ou desduplicação.

• A opção de catalogação completa ainda está disponível (imediatamente após o trabalho ou agendada).

Instant Recovery
Características principais
• Powers na máquina virtual (independentemente do seu tamanho) diretamente do armazenamento de backup.
• Faz a máquina virtual visível no vCenter ou no gerenciador Hyper-V assim que ela for recuperada.
• A VM recuperada pode ser migrada on-line para a produção via VMware vMotion ou Hyper-V Live Migration.

Nota: Veritas recomenda que você remova uma "VM Recuperada" instantaneamente que não é mais necessária no Backup Exec após a VM ter sido migrada com sucesso.
O conjunto de backup da máquina virtual permanecerá intacto no armazenamento Backup Exec e pode ser reutilizado.
A carga adicional no armazenamento do Backup Exec pode afetar o desempenho geral do servidor Backup Exec.

Cloud conector

A restauração GRT deve ser encenada para um caminho local no Backup Exec Server (padrão: C:\Temp).
Verifique no armazenamento baseado em nuvem significa que todos os dados devem ser lidos, o que incauta um custo $ (o mesmo que uma restauração). Restores custará dinheiro (verifique as informações de preços mais recentes do fornecedor de serviços).
Os backups e restaurações para e da nuvem serão mais lentos, em seguida, os trabalhos que utilizam em dispositivos locais.
Os backups e restaurações requerem uma conexão à Internet.
Não deixe a única cópia dos dados críticos do seu negócio em um dispositivo Cloud.
• Para fazer backup no disco e depois duplicar para a nuvem, você deve configurar dois tipos de armazenamento no Backup Exec: um dispositivo de armazenamento em disco local para fins de estadiamento e o armazenamento em nuvem.

• Crie Buckets específicos para usar exclusivamente com o Backup Exec.

• Use um Buckets diferente para cada dispositivo de armazenamento em nuvem. Não use o mesmo Buckets para vários dispositivos de armazenamento em nuvem, mesmo que esses dispositivos estejam configurados em diferentes servidores do Backup Exec.

• Certifique-se de que os nomes de Buckets contenha apenas letras minúsculas, números e guinchos ou hifens. Além disso, assegure-se de que os nomes dos Buckets não comecem com um traço.

• Os compartimentos não ficaram disponíveis para uso no Backup Exec, se o nome do Buckets não estiver em conformidade com as convenções de nomenclatura do balde.

Elaborado por Tiago Toledo