Se você está enviando seu código para qualquer serviço externo, você deve certificar-se de que ele está criptografado com segurança antes de ser enviado, ou que você tenha totalmente verificado o serviço externo, de preferência os dois. Executar seus próprios servidores de backup será mais seguro (você tem mais controle direto), mas mais complexo (você precisa fazer tudo sozinho). Como seus servidores de backup provavelmente estarão rodando em espaços de cores que você não tem controle físico, você pode querer configurar os dados em sistemas de arquivos criptografados que não são montados automaticamente na inicialização (eles requerem manual intervenção, para enviar a (s) chave (s), se os servidores precisarem ser reiniciados - ter as chaves no servidor para poder montar automaticamente os volumes criptografados é como ter um cofre caro com a combinação escrita em uma nota de post-it próxima por.
De qualquer forma, você deve ter backups off-line e on-line, ou seja, discos / fitas fora do local e não conectados. Dessa forma, se você estiver completamente hackeado e todos os seus servidores principais, backups locais e backups online hospedados forem destruídos, você ainda deverá ter os backups offline para reverter.
Uma maneira de reduzir o problema de um hacker invadir seus servidores principais e usá-los para invadir seus servidores de backup (o que aconteceu com um serviço da Web de alto perfil há alguns meses), sugiro ter um serviço intermediário que tanto servidores ao vivo e de backup se conectam. Dessa forma, você não pode solicitar que os servidores ao vivo ou de backup tenham acesso uns aos outros, e o servidor intermediário não precisa efetuar login ao vivo ou backup. Os sites ativos entrariam no servidor intermediário para enviar os dados mais recentes e algum tempo depois que os servidores de backup fizessem login para puxá-los para si mesmos. Isso também não remove a recomendação de ter backups off-line off-line, embora reduza sua chance de precisar usá-los com raiva.
Uma opção extra para hospedar seus backups externos: se você tiver bons termos muito com outra empresa local não concorrente, talvez você possa hospedar os backups uns dos outros. Você ainda pode criptografar seus backups para verdadeira paranoia (não no caso de os outros negócios serem ruins, embora isso possa acontecer, mas para cobrir a possibilidade de serem hackeados ou assaltados).
E um ponto extra que muitas vezes é negligenciado: verifique se você tem um procedimento para testar os backups . Você não quer descobrir que eles pararam de trabalhar por algum motivo semanas atrás no dia em que você precisa restaurar algo deles. Há um número de maneiras de testar seus backups, o melhor a ser feito depende da natureza e do tamanho dos dados que você está armazenando e do formato em que eles estão armazenados. Por exemplo, eu tenho uma cópia do meu servidor de e-mail em execução. VM que pensa é o servidor live, mas não é visto do mundo exterior. Três vezes por semana, um script o interrompe, restaura o backup mais recente e o reinicia, sendo enviados erros para mim. Então, como parte da minha manutenção regular, faço login nesta VM de backup para verificar se tudo está OK (ele está em execução, mudanças recentes estão presentes, uma amostra aleatória de dados antigos parece OK também, ...). Você ainda deve ocasionalmente testar manualmente os backups, mas os testes automatizados às vezes são uma dádiva de Deus - eles podem sinalizar um problema menor antes de se tornar um grande problema.
É difícil ser demasiado paranóico quando se cuida do seu código-fonte. É o seu ativo principal, o seu negócio pode não valer nada sem ele, então você precisa protegê-lo de forças maliciosas externas (incluindo forças naturais!) Com muito cuidado.