Como gerar back-ups nesta situação?

[Fabio S Araujo]

Mas deixa eu ver se entendi uma coisa, o backup é feito para a própria maquina?

[edvan]

Mas deixa eu ver se entendi uma coisa, o backup é feito para a própria maquina?

Pelo que entendi não, não tem espaço para gerar o backup é transferir para outro server.

[RobertSP]

Isso é loucura, se você não tem estrutura pra um backup automatizado ao menos em outro VPS tu tá é jogando seu lucro desse cliente no trabalho imenso semanal e tempo gasto. Eu não tenho coragem de fazer backup manual nem de 5GB e olha que minha conexão é 50MB, quem dirá tudo isso.

[MyWay Hosting]

Salve, salve PDH!

 

Estou com um pequeno problema. Tenho um cliente com um VPS de 150 GB de espaço, sendo que o mesmo possui 110 GB de e-mails importantes que não podem ser removidos, sobrando 40 GB de espaço livre. Preciso gerar back-ups semanais desta conta, mas não há espaço em disco livre para gerar os back-ups, mesmo armazenando os back-ups remotamente.

 

 

 

Eu recomendo vc mudar seus termos de uso para que isso não mais aconteça.  110 GB de e-mails importantes é o fim da picada.

 

Até mesmo porque a conta pode ser hackeada ou pode haver problemas no servidor com a consequente perda de emails e arquivos. Tens que encontrar uma forma de fazer o cliente entender que emails tem que ser baixados e o servidor é local de armazenamento temporário e não permanente. 

 

Outra coisa, ele jamais conseguirá baixar 110GB de emails. Qualquer timeout e recomeça do zero. Então entendo que o cliente está com emais presos para o resto da vida no servidor. Nunca mais ele conseguirá baixar e o cenário somente irá piorar.

[Rocha Neto]

Ele tem apenas 40 GB de espaço em disco, e utiliza 110GB.

 

Neste caso, é óbvio que o cliente é diretamente responsável por tomar a decisão final.

 

Veja, se ele tivesse 80GB de HD, e 40GB livre, na hora do backup, o sistema ia lotar o HD e os serviços iriam parar. A culpa é dele.

 

Se ele quer fazer backup, e o HD não tem espaço pra comportar a geração do backup, a culpa também é dele.

 

Você está sendo cortês, mas tem que ser sensato.

 

Se não tem jeito, eu aumentaria o HD dele. Mas isso nunca vai resolver. Ele sempre vai precisar de mais espaço pra fazer o backup.

[edvan]

Ele tem apenas 40 GB de espaço em disco, e utiliza 110GB.

 

Neste caso, é óbvio que o cliente é diretamente responsável por tomar a decisão final.

 

Veja, se ele tivesse 80GB de HD, e 40GB livre, na hora do backup, o sistema ia lotar o HD e os serviços iriam parar. A culpa é dele.

 

Se ele quer fazer backup, e o HD não tem espaço pra comportar a geração do backup, a culpa também é dele.

 

Você está sendo cortês, mas tem que ser sensato.

 

Se não tem jeito, eu aumentaria o HD dele. Mas isso nunca vai resolver. Ele sempre vai precisar de mais espaço pra fazer o backup.

 

Segundo o que o Jefferson disse o backup é cortesia e a responsabilidade é do cliente.

[Jefferson]

Segundo o que o Jefferson disse o backup é cortesia e a responsabilidade é do cliente.

 

Exato. Está descrito em nossos Termos de Uso que a responsabilidade é do cliente, mas sempre geramos os back-ups como forma de cortesia. Se um dia ocorrer algum problema por falha do cliente ou por falha de nossa equipe, teremos um back-up.

 

- O espaço de 110 GB de e-mails, são de anexos. É uma empresa de webdesign que recebe e enviar diversos projetos, arquivos em formato .PSD e isso consome muito espaço. A quantidade de e-mails é baixa, vamos assim dizer.

 

- Sobre o back-up, atualmente estou baixando através de um VPS Windows que tenho para testes, depois compacto e envio por FTP para o servidor remoto de back-ups. O processo é rápido, baixando diretamente a pasta MAIL e não utiliza a rede local da empresa.

 

 

Terei que terminar o projeto do plugin R3 para efetuar o back-up remoto direto deste cliente. Agradeço a todos pela participação no tópico!

[joaopaulo]

Simples assim:

 

1. Contrate um VPS Storage por aí de 250GB. Vai custar no máximo $15. Sugestão: Vultr.com
2. Instale apenas o SO limpo. Nada de Windows, cPanel, DiaboA4, etc...
3. Use o Rsync com cronjob, para sincronização diária e no FDS (via cron e shell script) faça uma cópia para outra pasta sem compactação, afinal, comprimir anexos só gasta CPU e nem tem uma redução tão significativa que valha a pena nesse teu caso.
4. Vai ser feliz.

[MyWay Hosting]

- O espaço de 110 GB de e-mails, são de anexos. É uma empresa de webdesign que recebe e enviar diversos projetos, arquivos em formato .PSD e isso consome muito espaço. A quantidade de e-mails é baixa, vamos assim dizer.

 

 

Menos mal, desta forma então talvez ele possa baixar os emails. Se fossem arquivos pequenos como é o de costume nunca mais ele conseguiria baixar. Alem disso por serem anexos grandes então não tens problemas de consumo de RAM já que cada arquivo precisa de 1 inode e isso consome RAM devido ao cache.

 

Contas de emails são mais problemáticas que os próprios sites de clientes, por isso é bom ter um termo de uso rígido na utilização de emails. Normalmente sites não crescem com a mesma velocidade de contas de emails.

[Visitante]

Exato. Está descrito em nossos Termos de Uso que a responsabilidade é do cliente, mas sempre geramos os back-ups como forma de cortesia. Se um dia ocorrer algum problema por falha do cliente ou por falha de nossa equipe, teremos um back-up.

 

- O espaço de 110 GB de e-mails, são de anexos. É uma empresa de webdesign que recebe e enviar diversos projetos, arquivos em formato .PSD e isso consome muito espaço. A quantidade de e-mails é baixa, vamos assim dizer.

 

- Sobre o back-up, atualmente estou baixando através de um VPS Windows que tenho para testes, depois compacto e envio por FTP para o servidor remoto de back-ups. O processo é rápido, baixando diretamente a pasta MAIL e não utiliza a rede local da empresa.

 

 

Terei que terminar o projeto do plugin R3 para efetuar o back-up remoto direto deste cliente. Agradeço a todos pela participação no tópico!

 

Conforme o João falou, tu pode utilizar o RSYNC:

 

#rsync -abvz --backup-dir=DIRETORIO-REMOTO -e '/usr/bin/ssh -F PORTA-SSH' /home/CONTA-CLIENTE/mail/* "USUARIO-SSH"@"IP-SSH":"DIRETORIO-REMOTO";

 

Lembre-se de colocar a chave no /root/.ssh/authorized_keys do servidor de destino!

 

Acho que o código está certo.. fui fazendo como me lembro. A primeira vez vai demorar mais devido a indexação dos dados.