Brevenotas Falla en el sistema de Migraciones - pérdida de datos

Zuljin · 22 Febrero 2022

Aviso que abro este thread sólo para hablar de temas técnicos y administrativos, temas políticos en otro hilo.

No se si vieron esta noticia

Falla en el sistema de Migraciones y falta de respaldo obligaron a reconstruir datos de miles de extranjeros desde 1993 a 2021 - CIPER Chile

Medio de investigación periodística independiente en Chile, enfocado en reportajes de actualidad y brindar información de calidad a la ciudadanía.

www.ciperchile.cl

El Sistema B3000, la principal base de datos del Servicio Nacional de Migraciones, sufrió una caída en octubre de 2021. Aunque en noviembre la Subsecretaría del Interior informó que solo hubo problemas en el proceso de solicitudes de visa, se habían borrado los registros de extranjeros –que permiten la emisión de visas o determinar expulsiones– desde 1993. Lo grave es que también falló el mecanismo para respaldar la información, encargado a empresas externas, lo que impidió recuperar los archivos. La información ha sido reconstruida gracias a un registro paralelo, pero los datos del periodo que va del 11 de agosto al 25 de octubre de 2021 fueron recuperados a partir de archivos de otras entidades –como la PDI y el Poder Judicial– y copiando “a mano” documentos en papel, por lo que no hay certeza de que se haya restaurado todo en esas once semanas.

pero es la mansa cagadita. Le doy vueltas al tema y no se me ocurre como pudo ocurrir si es que "a lo mejor" tenían backup.

Me acuerdo cuando Entel nos rompió los volúmenes que soportaban la base de datos de Producción que almacenaban todos los bips de la antigua tarjeta multivía y el puto Entel tampoco había hecho respaldo: salimos jugandos porque de pura cueva yo, como DBA Oracle junior en ese entonces, había implementado un backup automático para aprender.

Yo se que no hay ningún sistema invulnerable al cagazo, ya sea humano o de infraestructura tecnológica, y es por eso que se crean planes de desastres que consideran backups y también importante es que deben PROBAR LOS PUTOS BACKUPS. Yo periódicamente recupero respaldos de la base de datos en una máquina virtual temporal que me sirve para probar las piezas de backups, los procedimientos de recuperación y el tiempo que me demoro en recuperar, lo cual me permite mantener actualizado el tiempo del RTO.

Corríjanme si me equivoco colegas sysadmins, pero entiendo que este cagazo no se resuelve con simplemente irse a la nube porque las clouds no te respaldan nada si tú no se los indicas.

En fin, siéntanse libres de dar sus experiencias, comentarios y elucubraciones al respecto.

Soujiro · 22 Febrero 2022

yo estoy al debe en "probar" mi backup, la ultima vez que lo use fue en restaurar una replicacion hace unos 8 meses mas menos, asi que en ese entonces "funcionaba".

El gran cacho que tengo con el backup principal es que pesa 1.5 TB, andarlos subiendo y bajando de la nube y/o restaurarlo siemrpe toma tiempo.

Los respaldos mas chicos realizados con la misma logica si se usan constantemente, el problema como dije es nuestra db principal.

Igual son unos macacos si el backup no tiene algun check minimo que sea, yo aprendi eso a las malas en mi primera pega, desde entonces siempre hay cuando menos un check de tamaño que el backup se realizo correctamente, un clasico es que la tarea del backup corre pero no copia nada ergo termina pesando 0 el backup.

p.d como ejemplo el backup de este fin de semana no corrio, me llego notificacion al respecto via slack y lo tuve que lanzar manualmente ayer en la mañana temprano. el backup no funciono por que chocamos a nivel de ip con otras pruebas que estabamos realizando.

Sago7 · 22 Febrero 2022

Lo grave es que también falló el mecanismo para respaldar la información, encargado a empresas externas, lo que impidió recuperar los archivos.

Que den ahora ya el nombre de esa "empresa" que no valida la integridad de los respaldos ni siquiera cada 10 años. Y de pasada cuanto les pagaban. brb

Y además, nada de alta disponibilidad ni nada de todas las cosas informáticas que existen para prevenir la perdida de datos. Digo, para no culpar solo a los de los respaldos.

ricm · 22 Febrero 2022

puta hoy en dia es tan facil sacar 99 backups si se quiere, y backups de los backups, etc.
Mis sitios cagones en digitalocean sacan 3 backups mensuales, uno que copia digitalocean mismo en contenido completo de mis VM, tambien un script en CRON que hace mysqldump, y ademas hago unos a mano cuando tengo tiempo. No veo como ellos no puedan hacer una version super avanzada de lo mismo.

Lordnet · 22 Febrero 2022

pero es que no entiendo

no había política de respaldo?
los jobs de respaldo no corrieron? (directorio /tmp)
nunca probaron lo que estaban respaldando?

El programa de pruebas de restauración creo que está al debe en algunas empresas, xq lo lógico seria probar una vez al año ir a buscar una cinta a bodega y probar restaurar desde ella. pero es un weveo. cuando es del filesystem, es menos weveo (puedesd tomar un archivo de muestra) , pero restaurar una instancia de base de datos, no se si pueden restaurar un trozo de la tabla.

el otro problema que puedes tener es cuando quieres restaurar una base de 2 TB al final necesitas doble storage, los 2 TB que siguen operando en producción + los otros 2 TB que necesitas asignar para restaurar la base en una segunda instancia.

me acuerdo otro problema que tuvimos hace años con un backup de fileserver. el servidor hacia fullbackup de 250 GB diario. y se demoraba >25 horas . es decir, antes que terminara el job del lunes ya partía el del martes.

Corríjanme si me equivoco colegas sysadmins, pero entiendo que este cagazo no se resuelve con simplemente irse a la nube porque las clouds no te respaldan nada si tú no se los indicas.

tomando el ejemplo de la calculadora de azure/AWS, tu ahi le entregas las políticas de respaldo.

K3rnelpanic · 22 Febrero 2022

La empresa encargada de los respaldos será la que comienza con S y termina con ONDA? :zippycafe

Harima · 22 Febrero 2022

Zuljin dijo:
Corríjanme si me equivoco colegas sysadmins, pero entiendo que este cagazo no se resuelve con simplemente irse a la nube porque las clouds no te respaldan nada si tú no se los indicas.

Por lo menos en mi experiencia en la mayoría de los lugares en que he trabajado por pyme de 10 personas que fuera, siempre nos basamos en el DRP, mas que nada porque estamos en Chile y sabemos que puede existir un incendio, inundación, terremoto o cualquier incidente en donde algo se puede romper de la forma menos esperada (como que se entre un gato por una ventana y marque algun circuito o fuente de poder y algo explote), tonces, si se te puede pasar uno que otro detalle, pero para eso esta el ejercicio del DRP, para ir mejorando el plan de recuperación.
En el área TI el DRP es lo minimo, si no lo tienes te estas buscando que cosas malas te pasen y te mereces todo lo malo que te pueda pasar, si no conoces que es, sabemos entonces que entraste ahí por puro pituto y no tienes idea de lo que haces XD

zatanax · 22 Febrero 2022

Lo raro que por ser del estado debería haber auditorías, estas auditorías de ti dicen que se tiene que probar la recuperación de los respaldos , pero perder el histórico es como mucho ,este es un buen ejemplo de un cagazo por externalizar .

Zuljin · 22 Febrero 2022

Harima dijo:
Por lo menos en mi experiencia en la mayoría de los lugares en que he trabajado por pyme de 10 personas que fuera, siempre nos basamos en el DRP, mas que nada porque estamos en Chile y sabemos que puede existir un incendio, inundación, terremoto o cualquier incidente en donde algo se puede romper de la forma menos esperada (como que se entre un gato por una ventana y marque algun circuito o fuente de poder y algo explote), tonces, si se te puede pasar uno que otro detalle, pero para eso esta el ejercicio del DRP, para ir mejorando el plan de recuperación.
En el área TI el DRP es lo minimo, si no lo tienes te estas buscando que cosas malas te pasen y te mereces todo lo malo que te pueda pasar, si no conoces que es, sabemos entonces que entraste ahí por puro pituto y no tienes idea de lo que haces XD

Entiendo que para el problema en cuestión un DRP no sirve.
Supongamos que un operador casual o intencionalmente se piteó todos los registros de la base de datos. Ese borrado lógico tambien se va a replicar al sitio de contingencia.

Lordnet · 22 Febrero 2022

Zuljin dijo:
Entiendo que para el problema en cuestión un DRP no sirve.
Supongamos que un operador casual o intencionalmente se piteó todos los registros de la base de datos. Ese borrado lógico tambien se va a replicar al sitio de contingencia.

depende del escenario del DRP

el tipico es desastre datacenter, donde la estrategia es trasladar los servicios al site secundario donde se levanta el servicio.

y arreglar el sitio caido dependerá de la naturaleza del incidente y del servicio
1) que vuelva solo (suponiendo corte de fibra)
2) se repara por replicación (en servidores con replicación, o storage)
3) instalar de cero y restaurar. (por ej: falla de hardware)

Recuerdo que el controlador de dominio no puedes recuperarlo desde un respaldo. tomas el secundario y lo replicas al primario.

Zuljin · 22 Febrero 2022

Lordnet dijo:
depende del escenario del DRP

el tipico es desastre datacenter, donde la estrategia es trasladar los servicios al site secundario donde se levanta el servicio.

y arreglar el sitio caido dependerá de la naturaleza del incidente y del servicio
1) que vuelva solo (suponiendo corte de fibra)
2) se repara por replicación (en servidores con replicación, o storage)
3) instalar de cero y restaurar. (por ej: falla de hardware)

Recuerdo que el controlador de dominio no puedes recuperarlo desde un respaldo. tomas el secundario y lo replicas al primario.

Es que un sitio DRP tiene que estar sincronizado con el menor lag posible (RPO), porque si no no tiene sentido su existencia. Y en esa situación un borrado de datos en el sitio principal también se te replica al drp.

Tbon · 22 Febrero 2022

K3rnelpanic dijo:
La empresa encargada de los respaldos será la que comienza con S y termina con ONDA?

Hasta el 31 de julio de 2021, estos respaldos y su mantención estuvieron a cargo de Sixmanager SpA, que se había adjudicado el contrato con la Subsecretaría del Interior por medio de un Convenio Marco que tenía con el Estado, el que terminó a fines de 2020. Pero, ante la demora en la nueva licitación del servicio, la Subsecretaría mantuvo a Sixmanager vía trato directo durante cinco meses más. Su último contrato fue por los meses de junio y julio de 2021 y ascendió a 732,66 UF.

Según los registros en Mercado Público la licitación fue adjudicada en mayo a la empresa Santana Red de Negocios SpA (SRN), pero no fue hasta el 2 octubre de 2021 que la empresa comenzó a prestar el servicio.

Entre el fin del contrato de Sixmanager (31 de julio de 2021) y el inicio del contrato de Santana Red de Negocios (2 de octubre de 2021) queda un vacío de dos meses (agosto y septiembre) en donde no se registran en Mercado Público contratos u órdenes de compra para proveer el servicio de arriendo de infraestructura y respaldo de las bases de datos del Ministerio del Interior.

Es decir, nadie se preocupó de que la nueva empresa adjudicada estuviera haciendo la pega.

La duda que me queda, es que si la empresa anterior si estaba haciendo respaldos, como es que no pudieron recuperar una parte desde ese ultimo respaldo? 🤔

Lordnet · 22 Febrero 2022

Zuljin dijo:
Es que un sitio DRP tiene que estar sincronizado con el menor lag posible (RPO), porque si no no tiene sentido su existencia. Y en esa situación un borrado de datos en el sitio principal también se te replica al drp.

tomemos el ejercicio de extranjería
un trabajador indignado borra todas las tablas de producción.

efectivamente se replican a todos los sites, y por tanto se borran tambien.

por lo que ahora tu DRP indicará que deberías ejecutar una restauración a partir de lo que tengas en el robot de respaldo o en cintas. si tu respaldo es unicamente un job diario. entonces el RPO es de 24 horas.

el patinazo/atentado fue el lunes a las 13 y tu backup corrió a las 7 AM.
entonces solo tienes que recuperar la data desde el ultimo respaldo correcto, y "me imagino" que desde el transaction log pudiese reconstruir la data desde las 7 AM a las 13

Además extranjería pos, no es un sistema transaccional de alto movimiento, no es la tarjeta bip, fonasa o una telco. Tampoco es un sistema descriteriadamente grande, pero si, a diferencia de la banca, guardan dato por mucho más tiempo.

Lordnet · 22 Febrero 2022

Tbon dijo:
Hasta el 31 de julio de 2021, estos respaldos y su mantención estuvieron a cargo de Sixmanager SpA, que se había adjudicado el contrato con la Subsecretaría del Interior por medio de un Convenio Marco que tenía con el Estado, el que terminó a fines de 2020. Pero, ante la demora en la nueva licitación del servicio, la Subsecretaría mantuvo a Sixmanager vía trato directo durante cinco meses más. Su último contrato fue por los meses de junio y julio de 2021 y ascendió a 732,66 UF.

Según los registros en Mercado Público la licitación fue adjudicada en mayo a la empresa Santana Red de Negocios SpA (SRN), pero no fue hasta el 2 octubre de 2021 que la empresa comenzó a prestar el servicio.

Entre el fin del contrato de Sixmanager (31 de julio de 2021) y el inicio del contrato de Santana Red de Negocios (2 de octubre de 2021) queda un vacío de dos meses (agosto y septiembre) en donde no se registran en Mercado Público contratos u órdenes de compra para proveer el servicio de arriendo de infraestructura y respaldo de las bases de datos del Ministerio del Interior.

Es decir, nadie se preocupó de que la nueva empresa adjudicada estuviera haciendo la pega.

La duda que me queda, es que si la empresa anterior si estaba haciendo respaldos, como es que no pudieron recuperar una parte desde ese ultimo respaldo? 🤔

al parecer ni la antigua tampoco. porque si sixmanager hubiese funcionado, solo hubiesen perdido desde 2021 a la fecha. no todo el universo.

por suerte no son proveedores de por aqui

rodrigokfw · 22 Febrero 2022

hola, alguién tiene el contacto?, quiero limpiar los campos de mi base de datos sql, pero el azure no se que politica de seguridad tiene que no me deja :S

Zuljin · 22 Febrero 2022

Ahora bien, como dato les digo que no es común que una institución del estado "chica" posea un sitio remoto de contingencia básicamente porque es caro (porque si, cuesta harta plata la huea) y los tomadores de decisión no siempre tienen considerado el costo de indisponibilidad de servicio producto de un cagazo en el datacenter principal versus el costo de arrendar un datacenter equipado (consideren hosting, enlace, fierro y licencias de software).

Algunas instituciones ya se han ido a la nube y a nivel central el gobierno están forzando a las instituciones chicas y medianas que no lo hayan hecho a que migren sus servicios a alguna cloud que, ojo, tampoco es tanto ahorro en plata versus tener tu propio datacenter (lo sé porque me tocó evaluar migrar a la nube de Oracle algunos servicios).

Personalmente no sé técnicamente cómo fue que se perdieron los datos en Migraciones (¿Borrado lógico de la BD? ¿Se pitearon una lun? ¿Cagó una máquina virtual? ¿Cagó el server?) por lo que para mí es impreciso decir con exactitud que la solución sea drp y/o cloud, pero lo que si es seguro es que el cagazo de no tener respaldos y no haberlos probado fue mayúsculo.

Lordnet · 22 Febrero 2022

pero depende del servicio, base de datos de servicios chicos con poco movimiento valen huevo subirlas a azure, con redundancia respaldo y toda la vaina.

ahora una plataforma mision critica con chorromil CPU+RAM , si, puede que hasta te salga mas barato tenerla en datacenter. además entiendo hay beneficio contable de comprar fierro, versus cloud que se va todo a gasto.

Zuljin · 22 Febrero 2022

Ojo que cuando hablo de instituciones "chicas" no crean que son del porte de un colegio y que su sistema es una hueaita en lamp, sino que son instituciones que manejan sus buenos teras de datos (mucha digitalización de documentos).

Yo coticé la nube de Oracle que es la más barata y efectivamente nos daba un ahorro pero no era mucho tampoco. Y eso que agregamos la opción drp de nube a nube.

_userdefault · 23 Febrero 2022

En mi trabajo, tengo todo en AWS y las instancias EC2 las respaldo con AWS Backup de forma automática, he usado esos respaldos algunas veces y andan como reloj suizo, lo que no entiendo es como el gobierno, trabaja con empresas que nadie conoce!!!! aló azure, aló GCP, aló AWS... pagan mas plata que la chucha y con precios ultra inflados que varios deben cortar x dentro, deberían pescar todas las weas, migrarlas a GCP, Azure, AWS y chao, mas barato y andan como reloj suizo

Opinión muy personal: no le confiaría mi infraestructura a ningún hosting nacional/internacional chico (aunque sean muy buenos y tengan menos latencia) prefiero irme con los tres grandes nomas.

Harima · 23 Febrero 2022

Zuljin dijo:
Entiendo que para el problema en cuestión un DRP no sirve.
Supongamos que un operador casual o intencionalmente se piteó todos los registros de la base de datos. Ese borrado lógico tambien se va a replicar al sitio de contingencia.

Y para eso esta el backup, en el drp se define cuanto tiempo y/o cantidad de registros están dispuestos a perder por eso se define por ejemplo un full y los incrementales, y luego se hacen pruebas en ambientes controlados como por ejemplo borrar algunas tablas y si es factible su recuperación y/o reproceso, y con el resultado de ese ejercicio se generan las iteraciones.

Brevenotas Falla en el sistema de Migraciones - pérdida de datos

Fundador

Fanático

Tibetan Mod

☭

Autoridad Ancestral de Transacciones

non serviam

Pegao al tarro

Capo

Fundador

Autoridad Ancestral de Transacciones

Fundador

Football total philosophy

Autoridad Ancestral de Transacciones

Autoridad Ancestral de Transacciones

Gold Member

Fundador

Autoridad Ancestral de Transacciones

Fundador

Miembro Regular

Pegao al tarro