Eu administro vários sites de comércio eletrônico em meu servidor doméstico (meu, de um membro da família e de um cliente). É um Dell Dimension 4600 mais antigo que estou executando o Ubuntu 12.04 lts. O computador não mostra sinais de falha iminente, mas por ser antigo, quero ter um bom backup dele caso algo aconteça. Eu precisaria ser capaz de restaurar os dados para um novo servidor alguns dias após o servidor cair. A melhor maneira de usar algo como o Clonezilla? Ou deveria. Existe um método melhor para fazer isso?
Atualizar
Não preciso que o site esteja ativo enquanto faço isso e atualmente tenho cerca de 8 Gb de dados. Uma pequena cópia parece uma boa ideia para o que eu quero, que é fazer o backup e, se acontecer alguma coisa, poder conectar o disco de backup e pronto. O layout do disco é apenas um disco, uma grande partição de 80 GB. Sim, eu sei que isso não é o melhor, eu era novo em todo o mundo do Linux, Ubuntu, servidores Web, praticamente tudo quando instalei o sistema operacional e configurei-o inicialmente. Então também não há LVM
Responder1
Se o site não precisar estar ativo enquanto você faz isso, há uma série de soluções, sendo a mais fácil garantir que o disco seja montado somente leitura (por exemplo, usando um disco de inicialização) e fazer uma cópia em bits de 1 disco para outro. Então, se algo der errado, basta inserir o disco de backup, ligar o servidor e pronto.
Se o site precisar estar no ar durante a cópia, o problema é mais complexo. Uma boa maneira de lidar com backups no Linux é agendar backups incrementais usando algo como rsnapshot (mas o rsync pode ser mais fácil no seu caso). Se você precisar restaurar, precisará começar reconstruindo o servidor e, em seguida, copiando o instantâneo mais recente.
Você não indicou a quantidade de dados dos quais está fazendo backup, com que frequência eles mudam ou o layout dos discos. Ambas as coisas são úteis para criar uma solução de backup. Se você estiver construindo um novo sistema (ou teve a visão quando construiu o sistema original), geralmente é útil construir o sistema de arquivos no LVM e, em seguida, tirar um instantâneo do LVM e fazer backup dele. Isso significa que não há tempo de inatividade e você pode fazer uma cópia exata [da maior parte] do sistema de arquivos em um determinado momento. É claro que isso pressupõe que você use o LVM.
Da mesma forma, se você tiver uma boa separação entre o sistema operacional e o aplicativo, talvez queira começar com uma instalação básica do Ubuntu 12.04 e, em seguida, fazer backup apenas dos aplicativos de forma incremental. Você também pode querer manipular os bancos de dados de maneira diferente dos arquivos da web, descartando os bancos de dados. Da mesma forma, o tar (às vezes em dispositivos de bloco) pode ser bom para backups completos e compactados - mas ao fazer backup de dispositivos de bloco, esteja ciente de que as alterações de arquivo durante o backup do dispositivo de bloco podem voltar a funcionar com bastante força sem cuidado.
Infelizmente, é difícil ser mais específico do que isso porque os backups são um tanto específicos do sistema.
Responder2
Para uma situação como esta, a melhor maneira é provavelmente ter outro servidor onde você possa sincronizar seus dados. Compre um VPS e sincronize seu código, bancos de dados e configurações. Acabei de verificar um provedor que uso e você pode obter um VPS com 20 GB de espaço, 512 MB de RAM, transferência de 1,5 TB e 2 IPs por US$ 20 por ano. Dobre as especificações e custa US $ 40 por ano. Amendoim. Se você não gosta de pechinchas, você poderia usar Amazon Cloud ou Slicehost, mas acho que você está desperdiçando seu dinheiro.
Ao fazer alterações no código, use o Dreamweaver (ou qualquer outro que você use) para fazer alterações no seu site de "teste". Em seguida, promova seus dados para o site de “produção”. A maioria dos IDEs de desenvolvimento web tem a capacidade de ter um servidor de “teste” e um servidor de “produção”. Você escolhe qual é qual. Se fosse eu (e tenho quase a mesma situação com alguns clientes), definiria o VPS como site de produção e usaria o servidor doméstico como site de backup.
A configuração inicial disso é fácil. Você pode despejar todos os seus pacotes instalados do apt-get em um arquivo txt e usá-lo para instalar os mesmos pacotes no seu VPS. Tarar os arquivos da web, o banco de dados é despejado e você pode usar o SCP para copiá-los diretamente para o outro servidor. (Provavelmente faça tudo isso com um script de shell curto.) Você provavelmente desejará copiar a maior parte do seu /etc também. Depois que a configuração inicial for concluída, manter as coisas sincronizadas é trivial.
Isto tem muitas vantagens.
- Primeiro, falta energia em sua casa e seu servidor não cai.
- Em segundo lugar, as alterações de código são testadas e desenvolvidas em sua LAN para que sejam rápidas e você não precise esperar para enviar dados por meio de uma conexão lenta (YMMV).
- Você tem uma falha de hardware e precisa de uma peça que leva uma semana para ser obtida – seu local de produção permanece ativo.
- Você pode fazer login via SSH em seu servidor de teste de qualquer lugar, fazer alterações, testá-las e, em seguida, enviá-las para seu servidor de produção com interrupções mínimas.
- Você pode desenvolver exatamente a mesma configuração da máquina de produção. Assim você não precisa usar o XAMPP ou algum outro ambiente de desenvolvimento e se preocupar com dependências, estrutura ou todas as outras nuances de desenvolvimento.
- Colocação. Se sua máquina de produção falhar (VPS) por algum motivo, reencaminhe seu DNS para o servidor doméstico. Mantenha seu DNS TTL em 30 minutos e seu tempo de inatividade será mínimo.
Então, essa é a minha recomendação.
E, sim, eu cobro das pessoas mais de US$ 1.000 por ano por um VPS que me custa cerca de US$ 40 por ano... Eu também vendo serviços de co-localização, que é apenas mais um VPS de outro provedor ou no meu rack doméstico. Você tem que se apoiar em gigantes se quiser ganhar dinheiro no jogo da web. Desenvolver código é bom, mas a renda residual é onde está, irmão. Compre baixo. Venda caro.