Fazer backups de dados importantes é essencial. Mas e se for necessário retomar o trabalho imediatamente, e cada minuto conta? Nós, da Acronis, decidimos investigar quão rapidamente poderíamos iniciar o sistema. Este é o primeiro post de uma série sobre Active Restore, onde contarei como começamos esse projeto em colaboração com a Universidade de Innopolis, qual solução encontramos e em que estamos trabalhando atualmente. Detalhes a seguir.
Olá! Meu nome é Daulet Tumbaev, e hoje gostaria de compartilhar com vocês minha experiência no desenvolvimento de um sistema que acelera a recuperação de desastres. Para contar toda a trajetória do projeto, vamos começar um pouco de longe. Atualmente, trabalho na Acronis, mas também sou graduado da Universidade de Innopolis, onde terminei o mestrado em ‘Gestão de Desenvolvimento de Software’ (conhecido como MSIT-SE). Innopolis é uma universidade jovem, e seu currículo é ainda mais recente. No entanto, é baseado nos planos de estudos da Universidade Carnegie Mellon, que possui tópicos como projetos industriais.
O objetivo do projeto industrial é imergir o aluno na verdadeira processo de desenvolvimento e consolidar o conhecimento adquirido na prática. Para isso, a universidade colabora com empresas como Yandex, Acronis, MTC e dezenas de outras (no total, em 2018, a universidade tinha 144 parceiros). Durante essa colaboração, as empresas apresentam ao universitário suas áreas de atuação, e os alunos escolhem um dos projetos que mais os interessam e que está em linha com seu nível de preparação. Há apenas dois anos, eu estava ‘do outro lado da barricada’ e trabalhava como aluno em outro projeto da Acronis. Mas desta vez, tornei-me consultor técnico para os alunos do lado da empresa e propus o projeto Active Restore. A própria ideia do Active Restore foi formulada pela equipe Kernel da Acronis, no entanto, o desenvolvimento da solução começou em conjunto com a Universidade de Innopolis.
Active Restore – para que isso serve?
Tradicionalmente, a recuperação de desastres segue um padrão. Após problemas com o computador, você acessa a interface web de um sistema de backup, como o Acronis True Image, e clica no grande botão ‘restaurar’. Em seguida, você precisa esperar N minutos, e só depois disso poderá retomar seu trabalho.
O problema é que esse número N, conhecido também como RTO (objetivo de tempo de recuperação), pode ser bastante expressivo, dependendo da velocidade da conexão (se a recuperação for a partir da nuvem), do espaço do disco rígido da sua máquina e de vários outros fatores. É possível reduzi-lo? Sim, é possível, pois para retomar a operação nem sempre é necessário ter o disco completo do computador. Fotos e vídeos, por exemplo, não afetam a funcionalidade do dispositivo e podem ser recuperados posteriormente em segundo plano.
Driver necessário…
O sistema operacional calcula a inicialização com um disco completamente pronto. Portanto, o Windows realiza uma série de verificações de integridade do disco. O sistema não permitirá o início normal na ausência ou dano de alguns arquivos que o SO espera encontrar. Para resolver esse problema, decidimos usar files de redirecionamento que substituem arquivos ausentes ou danificados, mas na verdade são apenas espaços vazios. Criar esses redirecionadores não leva muito tempo, pois, na prática, eles não contêm nenhum conteúdo.
A recuperação ocorre da seguinte forma. Um processo em segundo plano, em paralelo com o funcionamento do sistema operacional, preenche os “espaços vazios” com dados. O processo de recuperação em segundo plano considera a carga no disco e não excede o limite estabelecido. No entanto, o usuário ou o próprio sistema operacional pode de repente solicitar um arquivo que ainda não existe. Aqui entra em cena o segundo modo de recuperação. A prioridade do arquivo solicitado é elevada ao máximo, e o processo de recuperação carrega urgentemente o arquivo no disco. O sistema operacional recebe o arquivo necessário, embora com um pequeno atraso.
Essa é a imagem ideal. Contudo, no mundo real, existem uma enorme quantidade de armadilhas e bloqueios potenciais. Juntamente com os mestrandos de Innopolis, decidimos investigar esse cenário de recuperação, avaliar o ganho no RTO e entender se essa abordagem é viável. Afinal, soluções desse tipo simplesmente não estavam disponíveis no mercado na época.
E se a parte de serviço eu decidi deixar para a equipe de Innopolis, então dentro da Acronis começou o trabalho em . A equipe do Windows Kernel se encarregou disso. O plano era o seguinte:
- Iniciar o driver em um estágio inicial de inicialização do sistema operacional,
- Durante a operação, quando estiver completamente pronto, carregar o serviço.
- O serviço processa as solicitações do driver e coordena seu funcionamento posterior.
Particularidades da construção de drivers
Se meus colegas forem falar sobre o serviço em outro post, neste texto vamos explorar as particularidades do desenvolvimento do driver. O mini-driver já desenvolvido possui dois modos de operação – quando o sistema é iniciado em modo normal e quando o sistema acaba de sofrer uma falha e está passando por uma recuperação. Antes que a carga das bibliotecas e aplicativos do usuário, e portanto do nosso serviço, comece, o driver se comporta da mesma forma. Ele não sabe em qual estado o sistema está atualmente. Como resultado, cada create, read e write é registrado, e todos os metadados são registrados. E quando o serviço estiver online, o driver fornecerá essas informações ao serviço.
No caso de uma inicialização normal, o serviço envia um sinal para o driver dizendo “Relax” para que ele “descanse” e pare de registrar todos os dados meticulosamente. Nesse caso, o driver passa a registrar apenas as alterações no disco e as informa ao serviço, que com outras ferramentas da Acronis mantém o backup do disco no estado mais atual possível no meio que o usuário definiu. Isso pode ser um backup em nuvem, remoto, incremental ou noturno.
Se o modo de recuperação for ativado, o serviço informa ao driver que ele precisa operar no modo “Recovery”. O sistema acabou de ser recuperado após uma falha, e assim que ele solicita a abertura de um arquivo no disco, o mini-driver deve interceptar essa operação, fazer essa solicitação, verificar se o arquivo existe no disco e se pode ser aberto.
Se não houver um arquivo, o mini-filtro transmite essa informação para o serviço, que aumenta a prioridade de restauração do arquivo (durante todo esse tempo, a recuperação ocorre em segundo plano). Assim, esse arquivo simplesmente salta para o início da fila. Depois disso, o serviço restaura esse arquivo por conta própria (ou por outros meios da Acronis) e informa ao driver que está tudo certo, agora o sistema operacional pode acessá-lo e o driver "libera" a solicitação original, do sistema para o disco.
Se a restauração não for possível, o serviço informa ao driver que o arquivo não está no backup. Nosso mini-filtro simplesmente permite que a solicitação do sistema prossiga e a solicitação original (o próprio SO ou o aplicativo) recebe o erro "arquivo não encontrado". Contudo, isso é perfeitamente normal se o arquivo realmente não estava no disco nem no backup.
Claro, o sistema operacional funcionará muito mais devagar, pois a leitura de qualquer arquivo ou biblioteca ocorre em várias etapas, possivelmente com acesso a recursos remotos. Mas, pelo menos, o usuário pode começar a trabalhar em um curto espaço de tempo, enquanto a recuperação ainda está em andamento.
Precisa descer mais, ainda mais...
O protótipo provou sua funcionalidade. Mas também descobrimos a necessidade de avançar, porque em alguns casos, ainda ocorrem deadlocks. Por exemplo, o sistema operacional pode solicitar várias bibliotecas em múltiplas threads, o que leva o nosso serviço a ficar preso a si mesmo.
O problema em que estou trabalhando agora é aumentar a velocidade do Active Restore e melhorar a segurança do sistema. Suponha que o sistema não precise de um arquivo inteiro, apenas de uma parte dele. Para isso, foi desenvolvido um driver específico — um driver de filtro de disco. Ele opera não no nível de arquivo, mas no nível de bloco. O princípio de funcionamento é semelhante: no modo normal, o driver apenas registra os blocos alterados no disco, e no modo de recuperação, tenta ler o bloco por conta própria, e em caso de falha, solicita ao serviço para aumentar a prioridade. Todo o restante do sistema permanece inalterado. Por exemplo, o serviço do nível do SO nem suspeita que está sendo solicitado a se comunicar com outro driver, porque o principal objetivo é fornecer ao SO exatamente os dados necessários para o funcionamento. Essa abordagem requer aprimoramentos significativos, especialmente porque o serviço ainda não consegue operar no nível de bloco.
O próximo passo foi iniciar o driver mais profundamente e mais cedo, descendo ao nível dos drivers UEFI e aplicativos nativos do Windows em vez do serviço. Para isso, foi desenvolvido (ou driver DXE), que inicia e termina antes mesmo do início do SO. Mas a "história" dos drivers UEFI, detalhes sobre a construção e instalação, bem como a especificidade dos aplicativos nativos do Windows, serão abordados no próximo post. Então, assine nosso blog, e eu irei preparar um relato sobre a próxima fase do trabalho. Agradeço os seus comentários e sugestões.
Apenas usuários registrados podem participar da pesquisa. , por favor.
Já passou por situações em que a recuperação demorou uma eternidade:
65.1%Sim28
23.2%Não10
11.6%Não pensei nisso
43 usuários votaram. 3 usuários se abstiveram.
Fonte: habr.com
