✨ Bem-vindo ao meu espaço! ✨
Este blog é o diário de um otaku apaixonado por animes, tecnologia de mainframe e viagens.
Cada entrada é uma mistura única: relatos de viagem com fotos, filmes, links, artigos e desenhos, sempre buscando enriquecer a experiência de quem lê.
Sou quase um turista profissional: adoro dormir em uma cama diferente, acordar em um lugar novo e registrar tudo com minha câmera sempre à mão.
Entre uma viagem e outra, compartilho também reflexões sobre cultura otaku/animes
☕ Um Café no Bellacosa Mainframe — Especial Red Team
Colocamos a Ferrari em Ré — Por Que Rollback Não É Backup
🚗 O glorioso momento em que alguém descobre que desfazer uma ação não significa desfazer suas consequências
Existe uma cena em Curtindo a Vida Adoidado que deveria ser exibida em todo curso de operações, recuperação, banco de dados, continuidade e resposta a incidentes.
A Ferrari foi usada.
A quilometragem aumentou.
O problema precisa desaparecer.
Surge então uma ideia absolutamente maravilhosa em sua simplicidade:
vamos colocar o carro em marcha a ré.
Se andar para frente aumentou a quilometragem...
andar para trás deveria diminuir.
Lógica cristalina.
Elegante.
Quase matemática.
E completamente incapaz de apagar tudo o que já aconteceu.
É neste momento que Ferris Bueller encontra uma das verdades mais dolorosas de produção:
desfazer estado não significa desfazer história.
Você pode voltar um valor.
Pode restaurar um arquivo.
Pode carregar um backup.
Pode executar ROLLBACK.
Pode recuperar uma tabela.
Pode restaurar um dataset.
Pode voltar configuração.
Mas talvez não consiga desfazer:
a mensagem enviada;
o pagamento processado;
o cliente que recebeu informação errada;
o arquivo copiado;
a fraude executada;
o log gerado;
o segredo exposto;
o processo disparado;
a decisão humana tomada.
Em outras palavras:
Produção não possui Ctrl+Z emocional.
Bem-vindo ao oitavo episódio de:
SAVE FERRIS — Red Team para Quem Aprendeu que o Sistema Também Mata Aula
Hoje vamos falar da Ferrari.
Mas, na verdade, vamos falar de backup, restore, rollback, journaling, Db2, VSAM, recuperação de transações e daquela reunião pós-incidente em que alguém pergunta:
— Dá para voltar?
E toda a sala fica em silêncio.
🔴 Primeiro erro: acreditar que “voltar” é uma coisa só
Em tecnologia usamos várias palavras como se significassem a mesma coisa.
Backup.
Restore.
Rollback.
Recovery.
Undo.
Rebuild.
Reprocess.
Failback.
Mas não são a mesma coisa.
Cada uma atua em uma camada diferente.
Ferris descobriria isso rapidamente.
💾 Backup não é rollback
Backup é uma cópia de estado em algum momento.
Ele responde:
“Temos uma versão anterior?”
Isso é importante.
Mas não significa que você consegue voltar instantaneamente.
Exemplo:
00:00 BACKUP
02:00 INCIDENT
05:00 DETECTION
Se você restaurar o backup da meia-noite...
o que acontece com tudo que ocorreu entre 00:00 e 05:00?
Pedidos?
Pagamentos?
Cadastros?
Transações?
Logs?
Talvez você recupere consistência técnica destruindo realidade de negócio.
Ferrari voltou para garagem.
Mas a cidade inteira já viu o carro.
🔁 Rollback é outra coisa
Rollback normalmente significa desfazer uma transação ou conjunto de mudanças antes da confirmação definitiva.
Em banco de dados, isso é natural.
Você inicia uma unidade de trabalho.
Faz alterações.
Algo dá errado.
Executa rollback.
O banco volta ao estado anterior daquela transação.
Perfeito.
Mas perceba:
isso funciona porque o sistema ainda possui contexto suficiente para desfazer.
Depois que uma mudança é confirmada, propagada e consumida por outros sistemas, a história complica.
☕ COMMIT é quase um rito religioso
Quem trabalha com transação entende.
Antes do COMMIT, o universo ainda pode ser negociado.
Depois do COMMIT...
a conversa muda.
UPDATE...
UPDATE...
UPDATE...
COMMIT
Pronto.
A transação foi assumida como válida.
Agora talvez existam:
logs;
replicações;
mensagens;
processos downstream;
auditoria;
integrações.
A quilometragem já saiu da Ferrari e entrou no ecossistema.
🧠 O sistema pode voltar, o mundo não
Essa é a essência.
Imagine:
um operador envia uma transferência errada.
Depois percebe.
Você pode corrigir o registro.
Mas o dinheiro talvez já tenha saído.
Pode restaurar a tabela.
Mas outro sistema já consumiu o evento.
Pode reverter status.
Mas cliente já recebeu e-mail.
Pode apagar arquivo.
Mas alguém já copiou.
Recuperação técnica não garante recuperação operacional.
🚗 A Ferrari em marcha a ré é rollback sem modelo de consequência
Eles olharam apenas para o indicador:
quilometragem.
Queriam mudar um número.
Mas o evento foi maior.
O carro saiu.
Rodou.
Foi visto.
Foi usado.
Voltou.
A história existiu.
Esse é o erro clássico de sistemas:
confundir estado observável com totalidade do evento.
📜 Logs existem porque história importa
Um bom sistema não registra apenas o estado atual.
Registra também eventos.
Quem alterou.
Quando.
O que era antes.
O que ficou depois.
Isso é fundamental para auditoria e recuperação.
Se você só sabe o estado final, perde contexto.
🧾 Journaling: o diário do sistema
Journaling existe exatamente porque operações importam.
A beleza da cena é que o plano de marcha a ré não apenas falha conceitualmente.
A situação piora dramaticamente.
É quase uma alegoria perfeita de recovery improvisado.
Você tenta corrigir incidente.
Cria outro.
Quem nunca?
💥 “A correção causou indisponibilidade”
Clássico.
Script emergencial.
Configuração errada.
Restore incompleto.
Rollback impossível.
O remédio cria novo problema.
Isso é por que mudança durante incidente precisa de controle.
🧠 Change Management continua existindo em crise
Urgência não elimina risco.
Pode simplificar processo.
Mas não significa:
faça qualquer coisa.
Mudanças emergenciais também precisam de:
registro;
aprovação;
plano de retorno;
validação.
🔁 O plano de rollback precisa existir antes da mudança
Essa frase é fundamental.
Não depois.
Antes.
Toda mudança deveria perguntar:
se falhar, como voltamos?
Se resposta for:
“depois vemos”,
você acabou de criar dívida operacional.
🔵 Blue Team e Operations precisam conversar
Segurança detecta.
Operações recupera.
DBA restaura.
Aplicação valida.
Negócio confirma.
Incidente atravessa times.
Recovery é colaborativo.
🧠 Técnica e negócio precisam concordar sobre “recuperado”
Infra diz:
servidor está online.
DBA:
banco está consistente.
Aplicação:
serviço responde.
Negócio:
clientes ainda estão vendo saldo errado.
Então não recuperou.
📊 Recovery precisa de critérios
Não basta “verde no dashboard”.
Precisamos validar:
integridade;
completude;
reconciliação;
transações;
acessos;
segurança.
Ferrari dentro da garagem não basta.
Precisamos saber se o pai percebeu.
🧾 Reconciliação
Especialmente em sistemas financeiros.
Comparar:
origem;
destino;
totais;
contagens;
valores.
Isso encontra discrepâncias depois de recuperação.
🦖 Db2 + CICS + MQ: recovery coordenado
Em sistemas empresariais, vários componentes interagem.
Db2 atualiza.
CICS coordena.
MQ envia.
Recuperação precisa respeitar consistência entre componentes.
Não adianta um voltar para 10h e outro ficar em 10h30.
🕰️ Time consistency
Esse é um problema real.
Quando múltiplos sistemas têm backups em horários diferentes, restore pode criar mundos paralelos.
Sistema A pensa que evento aconteceu.
Sistema B não.
Agora nasce reconciliação dolorosa.
🔐 Cyber Recovery
Hoje fala-se muito em cyber recovery.
Não apenas recuperar hardware.
Recuperar de ataque.
Isso exige:
ambiente limpo;
cópias confiáveis;
validação;
isolamento;
credenciais novas;
forense.
É muito mais amplo.
🧪 Clean Room
Em certos cenários, você recupera num ambiente isolado.
Valida antes de reconectar.
Porque não quer restaurar malware junto.
Ferrari passa por inspeção antes de voltar para garagem.
🧠 Backup infectado também existe
Se comprometimento aconteceu semanas antes e você não percebeu, backup pode conter persistência.
Então:
qual ponto é realmente limpo?
Logs ajudam.
Forense ajuda.
Não é trivial.
🕵️ Detection latency afeta recovery
Quanto mais tempo atacante fica sem ser detectado, mais difícil saber onde voltar.
Incidente identificado em 5 minutos?
Ótimo.
Depois de 60 dias?
Boa sorte.
📉 MTTD encontra RPO
Mean Time To Detect interfere em recuperação.
Se você demora para detectar corrupção, pode ter backups já contaminados.
Detecção não é só segurança.
É recovery.
🚗 A Ferrari ensina observabilidade
Se Cameron tivesse registro claro de:
quem tirou;
quando;
quanto rodou;
onde;
talvez não tentasse resolver com marcha a ré.
Informação reduz pânico.
🧠 Pânico produz rollback ruim
Em incidente, a primeira vontade é voltar.
Mas recovery precipitado pode destruir evidência.
Antes de apagar:
preserve.
Colete.
Registre.
Depois recupere.
Forense e operação precisam equilibrar.
🔬 Preserve Evidence
Imagem de disco.
Logs.
Memória quando necessário.
Eventos.
Artefatos.
Porque depois do restore talvez você perca pistas.
Ferrari lavada demais perde impressão digital.
🧾 Cadeia de custódia
Em incidentes graves, evidência pode ter valor jurídico.
Quem coletou?
Quando?
Como preservou?
Integridade.
Mais uma vez: história importa.
☕ Produção não possui memória emocional, mas nós possuímos
Sistemas podem voltar.
Pessoas lembram.
Clientes lembram.
Auditores lembram.
Reguladores lembram.
Diretores lembram.
É por isso que incidentes têm efeitos duradouros.
🎬 Ferris tentou resolver um problema técnico que já era humano
A quilometragem era um indicador.
O verdadeiro problema era:
Cameron havia quebrado confiança com o pai.
Não existe rollback técnico para isso.
A cena é genial justamente porque mostra limite da reversibilidade.
🧠 Segurança também lida com confiança
Depois de vazamento:
usuários mudam comportamento.
Clientes questionam.
Parceiros exigem garantias.
Você pode restaurar sistema em duas horas.
Reputação pode levar anos.
Esse é o Ctrl+Z emocional que não existe.
🔴 O objetivo não é voltar no tempo
Essa é talvez a conclusão mais madura.
Recovery não é viagem temporal.
É construir um estado novo e confiável depois de algo ruim.
Você não apaga incidente.
Você aprende.
Corrige.
Recupera.
Monitora.
Segue.
🔁 Recovery como transição, não reversão
Pense:
NORMAL
↓
INCIDENT
↓
CONTAINMENT
↓
RECOVERY
↓
NEW TRUSTED STATE
Não voltamos exatamente ao começo.
Voltamos melhores.
Ou deveríamos.
☕ A pergunta final Bellacosa
Quando alguém disser:
— Dá para dar rollback?
Pergunte:
“Rollback de quê?”
Do banco?
Do arquivo?
Da aplicação?
Do pagamento?
Da mensagem?
Da confiança?
Do vazamento?
Essa pergunta salva reuniões.
🎬 Epílogo: marcha a ré não apaga estrada
A Ferrari anda para frente.
Depois anda para trás.
Mas a estrada continua existindo.
Esse é o ponto.
Sistemas guardam estado.
Negócios acumulam consequências.
Pessoas acumulam memória.
Red Team precisa pensar nisso porque ataque não termina no acesso inicial.
Importa também:
o que pode ser revertido;
o que pode ser restaurado;
o que pode ser compensado;
o que é irreversível.
Backup é essencial.
Restore é capacidade.
Rollback é mecanismo.
Journaling é memória.
Logs são história.
Recovery é processo.
E resposta a incidente é o momento em que tudo isso precisa funcionar junto.
Então, da próxima vez que alguém sugerir:
“É só voltar.”
Coloque a xícara na mesa.
Olhe para a equipe.
E responda:
“Produção não possui Ctrl+Z emocional.”
Porque às vezes você consegue colocar a Ferrari em marcha a ré.
Mas não consegue fazer o mundo esquecer que ela saiu da garagem.
☕ SAVE FERRIS.
No próximo artigo:
Rooney Invadiu a Casa Errada — Quando o Blue Team Vira o Próprio Incidente
Porque depois de errar o rollback...
nada melhor do que deixar o defensor destruir o ambiente tentando provar que estava certo.
☕ Um Café no Bellacosa Mainframe — Especial Red Team
SAVE FERRIS — Ferris Bueller’s Red Team
Uma série de 12 artigos sobre Red Team, segurança ofensiva,
engenharia social, OSINT, integridade de dados, MFA, PAM,
rollback, Blue Team, inteligência artificial, RACF e z/OS,
usando Ferris Bueller para explorar uma pergunta fundamental:
o sistema está realmente seguro ou apenas acredita que está?
Red Team
OSINT
Engenharia Social
Blue Team
MFA
PAM
IA Generativa
RACF
z/OS
Mainframe
1
Ferris Bueller Tinha um Plano de Ataque — Red Team Antes de Existir Red Team
Reconhecimento, criatividade adversarial e a ideia de que
o verdadeiro alvo nem sempre é a tecnologia:
são as suposições de quem construiu o sistema.
Red Team • Recon • Threat Modeling • Criatividade Adversarial
Nove Faltas? CTRL+Z — Quando o Banco de Dados Decide o que é Verdade
Integridade de dados, alteração de registros, privilégio,
auditoria e a perigosa diferença entre aquilo que aconteceu
e aquilo que o banco de dados afirma ter acontecido.
Integridade • Db2 • Auditoria • Insider Threat • Dados
Cameron, Atenda o Telefone — Social Engineering as a Service
Ferris → Cameron → telefone → escola → funcionário → sistema.
Nenhuma peça precisa falhar sozinha quando a cadeia inteira
possui uma combinação explorável de confiança.
Social Engineering • Swiss Cheese Model • Human Risk
O Diretor Rooney Está Procurando Malware no Lugar Errado
Firewall, SIEM, EDR e Zero Trust podem funcionar perfeitamente
enquanto engenharia social, Help Desk e processos humanos
criam outro caminho até o objetivo.
Privilégio, acesso físico, MFA, PAM, least privilege e o risco
de proteger um ativo crítico apenas com medo, confiança
e a esperança de que ninguém ousará tocá-lo.
Colocamos a Ferrari em Ré — Por Que Rollback Não É Backup
Rollback, restore, journaling, logs, Db2, VSAM e recuperação:
voltar o estado de um sistema não significa apagar
as consequências daquilo que aconteceu.
“A Vida Passa Muito Rápido” — O Red Team Depois que Todo Mundo Foi Embora
Red Team não termina em “conseguimos entrar”.
Ataque deve gerar descoberta, evidência, correção,
detecção e aprendizado para deixar a organização mais resiliente.
Red Teaming • Purple Team • Detection • Resilience • Learning
Ferris Bueller’s Red Team: Como Hackear o Sistema
Sem Precisar Roubar a Ferrari do Cameron
reúne os doze episódios e conecta Red Team,
engenharia social, IA, Blue Team e segurança de mainframe.
A série SAVE FERRIS, publicada no
Bellacosa Mainframe, utiliza situações inspiradas
em Ferris Bueller para explicar conceitos de
Red Team, cybersecurity, segurança ofensiva,
engenharia social, OSINT, Blue Team, Purple Team,
Zero Trust, MFA, PAM, inteligência artificial,
RACF, IBM z/OS, CICS, Db2, MQ e segurança de mainframe.
O fio condutor é simples: um atacante não precisa necessariamente
quebrar a tecnologia. Ele pode explorar relações de confiança,
processos, identidades, privilégios, integrações e suposições
existentes entre pessoas e sistemas.
A temporada acompanha o ciclo completo:
reconhecimento → engenharia social → acesso →
privilégio → impacto → detecção → correção → aprendizado.
Para Red Teams e Blue Teams, o objetivo final não é provar
quem é mais inteligente, mas encontrar caminhos invisíveis
antes que um adversário real os descubra.
RESTORE: quando o Apply deu ruim e você precisa voltar no tempo (sem desligar a produção)
Se APPLY é instalar e ACCEPT é oficializar, RESTORE é o botão de “desfaz” do SMP/E.
Mas não se engane: RESTORE não é CTRL+Z. Ele exige entendimento profundo de dependências, níveis de serviço e do que está no target versus no distribution.
Vamos destrinchar isso no melhor estilo Bellacosa Mainframe: sem romantismo, com realidade de produção.
O que é o comando RESTORE no SMP/E?
O RESTORE permite remover um ou mais SYSMODs aplicados no target, reinstalando o nível existente nos DLIBs (distribution libraries) de volta para as target libraries.
📌 Ponto-chave
RESTORE só funciona para SYSMODs que foram APPLIED e ainda NÃO ACCEPTED.
Na prática:
Algo foi aplicado
Quebrou, gerou erro, impacto funcional ou regressão
Você precisa voltar o código para o último nível aceito
RESTORE entra em ação.
Onde o RESTORE atua?
RESTORE é sempre direcionado a um Target Zone:
SET BDY(TZONE)
Esse target zone:
Identifica as target libraries
Mapeia qual distribution zone (DZONE) contém o backup válido
Será atualizado com os metadados corretos após o restore
📦 O SMP/E não inventa código
Ele reinstala exatamente o que está nos DLIBs.
O que o RESTORE realmente faz?
Durante o processamento, o SMP/E:
✔ Substitui os elementos do target pelos elementos do DLIB
✔ Reexecuta link-edit se necessário
✔ Copia FMID, RMID e UMID do DZONE para o TZONE
✔ Atualiza o CSI
✔ Remove registros do SYSMOD restaurado (dependendo das opções)
Ou seja:
O target volta a refletir o último nível oficialmente aceito.
RESTORE vs APPLY – parecem iguais, mas não são
APPLY
RESTORE
Usa SMPPTS
Usa DLIBs
Entrada: Global Zone + SMPPTS
Entrada: DZONE + DLIBs
Instala novo código
Reinstala código anterior
Avança nível
Retrocede nível
👉 Ambos atualizam Target Libraries e Target Zone, mas com propósitos opostos.
Inline JCLIN e SMPCDS: o detalhe que derruba gente experiente
Se o SYSMOD a ser restaurado possui inline JCLIN, o SMP/E precisa do SMPCDS.
Por quê?
Porque o SMPCDS contém:
Backup da estrutura do TZONE
Informações necessárias para restaurar corretamente macros, source e datasets
Sem isso, o RESTORE pode:
Falhar
Ou deixar o ambiente inconsistente
O comando RESTORE na prática
Exemplo básico:
RESTORE
SELECT(UP00003)
Operandos importantes
🔹 SELECT (obrigatório)
Define quais SYSMODs você quer remover.
🔹 GROUP (a parte traiçoeira)
No RESTORE, o GROUP funciona ao contrário do APPLY.
APPLY: GROUP busca pré-requisitos ausentes
RESTORE: GROUP busca SYSMODs que DEPENDEM do selecionado
👉 Se um SYSMOD depende do que você quer remover, ele também precisa ser restaurado.
🔹 CHECK (sempre use!)
RESTORE CHECK SELECT(UP00003)
CHECK:
Não altera nada
Analisa dependências
Mostra mensagens do tipo GIM35922I
📌 Dica Bellacosa:
Raramente o primeiro RESTORE CHECK resolve tudo.
Rode, leia os relatórios, ajuste o SELECT, rode de novo.
Vagner Renato Bellacosa trabalha com IBM Mainframe
desde 1988
,
é IBM Champion e especialista em COBOL, CICS, Db2,
z/OS e IBM Z. Compartilha experiências profissionais,
conhecimento técnico, história da computação e práticas
do universo mainframe para aproximar novas gerações das
tecnologias que sustentam empresas, bancos e governos
ao redor do mundo.
IBM Champion
IBM Z
COBOL
CICS
Db2
z/OS
Mainframe desde 1988
