Estou mudando de VPS para servidor dedicado. Infelizmente, a maioria dos servidores dedicados não fornece backups de servidor como os VPS gerenciados e eu realmente gosto da tranquilidade de ter um backup de todos os meus scripts/arquivos se algo der errado (já aconteceu antes).
Então, a questão é: é possível criar diariamente "Snapshots" de determinados diretórios que são salvos no mesmo servidor, mas em pastas diferentes.
Compreensivelmente, esses backups não protegerão contra desastres externos. Estou mais procurando proteção contra qualquer dano causado por scripts maliciosos/hacking, etc.
Responder1
Você provavelmente está procurando algo como Webmin:http://webmin.com/
É uma parte obrigatória das configurações do meu servidor CentOS. É realmente fácil de instalar e facilita muito a administração do servidor, especialmente fazendo backup de coisas. Dê uma olhada na documentação aqui:http://doxfer.webmin.com/Webmin/FilesystemBackup
Responder2
é possível criar diariamente "instantâneos" de determinados diretórios que são salvos no mesmo servidor, mas em pastas diferentes. ... para proteção contra danos causados por scripts/hacking maliciosos, etc.
Sim, qualquer um dosmuitas ferramentas de software de controle de revisãoisso fará exatamente isso.
Eu uso o Mercurial ("hg"), geralmente com o lindo frontend do TortoiseHg.
Em muitos dos meus servidores, existe uma pasta(*), talvez "/var/www/", que contém tudo o que desejo fazer backup - arquivos de configurações, modelos, scripts cgi-bin personalizados do lado do servidor, navegador personalizado- scripts .js secundários, conteúdo .html, etc. (Todo o resto na máquina é um sistema operacional padrão e material de aplicativo. Se esse material for danificado, eu provavelmente o limparia e instalaria a versão mais recente, em vez de tentar reverter para a versão antiga e obsoleta que eu estava usando).
Quando configuro as coisas pela primeira vez, faço cd para essa pasta e faço a configuração única
hg init
hg add
hg commit -u dc -m "initial setup"
A linha “init” cria uma pasta “.hg/” que, algum dia, armazenará instantâneos compactados. (daí o nome de um tutorial popular do Mercurial,http://hginit.com/). A linha "add" e a linha "commit", por padrão, verificam todos os arquivos daquela pasta, não importa quão profundamente aninhados nas sub-subpastas, e colocam uma cópia (compactada) nessa pasta ".hg/" .
Quando suspeito de danos ou outras alterações nos arquivos de trabalho (e assumindo que a pasta ".hg", que contém todos os instantâneos, não está danificada), digito
hg status
que me diz exatamente quais arquivos foram alterados, não importa o quão profundamente aninhados em alguma subsubpasta, então eu digito
hg diff
o que me diz exatamente o que mudou em cada arquivo.
Se não gosto do que vejo - são modificações maliciosas ou, mais comumente, são minhas próprias edições tolas que agora me arrependo de ter feito, digito
hg revert --all
para reverter todas as alterações para o commit mais recente.
Se eufazergosto do que vejo - ajustei algo que realmente o torna melhor - digito algo como
hg add
hg commit -u dc -m "tweaked .htaccess so we now have Clean URLs."
com um comentário que descreva por que fiz essas alterações. (Existem maneiras de reverter apenasalgunsdos arquivos, e comprometer apenasalgunsdos arquivos, e até mesmo maneiras de submeter apenasalgunsdas muitas alterações feitas em um único arquivo - consulte a documentação para obter detalhes).
Talvez você prefira ter um cron job que faça diariamente algo como
hg add
hg commit -u mr_backup -m "cron automated snapshot of the server."
Um instantâneo compactado de cada versão que já foi confirmada permanece na pasta ".hg/". Existe um comando "hg update" para reverter para qualquer versão confirmada. Existe um comando "hg diff -r 1:2" para ver exatamente o que mudou entre o primeiro commit e o segundo commit.
situações mais complexas
(*) Freqüentemente, há apenas uma pasta da qual desejo fazer backup ( "/var/www/" ). No entanto, às vezes tenho uma situação mais complexa - os arquivos dos quais desejo fazer backup estão espalhados em várias pastas diferentes, e a única pasta comum entre eles é a pasta raiz "/", e não quero colocar o repositório ".hg/" na pasta raiz "/.hg/" .
Provavelmente existe uma maneira melhor de lidar com isso, mas o que estou fazendo agora é:
- Eu crio um usuário especial chamado "MrBackup" que possui permissões somente leitura para todos os arquivos dos quais desejo fazer backup.
- Eu configurei as coisas para que cada pasta da qual desejo fazer backup apareça como uma subpasta de/home/mr_backup. Atualmente tenho uma mistura aleatória de:
- Na verdade, alguns arquivos estão na pasta pessoal do MrBackup e, em seguida, o outro local onde eles "precisam" estar possui um link virtual para eles.
- Alguns arquivos têm um link físico para eles em ambos os lugares - o local onde "precisam" estar e também em algum lugar na pasta pessoal do MrBackup.
- Um script cron copia periodicamente alguns arquivos do local "ao vivo" para uma pasta de backup na pasta pessoal do MrBackup, talvez despeje um banco de dados SQL de outro servidor em um arquivo de despejo na pasta pessoal do MrBackup e também faz um backup do próprio script cron ( "crontab -l > /home/mr_backup/backup/crontab.txt" ).
- Muitas vezes quero fazer backup de quase tudo em alguma pasta P, exceto uma subpasta "cache/" da qual não preciso fazer backup, pois será regenerada automaticamente se necessário. Eu uso ".hgignore" para excluir a subpasta de cache.
- Então eu uso o Mercurial, como acima.
- Quando os arquivos gerados pelo script cron não parecem corretos, depois de fazer uma reversão, preciso executar algumas etapas extras para, de alguma forma, enviar a "versão boa" de volta ao local "ativo".
ps: Em uma máquina em uma cidade diferente do meu servidor, ocasionalmente eu abro o ambiente de trabalho TortoiseHg e clico no pequeno botão que, nos bastidores, executa
hg pull
(e me pede a senha do Sr. Backup) para obter um backup externo de tudo o que foi enviado ao repositório.
Em vez de fazer edições no servidor de produção, geralmente é melhor fazer as edições em alguma outra máquina, depois enviá-las e
hg push
para o servidor de produção.
A pasta ".hg/" continua crescendo - muito lentamente, porque só salva arquivos quemudarde um commit para o próximo, e mesmo esses conjuntos de alterações relativamente pequenos são compactados antes de serem armazenados.
Provavelmente existe uma maneira melhor de lidar com esse crescimento lento, mas o que faço atualmente é:
Depois de "hg commit" a versão atual e, em seguida, "hg pull" em minha máquina de backup externa, uma vez por ano eu excluo a pasta ".hg/" do servidor e uso "hg init" para criar uma pasta nova, nova e vazia. pasta ".hg/" e, em seguida, confirmo a versão atual. (A última versão do repositório de backup externo de 2014deveser idêntico à primeira versão do repositório de backup externo de 2015).