Um único comando digitado incorretamente apagou Toy Story 2 da existência em 1998. O sistema de backup da Pixar havia falhado silenciosamente semanas antes. Um backup do portátil de uma mãe permitiu à equipa recuperar quase tudo o que foi perdido.Um único comando digitado incorretamente apagou Toy Story 2 da existência em 1998. O sistema de backup da Pixar havia falhado silenciosamente semanas antes. Um backup do portátil de uma mãe permitiu à equipa recuperar quase tudo o que foi perdido.

Para o infinito... e apagar

2025/10/30 04:34
Leu 5 min
Para enviar feedbacks ou expressar preocupações a respeito deste conteúdo, contate-nos em crypto.news@mexc.com

Em 1998, ocorreu um desastre na Pixar. Um único comando mal digitado — rm -rf / — começou a apagar Toy Story 2 da existência. Personagem por personagem, cena por cena, o filme que levou um ano para ser construído desapareceu em segundos. A equipa assistiu incrédula enquanto o chapéu do Woody, as asas do Buzz e cenários inteiros desapareciam diante dos seus olhos. Quando os engenheiros correram para restaurar a partir dos backups, descobriram algo pior — o sistema de backup tinha falhado silenciosamente semanas antes. Como profissionais de TI, todos nós já passamos por isso antes, mas o que podemos aprender com isto e levar o Buzz para a sua nave a tempo?

A Festa do Andy

Esta "memória central" ocorreu em 1998, com o cofundador da Pixar, Ed Catmull, a recordá-la no seu livro chamado "Creativity, Inc.". A história começa com um infeliz funcionário anónimo da Pixar que estava a fazer uma limpeza de rotina de ficheiros nos servidores internos quando acidentalmente introduziu um comando de eliminação na pasta raiz de Toy Story 2... Isso são boas notícias. Este "evento de atualização do currículo" resultou no desaparecimento de modelos de personagens e recursos, e os servidores de ficheiros foram rapidamente desligados.

\ Infelizmente, nesse momento, cerca de 90% do trabalho feito em Toy Story 2 tinha desaparecido, e o sistema de backup da sequela também não estava a funcionar corretamente há cerca de um mês. Neste ponto, Toy Story 2 teria que começar do zero - ou a produção seria completamente descartada.

Uma Mãe Salva o Dia

Uma mãe salva o dia, assim como quando Buzz e Woody se unem para voltar para casa. Galyn Susman, a supervisora de direção técnica do filme, que seria afetada pelos despedimentos da Disney em 2023, tinha uma cópia do projeto Toy Story em casa. Galyn estava de licença maternidade e decidiu continuar a trabalhar a partir de casa – algo que é visto como normal hoje - mas na época, tabu. Ser mãe e sempre planear com antecedência, assim como ter filhos, fez com que ela levasse o seu trabalho para casa uma vez por semana. Isto foi um enorme benefício porque permitiu que ela se mantivesse atualizada e mantivesse um backup confiável de Toy Story 2.

\ Tal como um recém-nascido, a Pixar transportou cuidadosamente o portátil de volta ao escritório, embalado e envolto em cobertores durante a viagem de carro - imagino que até tocaram música de embalar para o portátil... ou talvez isso seja algo que eu faria. Ter o backup do portátil de Susman permitiu à equipa copiar os ficheiros e recuperar quase tudo o que tinha sido perdido.

\ Foi uma ocasião alegre com muitos high fives, e talvez tenha colocado um sorriso no rosto da pessoa responsável pela eliminação. A cópia de backup de Susman não tinha o filme inteiro no seu computador, mas eles conseguiram recuperar o suficiente para completar e entregar Toy Story 2 a tempo. Coloque a música inspiradora e dance como se ninguém estivesse a observar. Que história, não é?

\ E quanto ao funcionário que apagou os ficheiros? Fico feliz que esteja a prestar atenção. Até agora, não há relatos de que tenha sido despedido ou enfrentado consequências. Direi que é fácil imaginar a tensão na altura, e talvez um projeto futuro com ele a trabalhar no processo de backup.

Lições Aprendidas

A experiência serve como uma valiosa lição, não apenas para as pessoas da Pixar, mas para profissionais de TI em todo o mundo. Há um forte compromisso em criar múltiplos backups e implementar medidas de segurança extras para evitar que tais incidentes aconteçam novamente.

\ Nesta história, o sistema de backup tinha falhado meses antes, e ninguém notou. Isso significava que não havia backups para restaurar, e os negócios estavam parados. Isso soa familiar aos eventos de hoje? Deveria, porque acontece muito nos dias de hoje. O que as empresas podem fazer para se manterem seguras deste desastre?

Backups

  • A regra 3-2-1 - a regra de backup de dados é uma estratégia que recomenda manter três cópias dos seus dados, em dois tipos diferentes de meios de armazenamento, com uma cópia armazenada fora do local. Este método garante redundância e protege os dados de um único ponto de falha, como falha de hardware, roubo ou um desastre local.

    \

  • Backups externos - Um backup de dados externo e isolado armazena uma cópia dos seus dados numa localização física ou na nuvem separada (externa) e mantém-na desconectada da sua rede primária (isolada). Esta combinação protege os seus dados de desastres localizados e ameaças cibernéticas como ransomware, que não pode aceder remotamente ou corromper a cópia de backup isolada.

    \

  • RPO & RTO - Recovery Point Objective e Recovery Time Objective. Não é apenas importante, mas vital para a continuidade do seu negócio e sobrevivência em caso de desastre. A maioria das empresas afirma que tem backups testados e que passam nas auditorias, mas quando têm de restaurar os seus sistemas quando ocorre um desastre, demora muito mais tempo do que tinham planeado, e o negócio perde dinheiro por causa disso.

Controlos Técnicos e Permissões: Privilégios Restritos de Eliminação de Pastas.

  • A prevenção mais simples teria sido definir permissões no servidor para que nem todos os funcionários pudessem eliminar o diretório de nível superior do filme. Conceder acesso de "controlo total" a um grande grupo de utilizadores é comum em ambientes colaborativos, mas é um grande risco de segurança. Apenas um pequeno número de administradores deve ter permissão para executar comandos de "eliminação" em pastas críticas de alto nível.

\

  • Restrições a nível de comando. O funcionário usou o comando rm -r do Linux, que elimina um diretório e todo o seu conteúdo recursivamente. Um sistema mais avançado poderia ter impedido que este comando fosse executado no nível do diretório do projeto mais alto, seja com um script especial ou exigindo uma segunda etapa de autenticação.

    \

\

Isenção de responsabilidade: Os artigos republicados neste site são provenientes de plataformas públicas e são fornecidos apenas para fins informativos. Eles não refletem necessariamente a opinião da MEXC. Todos os direitos permanecem com os autores originais. Se você acredita que algum conteúdo infringe direitos de terceiros, entre em contato pelo e-mail crypto.news@mexc.com para solicitar a remoção. A MEXC não oferece garantias quanto à precisão, integridade ou atualidade das informações e não se responsabiliza por quaisquer ações tomadas com base no conteúdo fornecido. O conteúdo não constitui aconselhamento financeiro, jurídico ou profissional, nem deve ser considerado uma recomendação ou endosso por parte da MEXC.

USD1 Genesis: 0 Fees + 12% APR

USD1 Genesis: 0 Fees + 12% APRUSD1 Genesis: 0 Fees + 12% APR

New users: stake for up to 600% APR. Limited time!