Portada
Hace 7 años | Por ccguy a theregister.co.uk
Publicado hace 7 años por ccguy a theregister.co.uk
Gitlab.com fundido por borrar un directorio incorrecto, los backups fallan [ENG]

Gitlab.com fundido por borrar un directorio incorrecto, los backups fallan [ENG]

 theregister.co.uk

Gitlab.com, una empresa de gestión de código fuente, ha perdido datos de producción. Un administrador cansado ejecutó un rm -rf sobre un directorio incorrecto que contenía 300 GB. Cuando se dio cuenta sólo quedaban 4.5 GB de datos. Los sistemas de backups que tienen no estaban probados y no han servido para nada. Se están recuperando los datos de un snapshot con algunas horas de antigüedad que además no es completo. La pérdida afecta a la base de datos (incidencias y merge requests) pero no a los repositorios.

Etiquetas

DE3C548D-E347-406A-A60F-E6BBD322CAB7 6.2k 264

Comentarios

Unregistered

rm -rf *

¿Qué podría salir mal?

V 77
K 532
Robus

#1 Da para camiseta!

V 9
K 75
D

#7 eso parece: http://bfy.tw/9ozc

V 1
K 7
Cantro

#18

lol

V 7
K 69
D
editado

#24 http://bit.ly/2kqnHnt

V 1
K 12
TocTocToc
editado

#1 ¡Eso le pasa por no usar la papelera de reciclaje!

comment_21153179 media
V 8
K 74
Unregistered
editado

#28 Calla calla, que muchas veces hago Mayus + Supr para "Eliminar definitivamente" (sí, soy de Güindous) y más de una vez me colé, una vez borré la carpeta de películas completita

V 10
K 97
P

#38 Yo lo hice una vez con "Archivos de programa", quería entrar dentro para borrar uno a mano pero se me fue la pinza y le di antes de entrar. Por suerte entre que calculaba y empezaba me di cuenta y no hubo grandes daños lol

V 2
K 28
TocTocToc

#38 Eso te pasa porque no habrás vivido épocas pasadas. La papelera de reciclaje fue una bendición que igual no valoráis bien.

V 2
K 20
Unregistered

#52 Empecé con MS-DOS, como sabes las capacidades de los discos duros siempre era muy limitada (de aquella), creo que la 'Papelera de reciclaje' apareció con W95 y juraría que de aquella tenía un disco duro de unos 800 Mb, vamos que con 3 o 4 CDs ripeados en MP3 ya tenía petao el disco duro, y la manía ya me quedó desde aquella lol

V 1
K 28
TocTocToc
editado

#75 ¿Empezaste ya con discos duros? Qué suerte, yo empecé con una sola disquetera de 5 1/4. Bueno, en realidad antes con una cinta de casete...

Aún no había salido ni el MS-UNO .

V 3
K 29
Unregistered
editado

#88 Bueno, el CPC no lo cuento porque era de mi primo, pero sufrí las interminables cargas con su error después de 35 minutos esperando y esas cosas jajja lol , el primer PC creo que lo tuve a finales del 93, 486 DX con ¿4 Mb? de RAM, no recuerdo exactamente. #MomentoViejuno

V 1
K 26
Abeel

#75 los CDs con lectura Mp3 no fueron lanzados al mercado hasta el 2002 y con un precio bastante alto, por lo que es muy improbable que en tu Windows 95 de 7 años y 800mb te pusieras a ripear Mp3

V 3
K 32
atatat

#75 yo empece con unas pinturas en una caverna

V 1
K 9
s

#38 https://www.piriform.com/recuva

V 1
K 15
M

#82 Con ese programa si lo acabas de borrar tienes un 99.9% de probabilidades de poder recuperarlo todo.

V 0
K 9
g

#38 c: -> boton derecho -> propiedades -> versiones anteriores -> boton derecho encima de la que te cuadre -> abrir en nueva ventana.

De nada.

V 1
K 9
angelitoMagno

#28 Fuera de coñas, cuando estudié sistemas operativos una de las prácticas que tuvimos hacer fue crear un sustituto para rm que en vez de borrar enviara a una unidad que funcionase como "papelera de reciclaje"

Es para pensarlo. Que en entornos críticos un rm no borre, sino que mueva a una unidad externa a modo "papelera".

V 2
K 19
I

#95 Seguramente sólo serviria para que el admin de sistemas de turno crease un script que borrase y vaciase la papelera de una sola vez ...

V 7
K 41
P
editado

#28 ¿De qué serviría? Si lo que necesitaba era eliminar una carpeta para liberar espacio, pasarlo a la papelera no resolvía el problema. Además, suele pasar que no te das cuenta del error hasta mucho después de borrar y vaciar la papelera.

V 0
K 9
n

#1 A cualquiera se le olvida el punto en un sudo rm -rf ./

V 4
K 47
D

#1 Fuera coñas a mi me pasó una vez cuando se me coló un espacio donde no debía (por las prisas escribiendo):

rm -rf / home/user/folder

el espacio entre la / y el home hace que primero borre todo y luego intente borrar el subdirectorio home/user/folder...

V 51
K 313
D

#48 Wow... qué putadón.

V 3
K 23
pitercio
editado

#c-48" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/2729433/order/48">#48 Mal de muchos... conozco a uno que hizo algo parecido, desde la / ejecutó # rm -Rf . /ruta/completa/copiada/y/pegada/para/no/equivocarse

V 0
K 16
I
editado

#48 A mi se me colo un espacio borrando unos directorios en vez de rm -fr nombDir* hice rm -fr nombDir *. No veas la gracia. En todo caso a los que nos dedicamos a trastear con sistemas es algo que en mayor o menor medida nos ha pasado alguna vez.

V 1
K 14
M

#48 Por eso aunque sea aburrido como confirmar los password 2 veces, es interesante el parametro -I quedando como rm -rfI .

V 3
K 36
sillycon

#48 Me apunto a este carro... Y no una sola vez...

V 0
K 6
PauMarí

#48 hace muuuucho tiempo que cogí la manía de hacer ls /home/user/folder, cursor arriba, inicio suprimir suprimir rm -rf

V 5
K 26
D
editado

#48 O usas una distribución antigua de narices o una chapucera que modifica las opciones por defecto de forma estúpida, el rm de Linux (y el de BSD) hace años que lleva activado el preserve-root por defecto, si intentas borrar la raíz te sale un aviso de que no lo puedes hacer si no le pasas el flag contrario explícitamente.

Ejemplo acabado de ejecutar en esta máquina como root:
rm -rf /
rm: it is dangerous to operate recursively on '/'
rm: use --no-preserve-root to override this failsafe

Vamos, que lo de le di a rm -rf / sin querer es un mito desde hace mucho tiempo.

V 12
K 75
DrLove

#48 yo hice un

rm -rf ~ *

el espacio entre * y ~ no debía estar, era para borrar backups creados por el editor (no recuerdo si era emacs), me borró un proyecto de la universidad a 5 minutos de cerrar el servidor de entregas

V 0
K 9
D

#48 Sí, yo también le dí una vez al botón derecho -> elimimar -> si. Luego entre en la papelerá y repetí: boton derecho->eliminar->sí, seguro.
Todo eso sin darme cuenta.

(no, en realidad un formateo a propósito por estar haciendo el tonto;luego descubrí que quizás podría haber recuperado todo, o casi todo, pero no lo sabía... )

V 0
K 8
Neochange

#1 Diselo al que lo ejecutó que debe estar en su casa

V 1
K 16
ochoceros

#76 Más bien estará en caza para ser ejecutado.

V 1
K 20
sk11z00

#1

sesión en directo de como lo intentan arreglar

V 3
K 23
D

#1 Eso en Windows no pasa

V 2
K 27
xenko
editado

#1 Todo.

V 0
K 10
D

#1 ¿EXplicación para no iniciados?

V 0
K 10
P

#14 El error humano es normal y puede pasarle a cualquiera. Lo que no tiene razón de ser es que no hubieran testeado nunca el sistema de backups wall wall wall

V 54
K 330
sandra67

#57 Coincido, todos somos humanos y todos metemos la pata.

V 2
K 25
woopi

#14 #57 Ya lo dice el antiguo aforismo latino "Errare humanum est, et maior calamitas cum abaco."

Es decir: "Errar es humano, pero para cagarla bien hace falta un ordenador."

V 5
K 32
M

#57 Culpa del sysadmin, pero segun mi experiencia es un tema de politica de empresa. Ocurre lo mismo en desarrollo. Cuantas veces un desarrollador ha dicho que un sistema no estaba listo para ir a produccion, pero desde arriba se ha dicho que se ponga en produccion igualmente.

El problema es que la gente que esta tocando directamente los sistemas son jovenes y no tienen la experiencia y/o el valor para decir NO a segun que cosas. Yo hoy en dia no tocaria un sistema en producccion sin estar segurisimo de que los backups funcionan perfectamente...

V 0
K 6
Libertual
editado

#57 No testear el sistema de backups también es un error humano...

Goto #180

V 0
K 10
p
editado

#57 El error no es justificable cuando eres un profesional, te la juegas, datos críticos dependen de ti y especialmente cuando existen formas de testear que la operación peligrosa que vas a ejecutar hace lo que tú crees que le has mandado hacer.

Para dedicarse a esto hay que tener una mínima autodisciplina. Un día te saltas eso, y casualmente pasa. A nadie le da por cerrar los ojos a propósito mientras conduce porque le pican o los tiene doloridos. Esto es lo mismo.

A mí ejecutar esto sin testearlo antes cuando había lo que había en juego me parece una negligencia grave.

V 0
K 10
A

Eso en la nube no hubiera pasado

V 26
K 168
alejojo

del google doc:

2017/01/31 23:00-ish
YP thinks that perhaps pg_basebackup is being super pedantic about there being an empty data directory, decides to remove the directory. After a second or two he notices he ran it on db1.cluster.gitlab.com, instead of db2.cluster.gitlab.com
2017/01/31 23:27 YP - terminates the removal, but it’s too late. Of around 310 GB only about 4.5 GB is left - Slack

V 15
K 126
anxosan
editado

#8 Eso pienso yo; no me puedo creer que un Administrador introduzca "por error" una instrucción que sabe que lo va a borrar todo; aquí alguien no está contándolo todo.

Edito. La explicación que señala #12 ya tiene más sentido. Los nombres de los directorios eran muy semejantes, pero aún así el fallo es de cuidado.

V 4
K 55
D
editado

#8 #13 Errores cometemos todos, seamos developers, sysadmins, médicos, candidatos a las primarias del PSOE, presidentes o traficantes de droga. Lo que una mañana recién levantado puede sonar como un error de bulto impensable, puede suceder cuando llevas 14 horas pegándote con un puto upgrade. Que no le quita hierro a la cagada, pero el que este libre de pecado...

Y aclarado esto, recordad chicos: Para directorios "presuntamente" vacíos que deban desaparecer, rmdir es vuestro amigo.

cc #33 #80

V 11
K 87
Closmick

#12 este no encuentra otro trabajo en su vida.

V 1
K 18
D

#14 En EEUU puede que no pero en España seguro que se lo rifan muchos polí...

Ya, ya, ya me lo cojo yo:

V 1
K 21
frg

#14 Solo el que toca puede equivocarse.

V 2
K 17
l

#81 Con esa frase seguro que ligas un montón.. lol

V 0
K 6
skgsergio

#14 Pues precisamente aunque YP fue quien originó el error humano (que tal como está explicado yo lo entiendo ya que tienes varias terminales de maquinas de un cluster que son prácticamente idénticas y si no te fijaste bien en el prompt la lias) también es el que ha originado la posibilidad de recuperar los datos ya que hizo un snapshot del LVM antes de meter la zarpa y el resto de backups no funcionan, salvo ese....

V 0
K 9
e

#12 Las claves de acceso deberían ser distintas las de prod que dev/pprod y a prod, solo deberías poder realizar tareas automatizadas y si pasa algo, entras manualmente a la maquina a la maquina.

V 6
K 45
mmm_

#19 A la máquina a la máquina a la máquina.

V 13
K 105
D

#19 se le pide al máquina que mire la máquina a ver si máquina.

V 3
K 24
r

#19 Salvo que se usen claves de ssh... sin password (que los hay... y muchos... roll )

V 0
K 9
dreierfahrer

#19 claves de acceso???? lol se valida con clave criptografica, habitualmente

V 0
K 8
r

#12 Culpa de Linux por ser tan rápido! si hubiera tardado más, como otros SO, se hubieran perdido menos cosas...

V 4
K 41
D

No olvidéis poner el "where" en vuestros "delete from":

V 13
K 99
cybervirtualman

#34 el ser humano es extraordinario.

V 0
K 7
dulaman

#26 Yo me quedé en los "extragos"

V 9
K 84
D

#29 Si nos vamos a poner puntillosos las oraciones terminan con un "." por norma general, no con un emoticono lol

PD: Es solo por tontear, acepto las correciones

V 3
K 36
e
editado

Hombre, son un poco cutres también. En cualquier servidor guarro tienen backups, que estas cosas pasan. Que no están borrando el portátil de su casa.
Ah vale , pone que los backups no funcionaron. Pues la cagada es esa no el borrado accidental. Lo grave es que el backup no funcione, por que podría haber sido peor. Al que se le debería caer el pelo es al del backup no al que borro.

V 11
K 76
Aokromes

#51 de nada sirve un backup si no compruebas que esta bien hecho lol

V 0
K 8
e
editado

#69 sí sí. Pero la cagada es esa.

V 0
K 7
JungSpinoza

#69 no tienes un backup hasta que intentas recuperar los datos de el

V 1
K 14
d

#69 según Schrödinger el Backup esta bien hecho, hasta que lo compruebas ...

V 2
K 16
Nandove

Demasiado poco nos pasa a los sysadmin... el día que nos organicemos, paramos el mundo de verdad, y a vivir como mad max pero matando lusers! VIVA WARDOG!

V 8
K 67
b

#35 Que de tiempo sin actualizar lleva el tio.
Y me quedé con las ganas de leer el final de un nuevo mundo.

V 3
K 23
mmm_

#58 Pues compra el libro, que ahí viene.

V 1
K 14
b

#92 lo sé.

V 0
K 6
PauMarí

#35 ahí ahí, yo podría dejar a un par de muy grandes empresas, de las del ibex, bien jodidas, pero seamos realistas, no lo haremos nunca....

V 0
K 7
D

No entiendo casi nada pero suena a marronazo gordo

V 7
K 60
D

#6 Para no entender lo has pillado bien

V 6
K 49
D

#9 Es un monton de mierda que huele desde aquí.

V 0
K 12
b

#6

Pongamos un poco de música a la situación.

V 7
K 69
m
editado

#30: Y con error de inconsistencia.

V 2
K 31
Jakeukalane

#44

V 2
K 16
Jakeukalane

#44 ah. No vi a #30

V 2
K 28
juliander

#30 veo esta mas apropiada

V 0
K 10
D

docs.google.com/document/d/1GCK53YDcBWQveod9kfzW-VCxIABGiryG7_z_6jHdVik/pub

Via reddit. Es una cagada de proporciones industriales ..

V 5
K 57
natrix

¿De verdad hay gente que mete sus proyectos en la nube y no se guarda una copia?

V 4
K 44
mmm_

#37 Si lees la noticia verás que el problema no es de los repositorios (código y Wiki), sino de la base de datos (incidencias y merge requests)

V 0
K 8
az1d0

#37 Gitlab es un repositorio remoto, o sea que tu proyecto lo tienes en el repositorio local siempre y una copia en el remoto. Si Gitlab perdiera todo pues lo metes en otro remoto (github, bitbucket, etc...).

V 0
K 6
dreierfahrer

#37 eeeeeeeeeeeste....

Eeeeeeeee

V 0
K 8
mangrar

#37 git es distribuido, tu siempre tienes el repositorio local. Pero no se han borrado los datos sino los metadatos del repositorio por así decirlo. o sea, información de commits, pull requests, cosas así.

V 1
K 21
e

Por suerte gracias a git, cualquiera que tenga copia del repositorio puede restaurarlo.

V 3
K 40
D

#16 Lo malo es que no fueron los repos lo que se perdió.

V 3
K 26
alfgpl

Me da que si ejecutas rm -rf, a poco que lleves un tiempito administrando, no lo haces sin querer.

V 2
K 34
n

#8 Yo tuve una cagada similar en un servidor de desarrollo hace años sudo rm -rf /

V 2
K 28
dreierfahrer

#33 esas cosas pasan...

Solo se moja el q se mete al rio.

V 2
K 15
frg

#8 Nop, pero puedes haber realizado un mierdascript en dos minutos, en el que se cuela un "/" en los parámetros, y dejas la máquina pelada.

Suerte que los backups eran "de verdad", no como los de la noticia, mágicos lol

V 1
K 18
sorrillo
editado

#8 A poco que lleves un tiempito administrando sabes que es la forma más sencilla de borrar una serie de archivos y/o carpetas sin tener que ir uno por uno y/o tener que repetir comandos por que una carpeta no está vacía u otros motivos.

Que sí, que es arriesgado y puedes cagarla mucho pero también es desesperante responder a los errores que van saliendo cuando quieres borrar el contenido y el comando no es suficientemente agresivo para ello.

Y como indican en un script es aún más fácil cometer ese tipo de errores, una variable mal inicializada o con una "/" de más y el destrozo es monumental.

El error es el que es, lo que sí es una negligencia muy grave es tener unas copias de seguridad sin comprobar de forma periódica que se pueden restaurar.

V 1
K 21
a

#99 Nota: rm -rf / no hace nada. Hace tiempo que rm incorpora una medida de seguridad para no borrar la raiz:
rm -rf /
rm: it is dangerous to operate recursively on '/'
rm: use --no-preserve-root to override this failsafe

V 0
K 7
Black_Diamond

Don't drink and root.

V 2
K 29
p

Yo hice una vez "rm -rf http://". Vivía en la Atlántida en aquel momento.

V 2
K 29
D

#83 suerte que google tenía backup de todo, incluídas las contraseñas y las cestas de compra de toda la intelnet

V 0
K 6
nemesisreptante

Por favor todos los que hayais ido de vacaciones a Gitlab mandad todas las fotos que sacasteís. Necesitaremos toda la ayuda posible para recuperar los datos.

V 3
K 29
D

#42 Ha sido un rm -rf en un servidor, no una banda de islamistas dedicándose a arrasar las obras de arte de un museo.

V 0
K 7
Pezzonovante

Vamos, que "la ha liao parda"

V 2
K 26
Aokromes

Tengo un repositorio en gitlab, desde las 12 de la noche intentando mandar un push, veo que esta en mantenimiento, espero media hora, sigue en mantenimiento, recargo la web en algun momento de la noche, veo la cagada, menos mal que tickets y PRs tengo pocas lol

V 2
K 26
TocTocToc
editado

#66 Puede que tengas algo de lisdexia.

V 1
K 25
D
editado

#85 No creo, nunca he tenido problemas relacionados con eso, simplemente no presto mucha atención ni le dedico el esfuerzo que debería para corregirme como es debido (no estoy orgulloso de ello, es solo por aclararlo). No se por qué he adquirido esa forma de escribir, pero es más dejadez que un problema.

V 0
K 7
D

#90 Pregunta: ¿eres programador, o administrador de sistemas? Porque si lo eres, esa dejadez sería criminal, y básicamente de lo que va esta noticia: escribir db1 en vez de db2.

V 1
K 17
mefistófeles

Debe ser una putada nivel épico, pero me he quedado obsoleto y ya no entiendo la terminología informática, aunque me ha parecido entender, en román paladín, que ha borrado lo que no debía borrar y las copias seguridad no funcionaron.

Pero cucha, que el no comprender la terminología y no estar seguro de qué dice la noticia, no es óbice o valladar para que un digno meneante haga comentarios como si supiera de qué estoy hablando

V 2
K 25
Abeel
editado

#46 Señor lanzó orden de eliminación de todos los archivos del servidor 1, cuando quería hacerlo en el 2. El 2 es el de pruebas y el 1 es el bueno, el que ve el público, el de producción. Cuando se dio cuenta pidió copia de seguridad, pero una de las mayores empresas gestoras vieron que no había (no fucionaba) . Recuperó una copia idéntica de como estaba el servidor hace un día (snapshot) pero aun faltaban datos.

V 2
K 28
chemari

#40 "índole" lleva tilde

V 1
K 20
D
editado

#65 y análisis lol

editado:
Y pérdida, si hay unas pocas.

V 1
K 17
Candidatas
11
meneos
tecnología La Audiencia Nacional de España niega a EEUU una extradición por uno de los mayores ciberataques de la historia: Conficker
13
meneos
tecnología Amazon Prime Vídeo te estafa. Que no te tomen el pelo
11
meneos
tecnología Siemens Gamesa planea instalar un aerogenerador de 21 MW, el más potente del mundo
10
meneos
tecnología PROSOLAR BIRDS, El original invento desarrollado en España para proteger los paneles solares de los excrementos de los pájaros
9
meneos
tecnología Sólo hay que añadir agua: Crea tus propios muebles con estos diseños de esponjas emergentes (ENG)
16
meneos
tecnología Escándalo en la Industria Tecnológica: Super Micro acusada de vender GPUs prohibidas a China
44
meneos
tecnología Policía quiere eliminar la comunicación cifrada de extremo
11
meneos
tecnología Tecnoestrés, fatiga informática y el derecho a la desconexión digital en el ámbito laboral
9
meneos
tecnología La Mega Drive llega a España
25
meneos
tecnología musicForProgramming ();
15
meneos
tecnología El proyecto Alia, el 'ChatGPT español' que entrena el Gobierno: "La calidad de las respuestas va a ser mucho mejor"
11
meneos
tecnología Dentro de los cartuchos de Super Nintendo [ENG]
10
meneos
tecnología La razón por las que los usuarios de Android pronto van a tener siempre encendido el Bluetooth
6
meneos
tecnología Investigadores de HKU Engineering descubren la clave para lograr células solares orgánicas eficientes y estables (eng)
8
meneos
tecnología Los trucos de los hackers de Super Mario podrían proteger el software de errores, según un estudio (eng)
7
meneos
tecnología Black Basta, el principal sospechoso en el ciberataque a Ayesa
7
meneos
tecnología Netflix es acusada de manipular imágenes en uno de sus documentales de true crime, en lo que supone romper una nueva barrera ética para la IA
6
meneos
tecnología Mi experiencia con Nintendo Switch en 7 años
5
meneos
tecnología Minoristas se quejan de Intel: "Los Core 14 son un desastre"
D

Y el "administrador cansado" ... ¿ya está más descansado?

V 1
K 19
JungSpinoza
editado

#32 Si ahora ya puede descansar en la cola del paro

Todo Ops que se precie ha dicho mas de una vez: "mierda" ejecutando un comando en producción.

V 0
K 7
D

Consecuencias para los que tenemos repositorios?

V 1
K 18
mr_b

#15 Los repositorios están intactos (y las wikis, que también están en git). El problema es la información adicional que se guarda en la base de datos, como pull requests, comentarios, etc.

V 4
K 40
dreierfahrer

#15 no han borrado repos, solo su db

V 1
K 19
D
editado

#15 Lo que tenemos nuestra propia instancia de GitLab en nuestro propio servidor porque no nos fiamos de que no pasen cosas de estas... ninguna en absoluto

V 1
K 18
PacoJones

No me gustaría estar ahora mismo en esa oficina.

V 1
K 18
Qban

#84 Lo cierto es que están todos desde casa:

V 1
K 13
a

Para que luego digan que los admin no tenemos responsabilidad. Te puedes cargar de una sentada millones se horas se trabajo.

V 1
K 16
Shinu

#43 Pues la verdad es que nunca he oído a nadie decir que los admins no tienen responsabilidad.

V 4
K 31
D

Y yo a punto de pagar por tener Github... y ahora investigando GitLab (que no conocía) veo que Bitbucket tiene repos privados gratis también.

¿Alguna recomendación? El único problema es que necesitamos GitLFS para subir assets gráficos MUY pesados.

(Aunque ver que GitLab tiene tan poca seguridad me escama muchísimo)

V 1
K 15
H

#78 Si eres universitario tienes 2 años gratis de Github pro. Si no lo eres, puedes usar bitbucket para repos privados y github para los públicos.

V 1
K 13
D

#100 Me sobran diez años para volver a ser universitario Pero gracias de todos modos.

V 0
K 7
tunic

#78 BitBucket va muy bien, personalmente lo prefiero a GitHub (el desarrollo basado en PR no me gusta, favorece a los llaneros solitarios o es la sensación que me da, cada uno trabajando en su propia copia del repo).

Tiene soporte para GitLFS, pero no sé exactamente las condiciones. En mis repos dice que tengo 110Gb disponible para GitLFS, pero no sé si es compartido entre todos los repos o cada repo. Supongo que será compartido.

https://confluence.atlassian.com/bitbucket/git-large-file-storage-in-bitbucket-829078514.html

V 3
K 30
reithor

Ignatius J Reilly seal of approval.

V 1
K 14
D

A great power comes with a great responsibility. Think before you type.

V 1
K 12
chemari
editado

Vamos, que mas les vale a todos los empleados de esta empresa ir actualizando su perfil de infojobs...

V 0
K 10
Azucena1980

Que entradilla más fashion.

V 1
K 10
TiJamásLlevaTilde

#2 Si esto lo lee mi madre, se queda igual no, peor.

V 3
K 34
D

#4 Ella diría: "¿A que voy yo y los encuentro?" Y de repente, sin que nadie sepa como, backups recuperados.

V 8
K 69
D

#4 Peor que una completa ignorante, lo dudo.

V 0
K 7
ccguy
autor

#4 ¿cómo lo pondrías tú para que lo entendiese tu madre?

V 0
K 19
D

clap

V 0
K 9
D

Tomo nota de esta 'graciosa anécdota' para exponérsela al próximo amigo o conocido que me recomiende ciegamente la subida y almacenamiento de todos mis archivos en 'la nube'.

V 1
K 9
e

#62 las veces que se pierden datos en la nube comparadas con las que se pierden en un ordenador personal deben ser 1 a mil. No pondría algo que no quiero que se borre en un pendrive o un disco duro de mi casa.

V 0
K 7
M

#62 El problema no es la nube, el problema es no conservar los archivos también en local, como también es un problema no tener una copia de tus archivos en local. Con lo fácil que es hacer copias.

V 2
K 19
r

La pesadilla de cualquier sysadmin... estar cansado y darle al enter luego de cualquier "rm ..."

V 0
K 9
empanadilla.cosmica

#77 Y sin estar cansada, lo que os podría contar.

Un chupito por la eliminación de un fichero que no es, el reboot del servidor equivocado, destruir alguna base de datos haciendo el animal y otros actos semejantes.

El lunes detecté que unos backup de bases de datos que no funcionaban desde mayo del año pasado. Dos días corrigiendo unos scripts que no sé por qué dejaron de funcionar, ni quien fue el psicópata que los puso en producción de manera tan chapucera (daban miedo).

V 1
K 13
D

Mariano rajoy habrá apuntado el código para un amigo ?

V 0
K 7
D

Voy a hacer un clone de mis repositorios relevantes. Son de Github, pero estas cosas lo acojonan a uno.

V 2
K 6
D

Me quedo con las jetas de los inutiles de la foto del artículo.
Se les ve la gota de sudor bajando por la frente ante un despido inminente, por jaberla cagado.

V 4
K -13
dreierfahrer

#47 No jodas, no puedes echar a nadie por una mierda asi.

V 0
K 8
empanadilla.cosmica

#47 El problema no es equivocarse, el problema es equivocarse siempre en lo mismo.

Cualquier administrador de sistemas competente ha metido la pata más de una vez. Son esas metidas de pata las que nos hacen mejorar y llegar a la expertez. Si por meter la pata se despidiese a la gente mi director de recursos humanos debería despedirse a si mismo varias veces, porque le ha declarado nulos los jueces varios despidos, dos ERE y la empresa se ha comido una multa por cesión ilegal de trabajadores.


La conclusión de este asunto es que se hará un informe postmortem, y se decidirá llevar a cabo una serie de medidas para que si el problema raiz se reproduce (borrado de un directorio en el servidor de producción) las consecuencias sean mitigadas, es decir, se harán backups, se establecerán políticas de supervisión y recuperación de backups, que harán la plataforma más robusta a errores humanos.

Y quien, sabe, quizás también automaticen la destruccción y creación de entornos de pruebas para evitar más errores humanos.

V 1
K 13
D

#47 Si despides a gente por cometer un error... contratarás a gente que todavía no lo ha cometido.
Eso sí que es de inútiles.

V 0
K 7
Howard

Bueno, pues seré yo el primero en preguntarlo: ¿esta mierda por qué es relevante?

V 10
K -28
D

#20 Porque afecta a desarrollo de software de diferente indole. Sin saber a cuantos usuarios y de que clase (si son empresas o particulares) la perdida de información, por pequeña que sea, puede causar desde retrasos a grandes extragos que solo pueden solventarse con horas y horas de analisis. A nivel comercial puede hacerte perder la carrera con otro producto por ejemplo. O que tuvises una presentación preparada y no puedas cumplir debidamente o a saber. Es un problema que puede deribar en otros muchos.

V 30
K 193
Howard

#21 Gracias

V 1
K 10
mmm_

#21 Te perdono las tildes pero ese "deribar" duele.

V 12
K 83
D

#26 Ya no me deja editar

V 0
K 7
TocTocToc

#26 #27 Las prisas al escribir causan a veces extragos.

V 4
K 47
D

#61 No te creas que son las prisas, asumo mi parte de culpa. Esa se me ha escapado sin prisas.

V 0
K 7
mmm_

#61 También, también.

V 0
K 8
barkalez

#61 Extragos de Whisky...

Torrente, me debes 5000 pesetas de Whisky...

V 0
K 6
Thelion

#26 Hace extragos.

V 1
K 14
BiRDo

#21 derivar

V 1
K 13
D

#39 Por que me corrijais 7 veces no lo voy a poder editar lol. Ya se pasó el tiempo.

V 0
K 7
D
editado

#21 Tú no serás bombero, no?

V 5
K 52
D
editado

#93 No tengo pulmón para eso lol

V 0
K 7
D
editado

#93 Y por cierto, las interrogaciones en español se abren con el signo "¿".

Ya vais dos que me corregís cometiendo faltas lol

V 0
K 7
dreierfahrer

#21 hombre... es git.... en ese sentido no es tan sumamente grave....

Pero es un marron muy gordo y es gracioso q no me pase a mi....

V 1
K 19
m
editado

#20: Tu imagínate que eres arquitecto en 1960, y de repente el conserje decide "limpiar un poco" y tirar a la basura todos los papeles de la oficina, vas a por ellos al contenedor pero ya pasó el camión de la basura.

Pues esa es la que han mangado. Te recomiendo la canción "No te olvides de poner en WHERE en el DELETE FROM" para que lo entiendas mejor.

V 6
K 50
Howard

#53 ¿Pero solo 300 GB? ¿Quién guarda su información ahí? ¿Obama?

V 1
K 18
mangrar

#63 no se han borrado los datos en si, o sea, el código. Sino la base de datos con pull requests y demás. Sino, sería mucho mas que 300Gb.

V 1
K 17
frg

#53 No hace falta estar en 1960. Estube en una empresa de alarmas y sistemas de seguridad, que para pasar una ISO, llevó todos sus planos y carpetas de proyecto de papel a un almacén, ... Y hasta aquí puedo leer. No logramos recuperar nada, porque nadie sabe a que almacén se llevó, si se destuyó, o si se perdieron por el camino.

V 5
K 43
dreierfahrer

#91 jajajajajajajajaajja

V 0
K 8
Abeel

#53 pero existe un snapshot, así que en tu ejemplo es tienes los papeles en el escritorio, el conserje lo tira, pero en tu caja fuerte tienes los papeles de ayer, y sólo has perdido los de hoy.

V 2
K 30
Jakeukalane
editado

#53 #20 -> #148

V 1
K 22
angelitoMagno

#20 Aquí hay muchos informáticos y hacer un "rm -rf" en el sitio equivocado es nuestra segunda mayor pesadilla.
La mayor pesadilla es la que describe este vídeo:

V 2
K 34
Howard

#97 Ya me imaginaba. Solo pretendía meterme un poco con vosotros.

V 1
K 18
Aokromes

#97 o hacer drop a la base de datos erronea lol

V 1
K 19
redscare

#20 Porque abundamos los frikis de IT en meneame y estas cosas nos molan

V 1
K 14
1 2 3