Desafio 28: projetar Backup e recuperação para dados não estruturados

Tempo Estimado e Custo

60-90 min | Custo estimado: $5-15 | Peso no Exame: 15-20%

Introdução

A Vivid Creative Agency é uma empresa de design de 200 pessoas que produz campanhas publicitarias para clientes da Fortune 500. Seus ativos criativos totalizando 200 TB incluem fotografia em alta resolução (arquivos RAW, 50-100 MB cada), projetos de vídeo 4K/8K (arquivos individuais de até 500 GB), arquivos de projeto Adobe (Photoshop, Premiere, After Effects) e entregaveis de clientes em vários formatos. Todos os ativos são armazenados no Azure Blob Storage e Azure Files (para workspaces de projeto compartilhados).

O maior risco operacional e a delecao acidental. Somente no último trimestre, designers acidentalmente deletaram a pasta errada três vezes, uma vez perdendo 2 semanas de trabalho em uma campanha de $500K. O processo de recuperação existente requeria restauração a partir de backups noturnos, significando que até 24 horas de trabalho poderiam ser perdidas. O diretor criativo exige recuperação em menos de uma hora para delecoes recentes, enquanto o CFO insiste em proteção de arquivo de longo prazo (alguns contratos de clientes requerem retenção de ativos por 7 anos pós-campanha).

O desafio é equilibrar múltiplas camadas de proteção: recuperação instantanea para o cenário "ops, deletei a pasta errada", backups programados para recuperação point-in-time, e arquivamento imutável para conformidade de longo prazo. Os custos de armazenamento já são altos com 200 TB, entao a estratégia de backup deve ser consciente de custos e evitar dobrar as despesas de armazenamento.

Habilidades do exame cobertas

Recomendar uma solução de backup e recuperação para dados não estruturados

Tarefas de design

Parte 1: design de proteção de dados no Blob Storage

Avalie e configure os seguintes recursos nativos de proteção para as contas de blob storage. Para cada um, documente contra o que protege, seu impacto no custo e suas limitacoes:

Blob Storage Protection Features

Click each cell to reveal the answer. Think about your answer first!

	Protects Against	Cost Impact	Retention
Blob soft delete	?	?	?
Container soft delete	?	?	?
Blob versioning	?	?	?
Point-in-time restore	?	?	?

Projete uma estratégia de proteção em camadas:
- Camada 1 (Recuperação instantanea): Quais recursos fornecem restauração self-service em minutos?
- Camada 2 (Backup programado): O que fornece backup diario com retenção de 30 dias?
- Camada 3 (Arquivo de longo prazo): O que fornece retenção de 7 anos com custo mais baixo?
Configure blob soft delete e container soft delete para as contas de armazenamento de produção:

# Enable blob soft delete (30-day retention)
az storage account blob-service-properties update \
  --account-name stvividcreative \
  --resource-group rg-creative-assets \
  --enable-delete-retention true \
  --delete-retention-days 30

# Enable container soft delete (30-day retention)
az storage account blob-service-properties update \
  --account-name stvividcreative \
  --resource-group rg-creative-assets \
  --enable-container-delete-retention true \
  --container-delete-retention-days 30

Parte 2: versionamento e Point-in-Time restore

Habilite blob versioning e análise seu impacto no patrimonio de armazenamento de 200 TB:
- Como o versionamento afeta os custos de armazenamento quando arquivos são frequentemente sobrescritos?
- Para arquivos de vídeo que são raramente modificados, o versionamento e custo-efetivo?
- Para arquivos de projeto Adobe que são salvos centenas de vezes diariamente, qual é o risco de custo?
Projete regras de lifecycle management para gerenciar custos de versoes:
- Mova versoes anteriores para o tier Cool apos 7 dias
- Mova versoes anteriores para o tier Archive apos 30 dias
- Delete versoes anteriores com mais de 90 dias (exceto blobs com tag de conformidade)
Configure point-in-time restore e entenda seus pré-requisitos:
- Quais outros recursos devem estar habilitados para point-in-time restore funcionar?
- Qual é o período máximo de retenção para point-in-time restore?
- Você pode restaurar um único container, ou deve restaurar a conta inteira?
- Quais são as limitacoes? (por exemplo, não pode ser usado com hierarchical namespace do Data Lake Storage Gen2)

Parte 3: Azure Backup para blobs (Vaulted backup)

Projete a configuração do Azure Backup para dados blob usando o Backup vault:
- Compare operational backup (continuo, usa recursos nativos do blob) vs. vaulted backup (programado, armazenado no vault)
- Qual abordagem funciona para o patrimonio de 200 TB dadas as restrições de custo?
- Qual é a frequência de backup e faixa de retenção para vaulted blob backup?
Configure uma política de operational backup para os ativos criativos:

# Create a Backup vault
az dataprotection backup-vault create \
  --resource-group rg-creative-assets \
  --vault-name bv-vivid-creative \
  --location eastus \
  --storage-setting "[{type:LocallyRedundant,datastore-type:VaultStore}]"

# Create a backup policy for blobs (operational tier)
az dataprotection backup-policy create \
  --resource-group rg-creative-assets \
  --vault-name bv-vivid-creative \
  --name policy-blob-30day \
  --policy '{backupRules:[{name:Default,trigger:{kind:ScheduleBased,schedule:{repeatingTimeIntervals:["R/2024-01-01T00:00:00+00:00/P1D"]}},dataStore:{dataStoreType:OperationalStore,objectType:DataStoreInfoBase}}],objectType:BackupPolicy,datasourceTypes:["Microsoft.Storage/storageAccounts/blobServices"]}'

Avalie se vaulted backup é necessário além do operational backup para o requisito de conformidade de 7 anos. Documente os trade-offs:
- Vaulted backup armazena dados independentemente (isolado da delecao da conta de origem)
- Vaulted backup suporta cross-region restore
- Vaulted backup tem custos adicionais de armazenamento

Parte 4: Backup e recuperação do Azure Files

A equipe de design usa Azure Files (Premium, share de 10 TB) para colaboracao ativa em projetos. Projete a estratégia de backup:
- Azure Backup para Azure Files usa share snapshots
- Configure backup diario com retenção de 30 dias
- Configure backup anual para conformidade (armazenado como snapshot)
Compare as limitacoes de backup do Azure Files com backup de blob:
- Número máximo de snapshots por share (200)
- Custos de armazenamento de snapshot (diferencial, apenas blocos alterados)
- Opcoes de restauração: restauração de share completo vs. restauração individual de arquivo/pasta
Crie uma arvore de decisão para a equipe de recuperação:
- "Deletei acidentalmente um arquivo 5 minutos atras" -> Usar qual recurso?
- "Preciso recuperar uma pasta de ontem" -> Usar qual recurso?
- "Preciso recuperar arquivos de 2 anos atras para retenção legal" -> Usar qual recurso?
- "A conta de armazenamento foi deletada por um administrador malicioso" -> Usar qual recurso?

Criterios de sucesso

⬜Layered protection strategy documented with soft delete, versioning, and backup vault
⬜Blob soft delete and container soft delete enabled with apprópriate retention periods
⬜Lifecycle management rules configured to manage versioning costs with tier transitions
⬜Azure Backup for blobs configured with apprópriate backup policy type selected
⬜Azure Files backup configured with daily snapshots and apprópriate retention
⬜Recovery decision tree created mapping scenários to correct recovery method

Dicas

Dica 1: Pre-requisitos do Point-in-Time Restore

Point-in-time restore para blobs requer que TODOS os seguintes estejam habilitados:

Blob soft delete
Blob versioning
Blob change feed

Limitacoes importantes:

Retencao máxima: 14 dias (você só pode restaurar para um ponto nos últimos 14 dias)
Restaura em nível de container (não blobs individuais - use versionamento para isso)
NAO suportado com hierarchical namespace (Data Lake Storage Gen2)
NAO suportado com premium block blobs
Só pode restaurar block blobs (não page blobs ou append blobs)

Isso significa que point-in-time restore e proteção de Camada 1 para acidentes recentes, não para conformidade de longo prazo.

Dica 2: Gerenciamento de Custo de Versionamento

Blob versioning armazena cada versao anterior como um blob separado. Calculo de risco de custo para um arquivo Adobe de 100 MB salvo 50 vezes/dia:

Sem versionamento: 100 MB armazenados
Com versionamento (sem lifecycle): 100 MB x 50 versoes/dia x 30 dias = 150 GB por arquivo!

Estratégias de mitigacao:

Use lifecycle management para mover versoes anteriores para o tier Cool apos 1-7 dias
Delete versoes anteriores apos 30-90 dias (a menos que tenham tag de conformidade)
Use rastreamento de último acesso para arquivar versoes não utilizadas
Considere desabilitar versionamento para containers com arquivos de alta rotatividade e usar Azure Backup em vez disso

{
  "rules": [{
    "name": "version-lifecycle",
    "type": "Lifecycle",
    "definition": {
      "actions": {
        "version": {
          "tierToCool": { "daysAfterCreationGreaterThan": 7 },
          "tierToArchive": { "daysAfterCreationGreaterThan": 30 },
          "delete": { "daysAfterCreationGreaterThan": 90 }
        }
      }
    }
  }]
}

Dica 3: Operational vs Vaulted Backup para Blobs

Operational backup:

Usa recursos nativos de proteção de blob (soft delete, versionamento, change feed)
Proteção continua (sem lacuna de RPO)
Dados permanecem na conta de armazenamento de origem
Se a conta de origem for deletada, operational backup também é perdido
Sem cross-region restore
Melhor para: proteção contra delecao acidental, corrupcao

Vaulted backup:

Dados são copiados para um Backup vault separado
Programado (diario/semanal) com retenção configuravel
Dados sobrevivem a delecao da conta de origem
Suporta cross-region restore (com vault GRS)
Custo adicional de armazenamento para a copia no vault
Melhor para: proteção contra desastres em nível de conta, requisitos de conformidade

Para Vivid Creative: Use operational backup para proteção do dia a dia + vaulted backup para o requisito de conformidade de 7 anos.

Dica 4: Limites de Snapshot do Azure Files

O backup do Azure Files usa share snapshots com estas restrições:

Máximo de 200 snapshots por file share
Com backup diario: 200 snapshots = ~6,5 meses de retenção máxima
Para retenção mais longa: menos snapshots diarios ou use cronograma semanal/mensal
Armazenamento de snapshot e diferencial (só armazena blocos alterados desde o snapshot anterior)
Exemplo de custo: share de 10 TB com 5% de alteracao diaria = ~500 GB de armazenamento de snapshot para 200 snapshots

Opcoes de restauração:

Restauracao de share completo para um novo share
Restauracao individual de arquivo/pasta (recuperação em nível de item)
Restaurar para local original ou local alternativo
Não pode restaurar para uma conta de armazenamento diferente (mesma conta apenas)

Recursos de aprendizagem

Verificação de conhecimento

1. Um designer acidentalmente deletou um container inteiro com 50.000 arquivos 10 minutos atras. Qual é o método de recuperação mais rápido?

Container soft delete fornece recuperação instantanea do container inteiro deletado. Com container soft delete habilitado, o container deletado e todo seu conteúdo são retidos pelo período de retenção configurado (até 365 dias). A recuperação é uma única operação "undelete" que restaura o container inteiro imediatamente. Isso e mais rápido que point-in-time restore (que requer uma operação de restauração que pode levar tempo proporcional ao tamanho dos dados) e mais rápido que restaurar do backup vault. Container soft delete e específicamente projetado para este cenário de "delecao acidental de container inteiro".

2. Uma conta de armazenamento tem 200 TB de dados com blob versioning habilitado. Designers salvam arquivos Adobe centenas de vezes diariamente. Qual é o risco principal, e como você mitiga?

O risco principal e a explosao de custo de armazenamento por versoes acumuladas. Cada salvamento cria uma nova versao, entao um arquivo de 100 MB salvo 100 vezes/dia gera 10 GB de dados de versao diariamente por arquivo. Mitigacao: implemente políticas de lifecycle management que movam versoes anteriores para o tier Cool apos 1-7 dias, tier Archive apos 30 dias, e delete apos 90 dias. Alternativamente, desabilite versionamento para containers de alta rotatividade e confie no Azure Backup (snapshots diarios) em vez disso, que tem custos previsiveis de cronograma fixo ao inves de custos por salvamento.

3. Uma empresa precisa garantir a recuperação de dados blob mesmo se um administrador malicioso deletar a conta de armazenamento inteira. Qual mecanismo de proteção aborda isso?

Vaulted backup (Azure Backup para Blobs armazenado em um Backup vault) fornece proteção independente da conta de armazenamento de origem. Operational backup depende de recursos nativos dentro da mesma conta de armazenamento e é perdido se a conta for deletada. Vaulted backup copia dados para um Backup vault separado com seu próprio RBAC, imutabilidade e lifecycle. Adicionalmente, Azure Resource Manager locks (CanNotDelete) e Azure Policy podem prevenir delecao de conta, mas apenas vaulted backup fornece recuperação apos o fato. Combine com vault imutável para proteção máxima.

4. Point-in-time restore para blobs tem retenção máxima de 14 dias. Qual alternativa fornece capacidade de recuperação point-in-time mais longa para dados blob?

Blob versioning combinado com lifecycle management fornece recuperação point-in-time estendida. Enquanto o recurso integrado de point-in-time restore é limitado a 14 dias, blob versioning retem cada versao indefinidamente (até que políticas de lifecycle as deletem). Você pode definir regras de lifecycle para reter versoes por 90, 180 ou 365+ dias. Para recuperação de longo prazo em nível de conformidade (7+ anos), use vaulted backup com retenção estendida configurada na política de backup. O trade-off e que versionamento requer que você identifique a versao específica do blob para restaurar, enquanto point-in-time restore pode reverter um container inteiro atomicamente.

Limpeza

# Delete resource groups
az group delete --name rg-creative-assets --yes --no-wait

# Note: if soft delete is enabled, storage data persists until retention expires
# If you need immediate cleanup, disable soft delete first:
# az storage account blob-service-properties update \
# --account-name stvividcreative \
# --resource-group rg-creative-assets \
# --enable-delete-retention false

Próximo: Challenge 29: Design a Disaster Recovery Plan

Introdução​

Habilidades do exame cobertas​

Tarefas de design​

Parte 1: design de proteção de dados no Blob Storage​

Parte 2: versionamento e Point-in-Time restore​

Parte 3: Azure Backup para blobs (Vaulted backup)​

Parte 4: Backup e recuperação do Azure Files​

Criterios de sucesso​

Dicas​

Recursos de aprendizagem​

Verificação de conhecimento​

Limpeza​