Applications
Services and dependencies that support the business.
BACKUP & DISASTER RECOVERY
Backup only fulfils its purpose when recovery works.
Hardware failures, human error, corruption, outages, security incidents and higher-impact events can interrupt services and compromise business-critical data.
That is why protection cannot end with creating a copy.
Add Solution designs, implements and evolves Backup & Disaster Recovery strategies that consider criticality, retention, isolation, immutability, RPO, RTO, recovery testing and the procedures required to restore data, workloads and services when they are actually needed.
LOCALOFF-SITEISOLATED
RECOVERABILITY
RPORTORESTORERUNBOOK
ENGENHARIA APLICADA
Proteção de dados só se comprova quando a recuperação é possível e conhecida.
A Add Solution conecta criticidade, RPO, RTO, cópias, imutabilidade, isolamento, testes e procedimentos em uma estratégia recuperável.
Arquitetura, execução e operação tratadas como partes da mesma responsabilidade.
FROM BACKUP TO RECOVERABILITY
The goal is not to complete the backup. It is to be able to recover.
A limited view ends with a job, backup and success status. Resilience connects workload, protection, copies, validation, recovery and return to operation.
Backup measures copy creation. Recoverability measures our ability to use it.
WHAT ARE WE PROTECTING?
Not all data has the same importance. Not all systems can wait the same amount of time.
A strategy starts with the business and applications, not repository capacity. Criticality, volume, data change and retention guide classification.
Databases
Consistency and recovery according to the workload.
Virtual machines
VMs, applications, storage and dependencies.
Servers
Physical systems, configurations and data.
Files
Structured and unstructured data.
Cloud workloads
Resources, services, retention and recovery.
Configurations
Elements required to rebuild services.
Dependencies
Network, identity, DNS, integrations and people.
RPO & RTO
How much can we lose? How long can we wait?
Recovery objectives connect business tolerance, protection architecture and restoration capability.
The recoverable point.
It represents the objective related to the point in time to which data must be recoverable, reflecting the defined tolerance for data loss.
The restoration time.
It represents the time objective for restoring the service or process after an interruption.
LAST POINTRPO → INCIDENTE → RTOSERVICE RECOVERED
COMPLEMENTARY MECHANISMS
Backup ≠ snapshot ≠ replication ≠ high availability ≠ DR.
Each mechanism addresses different scenarios. None should automatically be treated as a substitute for another.
Backup
Copies intended for recovery according to policy and retention.
Snapshot
State of data or a workload for platform-specific purposes.
Replication
Data or workloads reproduced at another destination according to the architecture.
High availability
Continuity in the face of certain types of failure.
Disaster Recovery
Coordinated recovery from higher-impact events.
Copy redundancy must reduce dependencies, not merely multiply files.
The 3-2-1 principle considers three copies, two media or domains according to the strategy, and one copy outside the primary environment. Evolutions such as 3-2-1-1-0 add isolation or immutability and planned validations.
They are architecture references, not absolute guarantees.
A copy subject to the same compromise may cease to be trustworthy.
Protected retention, deletion controls, separation of privileges, isolation and repository protection reduce certain alteration or deletion risks.
Immutability does not replace architecture, security or testing.
Copies must reduce shared dependencies.
Physical, logical, offline or external isolation, or independent controls, may be part of the strategy. The more a copy shares its environment and credentials with production, the greater the common risk.
During an incident, backups can also become targets.
Credentials, privileges, repositories, immutability, MFA where applicable, administrative separation, monitoring and testing must work together.
Backup does not prevent an attack. Recovery helps limit the impact on returning to operation.Cybersecurity PAM & Identity Security
Protecting a VM requires understanding what exists inside and around it.
VMs, applications, consistency, storage, snapshots used in certain processes, network, dependencies and restoration form the scenario. A snapshot is not a backup.
VirtualizationDifferent workloads require coherent protection mechanisms.
Physical servers, files, databases, applications, configurations and structured or unstructured data may require their own consistency measures and procedures.
Servers & StorageCloud changes where data is located. It does not eliminate the responsibility to protect it.
Snapshots, native backup, protection services, cross-region or cross-account copies, external repositories, retention, immutability and recovery may be included according to the workload.
CloudSaaS reduces responsibility for infrastructure, but not necessarily for your data.
Organisations need to understand what the provider protects, for how long, what can be recovered and what responsibility remains with the customer.
DISASTER RECOVERY
Recovering data is different from recovering an operation.
Backup recovers information. Disaster Recovery organises how infrastructure, connectivity, identity, applications, people and procedures enable the service to exist again.
01Data
02Infrastructure
03Connectivity
04Identity
05Applications
06Procedures
The destination must meet the recovery objectives.
Another Data Center, colocation, cloud, secondary infrastructure or hybrid combinations may be evaluated according to RPO, RTO, criticality, cost, complexity and dependencies.
Data Center Cloud ConnectivityStarting every server does not mean recovering the service.
Recovery must respect dependencies. The order varies by environment and must be validated.
Infraestrutura → Networking / DNS / Identity → Database → Application services → Front-end / integrações → Validação
During a crisis, improvisation costs time.
Responsibilities, contacts, sequence, procedures, dependencies, validations, escalations and decision criteria must be documented and evolve with the environment.
The worst time to discover a failure is during the incident.
Verification, integrity checks, restoration of files and workloads, application testing and DR simulations may be combined according to criticality.
A successful backup is operational evidence. A tested restore is evidence of recoverability.
A silently degraded process may remain invisible until it is needed.
Jobs, failures, duration, capacity, repositories, retention, growth, latest points, anomalies and alerts need continuous monitoring.
AI & Observability Command CenterRetention is a recovery decision. Capacity is a consequence.
Volume, change rate, frequency, retention, compression, deduplication when available, growth, repositories and costs must reflect applicable operational, internal, contractual and regulatory requirements.
If you had to recover your environment today, would you know where to start?
We can assess workloads, policies, retention, repositories, immutability, RPO, RTO, dependencies and procedures to identify risks before an incident.
Request an assessmentADD SOLUTION METHOD
From business criticality to tested recovery.
More than 15 years of experience in infrastructure and critical environments connecting backup, storage, virtualisation, cloud, networks, identity, security and operations.
- 01
Understand
Data, workloads and dependencies.
- 02
Classify
Criticality and requirements.
- 03
Define RPO/RTO
Establish recovery objectives.
- 04
Architect
Copies, retention, destinations and recovery.
- 05
Protect
Implement the strategy.
- 06
Isolate
Reduce risks shared by copies and production.
- 07
Validate
Confirm integrity and availability.
- 08
Document
Create procedures and runbooks.
- 09
Observe
Monitor continuously.
- 10
Test
Exercise recovery.
- 11
Evolve
Adapt protection to changes.
TECHNOLOGIES & PRODUCTS
Here we sell strategy, engineering, implementation and recovery.
Manufacturers, platforms, software, appliances and related services belong on the technology pages. Architecture starts with risks and recovery objectives.
Backup & Resilience TechnologiesPERGUNTAS FREQUENTES
Decisões importantes sobre Backup & Disaster Recovery
Respostas objetivas para dúvidas técnicas e operacionais que costumam surgir antes de um projeto.
01Backup bem-sucedido garante que o restore funcionará?
Não. O sucesso do job é uma evidência operacional. Validações e testes de recuperação produzem evidências adicionais de recuperabilidade.
02Snapshot substitui backup?
Não. Snapshot e backup possuem objetivos diferentes e devem ser avaliados dentro da arquitetura de proteção.
03Imutabilidade impede ransomware?
Não. Ela reduz determinados riscos de alteração ou exclusão das cópias, mas não substitui segurança, isolamento, arquitetura e testes.
04O que significam RPO e RTO?
RPO está relacionado ao ponto recuperável e à tolerância definida à perda de dados. RTO representa o objetivo de tempo para restabelecimento do serviço ou processo.
05Cloud já inclui toda a proteção necessária?
Não necessariamente. Cada serviço possui responsabilidades e recursos próprios; workloads cloud também precisam de uma estratégia explícita de proteção e recuperação.
06A Add Solution realiza testes de recuperação?
A estratégia pode incluir verificação, validação de integridade, restore de arquivos e workloads, testes de aplicações e simulações de DR conforme criticidade e arquitetura.
FALE COM UM ESPECIALISTA
Vamos conversar sobre Backup & Disaster Recovery.
Share the context of your environment, the perceived impacts and the results your organization seeks. Add Solution will direct the conversation to the most appropriate experts.
CONTEXTO DA CONVERSABackup & Disaster RecoveryOrigem e interesse são registrados automaticamente no atendimento.