Introdução
No contexto de redes industriais e telecom, backup de configuração de switch e recuperação de configuração são práticas operacionais críticas para garantir disponibilidade, conformidade e rápida restauração após incidentes. Este artigo aborda desde conceitos (running-config, startup-config, VLAN DB, ROMMON) até métodos (TFTP, SCP, SFTP, APIs) e automação com Ansible e RANCID, oferecendo instruções aplicáveis a engenheiros elétricos, projetistas OEM, integradores e gestores de manutenção. Cito referências normativas relevantes (ex.: IEC/EN 62368-1, IEC 60601-1) quando aplicável ao requisito de segurança da infraestrutura, e conceitos de engenharia como MTBF e Fator de Potência (PFC) na ótica da disponibilidade das fontes de alimentação que sustentam a rede.
A abordagem é prática e orientada a decisões: iremos definir quando o backup é obrigatório, mapear riscos e KPIs (RTO/RPO), comparar protocolos e ferramentas, e fornecer scripts e playbooks para Cisco IOS/IOS-XE, NX-OS, Junos e HPE. Também descrevemos procedimentos de teste, verificação de integridade (checksums) e estratégias de versionamento para facilitar rollback seguro. Este artigo pretende ser um guia técnico de referência — use-o como base para políticas operacionais e PoC de automação.
Para aprofundar e manter continuidade técnica na sua operação, consulte também artigos relacionados no blog da IRD.Net (buscas relacionadas: https://blog.ird.net.br/?s=backup e https://blog.ird.net.br/?s=rede). Para soluções de hardware e fontes industriais que suportem políticas de alta disponibilidade, veja nossos produtos em https://www.ird.net.br/produtos e, para contato comercial ou suporte técnico, acesse https://www.ird.net.br/contato.
O que é backup e recuperação de configuração de switch e quando aplicar
Definição e tipos de arquivos
Um backup de configuração de switch é a cópia persistente das configurações do equipamento (por exemplo, running-config e startup-config) para um repositório externo. O running-config contém o estado atual na RAM; o startup-config é o arquivo gravado na NVRAM que o equipamento usa ao boot. Outros artefatos relevantes incluem VLAN DB, arquivos de ROMMON e imagens de firmware/IOS que frequentemente precisam ser versionadas junto com a configuração.
Diferença entre backup, snapshot e export
Enquanto um backup é uma cópia navegável e restaurável do estado lógico, um snapshot muitas vezes representa um ponto no tempo com metadados adicionais (timestamps, checksums). Em switches, backup costuma implicar na capacidade de restaurar e operacionalizar o equipamento; snapshot pode ser usado para testes rápidos e diffs. A distinção é importante para definir RPOs: snapshots rápidos podem ser frequentes, backups formais devem ter retenção e criptografia.
Quando executar backups
Execute backups sempre que houver: mudanças de topologia, atualizações de firmware/IOS, manutenção planejada, transferência de propriedade do equipamento, ou quando um equipamento opera como parte crítica de SLA. Situações de risco incluem falha de hardware (MTBF estimado), corrupção de NVRAM e rollback de versão. Em ambientes regulados (ex.: IEC/EN 62368-1 implicando requisitos de segurança elétrica ou IEC 60601-1 em ambientes médicos), mantenha políticas de retenção documentadas e auditáveis.
Por que investir em estratégia de backup e recuperação: benefícios, riscos e requisitos
Benefícios operacionais e KPIs
Uma estratégia formal reduz RTO/RPO e melhora a auditabilidade. Métricas essenciais incluem Tempo de Recuperação (RTO), Ponto de Recuperação (RPO), taxa de sucesso de restauração e frequência de backups. Benefícios concretos: redução do MTTR, consistência entre ambientes (produção/teste), e capacidade de restauração após atualização de IOS sem impacto prolongado.
Avaliação de riscos e requisitos de conformidade
Avalie: perda de configuração, corrupção de imagem, acesso não autorizado e falhas elétricas (considere fontes com PFC e redundância para reduzir downtime). Para conformidade, mantenha trilhas de auditoria e retenção conforme políticas internas e normas aplicáveis. Requisitos técnicos incluem autenticação forte, criptografia em trânsito/repouso e segregação de rede entre management plane e data plane.
Requisitos organizacionais
Defina responsáveis, SLAs de backup, e cadências (diárias/semanais/mensais) com políticas de retenção. Integre inventário (CMDB) e documentação de mudanças para correlacionar backups a eventos. Garanta testes periódicos de restore em laboratório com verificação de integridade (SHA256/MD5) e aprovações formais antes de promover alterações em produção.
Métodos e protocolos suportados: TFTP, FTP(S), SCP, SFTP, APIs e ferramentas de automação
Comparação de protocolos de transferência
- TFTP é simples e amplamente suportado, mas não possui autenticação/criptografia — adequado apenas em redes management isoladas e protegidas.
- FTP/FTPS oferece mais recursos; FTPS acrescenta TLS, mas não é tão difundido em equipamentos de rede.
- SCP/SFTP (SSH) são preferíveis por autenticidade e criptografia (recomendado para ambientes produtivos), com overhead de CPU/latência aceitável.
- HTTP(S) / APIs começam a ser padrão em equipamentos modernos (RESTful), permitindo automação e integração com sistemas de gerenciamento.
Ferramentas open-source e enterprise
- RANCID / Oxidized: coletores que versionam e armazenam configurações (bom para versioning e diffs).
- Ansible / Netmiko / Nornir: orquestração e execução de playbooks, ideal para automação de larga escala.
- SolarWinds / ManageEngine (enterprise): consoles que agregam backup, monitoramento e alertas.
Escolha com base em escalabilidade, compatibilidade de plataformas (Cisco/Juniper/HPE), e requisitos de segurança.
Segurança, escalabilidade e requisitos de rede
Implemente segregação de management VLAN, ACLs restritivas, autenticação baseada em chave e TLS/SSH. Para escalabilidade, prefira soluções que façam conexões simultâneas (pooling) e que suportem compressão e checksums. Planeje largura de banda e QoS para operações de backup massivo, evitando impacto no tráfego de produção.
Guia prático passo a passo: comandos, scripts e procedimentos de restore para Cisco, Juniper e HPE
Cisco (IOS / IOS-XE / NX-OS) — Backup e Restore básicos
Comandos úteis:
- Backup via TFTP: copy running-config tftp://192.168.1.100/hostname-running.cfg
- Backup via SCP: copy running-config scp://[email protected]:/backups/hostname-running.cfg
- Verificar startup: show startup-config
- Para restaurar: copy tftp://192.168.1.100/hostname-startup.cfg startup-config ; reload
Em NX-OS, use copy running-config scp: e checar show version para compatibilidade de imagem. Após restore, valide interfaces, VLANs e STP.
Exemplo Ansible (snippet):
- name: Backup running-config
cisco.ios.ios_config:
backup: yes
backup_options:
filename: "{{ inventory_hostname }}-{{ ansible_date_time.iso8601 }}.cfg"
dir_path: "/var/backups/switches"
Juniper (Junos) — Backup e Restore
Comandos Junos:
- Salvar configuração ativa: request system configuration rescue save
- Exportar config: cli > show configuration | save /var/tmp/host.conf
- Transferir via SCP: scp /var/tmp/host.conf [email protected]:/backups/
- Restaurar: file replace /config/juniper.conf.gz scp://user@host:/path/juniper.conf ; request system configuration re-apply
Valide commit e rollback (Junos tem rollback por padrão: show system rollback).
Exemplo Netmiko (Python):
- Conexão SSH, executar ‘show configuration’, salvar conteúdo em repositório com timestamp e checksum.
HPE (Aruba / Comware) — Comandos e práticas
Comandos comuns:
- show startup-config / show running-config
- copy running-config tftp 192.168.1.100 backup.cfg
- request system configuration rescue save/restore (quando disponível)
Procedimentos de restore incluem salvar a configuração no path correto e reiniciar o serviço/ equipamento. Para switches HPE Comware, valide os grupos de VLAN/ACL após restauração.
Checklist pós-restore (válido para todas as plataformas):
- Verificação de integridade (checksum), comparação de diffs entre versões, teste de conectividade de management, validação de rotas/STP, e confirmação de que serviços dependentes retomaram normalmente.
Erros comuns, troubleshooting avançado e melhores práticas operacionais
Falhas recorrentes e causas
Erros frequentes: backups corrompidos por transferência incompleta (TFTP), inconsistências entre running/startup após gravação, perda de configurações por escrita na NVRAM falha, ou rollback inadvertido por scripts automatizados. Falhas elétricas (fonte sem PFC ou sem redundância) podem causar corrupção de NVRAM durante gravação.
Técnicas de troubleshooting e validação
- Use checksums (SHA256) para validar arquivos logo após transferência.
- Realize diffs automatizados (git/oxidized/RANCID) para identificar mudanças não autorizadas.
- Em caso de imagens incompatíveis após restore, use ROMMON para recuperar imagem anterior (no Cisco: modo rommon e boot manual).
- Habilite logs detalhados e syslog centralizado (com retenção) para correlacionar eventos de backup/restore.
Versionamento, rollback e hardening
Armazene configurações em repositórios git/GitLab para versionamento e tagging; mantenha políticas de retenção e branches (produção, teste). Teste rollback em laboratório com automação (Ansible playbooks que aplicam config e validam health-checks). Implemente controle de acesso baseado em função (RBAC), autenticação multifator para servidores de backup, e criptografia em repouso (AES-256) para backups sensíveis.
Implementação, automação contínua e roadmap estratégico: auditoria, integração com NMS/CI e métricas
Plano faseado de implementação
Adote um roadmap PoC → Piloto → Produção:
- PoC: escolha um subset de switches, valide protocolos e ferramenta (ex.: Oxidized + Git).
- Piloto: expanda para uma área/plantão, integre com NMS (SNMP traps) e ajuste alertas.
- Produção: escale, automatize cadências e integre ao CMDB/CI.
Inclua responsabilidades, cronograma e critérios de aceite (testes de restore bem-sucedidos em laboratório).
Pipelines de automação e integração
Desenvolva pipelines que envolvam:
- Orquestração (Ansible/Rundeck) para backups agendados.
- Repositórios Git para versionamento.
- Integração com NMS/CMDB para atualização automática de inventário.
- Relatórios periódicos e dashboards com KPIs (RTO, RPO, taxa de sucesso de backups).
Automatize validações pós-restore (smoke tests) e alertas via webhook ou sistema de tickets quando divergências forem detectadas.
Métricas, auditoria e evolução tecnológica
Defina KPIs mensuráveis: tempo médio de restauração, percentual de backups válidos, número de restores testados por trimestre. Para auditoria, gere relatórios com logs imutáveis (WORM ou blockchain-based hashes) e retenha samples para compliance. Planeje evolução: IaC para rede, testes automatizados de configuração e integração contínua de templates de configuração.
Para aplicações que exigem alta robustez e continuidade operacional, avalie o uso de soluções de alimentação redundante e condicionada: conheça nossas fontes industriais e módulos de redundância em https://www.ird.net.br/produtos para manter a disponibilidade da camada de gerenciamento da rede.
Conclusão
Este artigo consolidou o conhecimento necessário para projetar e operacionalizar um programa robusto de backup de configuração de switch e recuperação de configuração, cobrindo definições, riscos, protocolos (TFTP, SCP, SFTP, APIs), ferramentas (RANCID, Oxidized, Ansible) e procedimentos práticos para Cisco, Juniper e HPE. Reforçamos a importância de políticas de governança, testes regulares de restore e automação para reduzir RTO/RPO e garantir compliance.
Decisões críticas incluem escolha de protocolo (priorize SFTP/SCP e APIs quando possível), implementação de versionamento (Git/Oxidized) e integração com CMDB/NMS para visibilidade. Meça sucesso com KPIs operacionais e audite periodicamente. Para escala e segurança, implemente criptografia em trânsito e repouso, RBAC e segregação de management plane.
Perguntas, comentários e desafios práticos são bem-vindos: relate sua topologia, equipamentos e requisitos de SLA nos comentários para que possamos sugerir playbooks e ajustes específicos. Para mais artigos técnicos consulte: https://blog.ird.net.br/