NOTÍCIA: Banco de dados do Migre.me é perdido e o serviço para

**Redação Adrenaline** · 02-09-10 17:42

Após um procedimento de atualização de servidor, que aconteceu na madrugada de quarta-feira, o principal serviço brasileiro de encurtamento de endereços de internet, o Migre.me, teve toda a base de dados perdida, e desde então não foi reativo. O criador do site, o analistas de sistemas Jonny Ken, postou um vídeo onde conta o que ocorreu durante a atualização. A principal falha, segundo Ken, é que o backup de todos os 10 milhões de usuários cadastrados no site estava no mesmo disco onde estava hospedado o sistema. Com a atualização, ambas as bases, original e a cópia, foram perdidas.

O criador do Migre.me não divulgou em qual servidor é hospedado o serviço, e também dividiu a culpa. "Eu peço desculpas, porque eu não sabia disso [backup no mesmo computador da base], eu devia me informar quanto a isso. Eu sempre trabalhei com análise de sistemas, e eu sempre trabalhei com backups", desabafou Ken. "Eu sei que a credibilidade do serviço, que tem que estar disponível 24h por dia, sei que está agora bastante abalada". Por hora, não se sabe se o serviço irá voltar a funcionar, nem se será possível recuperar os dados.

[ Ver texto completo ]

**Dicroh** · 02-09-10 17:48

Backup no mesmo servidor .. OMFG
Muito "ixperto" esses caras ... Meu DEUS!

**goblin** · 02-09-10 17:50

Almir backups

**Pennant** · 02-09-10 17:58

Se é backup é óbvio que não era pra estar no mesmo disco dos dados originais, manja muito esseae.

**tjorssato** · 02-09-10 17:59

Postado originalmente por Dicroh

Backup no mesmo servidor .. OMFG
Muito "ixperto" esses caras ... Meu DEUS!

pensei exatamente nisso...

sem palavras....

**iCOM** · 02-09-10 18:54

Jonny Ken,

Em primeiro lugar quero te parabenizar pela coragem de vir a público
e explicar em video o problema ocorrido com seu serviço de Internet.
Como não fui usuário do referido serviço não posso aqui compor com testemunho, mas pelo
número de registros mencionados, deve ter sido de grande utilidade pública.

Caso necessite de auxílio para o futuro armazenamento correto dos registros ente em contato e mecione
este post.

Never give up!

Abraço
Adriano Villeroy

**lordstranho** · 02-09-10 19:57

Que burro, da zero pra ele!!!
Backup no mesmo HD, bleza fail do host, mas ele tinha de ter um backup pessoal e não um remoto no host, hauhsuhs isso que da contratar serviço da china

**mash** · 02-09-10 20:07

Virtualiza....Snapshot....deu *****....volta o snap....

Difícil?

Mas notaram que nem ele sabia como era o sistema de backup do serviço. Faltou um pouco de "malícia" e transparência por parte do fornecedor do datacenter.

**mash** · 02-09-10 20:16

Escutando o cara falando.

Até imagino aonde estava estes dados.

E segundo as explicações é algo "usual" armazenar backups no mesmo storage.
Notem que ele não falou no MESMO DISCO e sim no MESMO STORAGE.

Então o que geralmente é feito. Cria-se volumes em um storage, geralmente estes storages são completamente redundantes (cache, discos, fonte, controladora, coolers, interface de rede) etc...

E em paralelo é feito backups incrementais definidos em política seja em fitas de backup ou até mesmo replicação de storage no mesmo espaço fisíco (datacenter) ou locais remotos.

Ou seja, em uma falha, vc ainda tem o backup incremental em fita.

Mas para voltar backup incremental, em grandes volumes de dados, é feito um único backup FULL no começo do ano e o resto do ano são feitos incrementais. Se vc precisa voltar backup do mês de janeiro e está no dia 30 de dezembro, precisa ir voltando fita por fita =D

Enfim, o datacenter vacilou por não ter o backup em fita.
Sabe o que é isso? Ter a certeza que o backup do storage tá 100% =D

E outra, ele comentou que solicitou upgrade, indica que ele fez colocation e não locou o serviço web (SaaS).

Isso é a impressão que eu tive =D

**twisterbr** · 02-09-10 21:19

putz, é o minimo mesmo qdo se mexe com servidor, fazer backup em outro computador, e melhor ainda se for em local diferente..

um professor meu contou uma história sobre o world trade center onde guardavam todo o backup de uma torre na outra... imagina a dinheirama que não perderam

**adrcmendes** · 02-09-10 21:44

faltou experiência..

**AMD X3** · 02-09-10 21:46

Que bixo espertão em...

**Keed Jamaica** · 02-09-10 23:18

até eu que nao tenho experiência com servidor sei que backup deve ficar em uma mídia separada (por mídia eu me refiro a fita, hd, disco, papel, qualquer coisa longe do mesmo hd) deram molinho mesmo, srsrs

**TonyMad[F4Fx]** · 02-09-10 23:53

Po, la na empresa eu ja vi dar ***** mesmo o backup estando em maquina separada. Tipo, foi fail pq o responsavel pelo cpd não presta atenção e acha q ta tudo perfeito. Tipo assim. Toda madrugada o servidor faz backup de tudo que foi feito naquele dia, tipo os pontos de backup do windows. Só q certo dia os dados originais deram pau, e o sistema de backup rodou mesmo assim, por consequencia mandou um monte de dado fudido pro backup. Foi uma ***** federal. Pelo menos conseguiram recuperar quase tudo. A ***** é q o pessoal teve q pegar todo o log do q tinham feito, papeis impressos e o caramba, e refazer todo o trabalho q tinham feito no dia do bug. E a grande ***** é q tinham q fazer na ordem, pq por ex, tinha nota fiscal, então os numeros novos tem q ser iguais aos antigos pra nao dar ***** na receita federal. Foi uma semana de cu até resolver tudo e botar tudo em dia...
A grande ***** é confiar q o sistema ta sempre funcionando.

**Chico** · 03-09-10 01:20

Postado originalmente por mash

Escutando o cara falando.

Até imagino aonde estava estes dados.

E segundo as explicações é algo "usual" armazenar backups no mesmo storage.
Notem que ele não falou no MESMO DISCO e sim no MESMO STORAGE.

Então o que geralmente é feito. Cria-se volumes em um storage, geralmente estes storages são completamente redundantes (cache, discos, fonte, controladora, coolers, interface de rede) etc...

E em paralelo é feito backups incrementais definidos em política seja em fitas de backup ou até mesmo replicação de storage no mesmo espaço fisíco (datacenter) ou locais remotos.

Ou seja, em uma falha, vc ainda tem o backup incremental em fita.

Mas para voltar backup incremental, em grandes volumes de dados, é feito um único backup FULL no começo do ano e o resto do ano são feitos incrementais. Se vc precisa voltar backup do mês de janeiro e está no dia 30 de dezembro, precisa ir voltando fita por fita =D

Enfim, o datacenter vacilou por não ter o backup em fita.
Sabe o que é isso? Ter a certeza que o backup do storage tá 100% =D

E outra, ele comentou que solicitou upgrade, indica que ele fez colocation e não locou o serviço web (SaaS).

Isso é a impressão que eu tive =D

Entendi foi é NADA do que cê falou.

**Atoledo** · 03-09-10 01:36

**gamerx** · 03-09-10 01:55

mais fizeram burrada hein...vai dar um bom trampo agoraaa

haja café ..kpkapkapakpak

**Chico** · 03-09-10 01:58

Processa logo. (o data center)

**mestrepanda** · 03-09-10 04:08

mais que servidor é esse!!!
como outro user citou... geralmente esses servidores tem backup em fita... esse cara deve ter hospedado na XingLing hosts!!!

**gonzayeah** · 03-09-10 07:17

Sem problemas, é so passar o recuva...

**GuillerZ** · 03-09-10 08:33

isso tudo é jogada de marketing.... daqui a pouco ele lança o fenix.me

**kikz** · 03-09-10 09:01

undeletePRO FTW...

Cara, inocência do manolo japa :S

Notem que nem nerd ele é, bah...

**bigaluksys** · 03-09-10 09:53

Postado originalmente por kikz

undeletePRO FTW...

Cara, inocência do manolo japa :S

Notem que nem nerd ele é, bah...

pois é manolo
tem q ser nerd, senão dá no q deu

**Vhann** · 03-09-10 16:51

Cara já passei por algo parecido mas o banco era MYSQL, eu usava uma LTO3 da IBM e os "analistas" do dia não verificaram se o script de cópia automática tinha sido concluído com sucesso, putz a sorte foi que eu fiz um backup físico do arquivo do banco de madrugada. E olha que isso fez a gente ficar sem o serviço rodando o dia todo quase.

Tem hora que o ideal mesmo é o backup ficar em um Data-Center em outra localidade...