On 2017-05-19 17:45, Juan Erbes wrote:

Parece ser que resucitaron: https://www.redsharknews.com/technology/item/4600-ibm-releases-mammoth-15tb-...

No me suena el nombre ese de datasette, pero me imagino lo que es. Se que hay gente que graba las copias de seguridad en cinta. Una tipo ISO nosecuantos. LTO? Se que son dispositivos bastante caros, 1500$ menciona el artículo. Una cinta de 15 TB es algo muy interesante, pero costará una pasta gansa. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" (Minas Tirith))

On 2017-05-20 09:56, Rafa Griman wrote:

Wenas :)

2017-05-20 0:51 GMT+03:00 Carlos E. R. <>:

...

On 2017-05-19 17:45, Juan Erbes wrote:

...

Se que hay gente que graba las copias de seguridad en cinta. Una tipo ISO nosecuantos. LTO? Se que son dispositivos bastante caros, 1500$ menciona el artículo.

Actualmente LTO7. Yo prefiero LTO porque es un estándar. El de IBM es tecnológicamente mejor ... pero sólo de IBM.

Exacto, tiene sentido. Varios fabricantes, luego mejor servicio.

...

Una cinta de 15 TB es algo muy interesante, pero costará una pasta gansa.

Hay que ver si es rentable. En entornos de HPC es rentable.

Haces una inversión en el aparato, pero luego el coste por gigabyte compensa. Para usuarios pequeños, gastar 1500$ en el aparato es difícil de justificar, es más que un ordenador. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" (Minas Tirith))

On 2017-05-20 16:24, Juan Erbes wrote:

Ya que no se acuerdan del Datasette, les dejo los links:

https://www.youtube.com/watch?v=Cq0uSCRpM18

https://en.wikipedia.org/wiki/Commodore_Datasette

Por aquellos tiempos, era la unica forma de almacenar datos y programas en las Commodore 64.

El casette, no era ni mas ni menos que los estandar de audio.

Me acuerdo por aquel entonces en mis primeras practicas en Basic, haber usado la Commodore 64 para generar el trazado de una sinusoidal mediante series de Fourier.

Ah, un casette especial para el commodore. Yo nunca tuve uno. Sí pude jugar con el Sinclair Spectrum, tuvimos alguno compartido en la residencia de estudiantes. Lo usabamos con un reproductor de cinta normal y corriente. El profesor tenía un microdrive creo que se llamaba, un lector de cinta digital miniatura. No, ZX microdrive, pone la wikipedia. https://en.wikipedia.org/wiki/ZX_Microdrive https://en.wikipedia.org/wiki/ZX_Spectrum https://es.wikipedia.org/wiki/Sinclair_ZX_Spectrum https://es.wikipedia.org/wiki/ZX_Microdrive Yo vi un articulo de esos de hágaselo usted mismo, para usar cinta de video. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" (Minas Tirith))

On 2017-05-21 05:35, Rafa Griman wrote:

Hola :)

2017-05-20 16:19 GMT+03:00 Carlos E. R. <>:

...

Haces una inversión en el aparato, pero luego el coste por gigabyte compensa. Para usuarios pequeños, gastar 1500$ en el aparato es difícil de justificar, es más que un ordenador.

Cierto.

Para volúmenes pequeños no te vale la pena una unidad de cinta, es preferible un sistema de ficheros fiable (ZFS o XFS, mi orden de preferencia) en un servidor con memoria ECC y discos buenos (HGST si son rotacionales y Samsung EVO si son SSD, es mi preferencia aunque YMMV).

Para grandes volúmenes de datos la unidad de cinta tiene dos ventajas: - el consumo del aparato en sí (mucho menos que el equivalente en disco). La necesidad de refrigeración que necesita es mucho menor. - poder almacenar datos fuera, físicamente te puedes llevar las cintas a otro lugar.

Bueno, puedes hacer copias de seguridad con discos duros extraibles; es lo que yo hago.

Eso sí, el disco ocupa mucho menos espacio y es más rápido (más ancho de banda y menor latencia). Aunque la primera ... se puede discutir según el tipo de librería, ...

OJO, me refiero sólo al hardware, hay software de backup muy caro que te dispara el precio ;)

Je! Yo hago un simple rsync. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" (Minas Tirith))

Unas notas más:

Las cuentas que yo hice la para organización para la que trabajo (grande, muy grande) concluían que *para backup* - sin contar costes de electricidad - el almacenamiento en disco es más rentable que la cinta. Las razones de esto son:

- La deduplicación es más eficiente que la compresión (cerca de 8x vs 2.5x) - El coste del sw de backup es un factor considerable. Algunos proveedores permiten ciertos trucos pero, en general, el mantenimiento del sw de backup, es un coste muy elevado. - El coste de la cinta puede parecer bajo frente al disco, pero cuando incluyes otros factores: - mantenimiento de las librerías (las grandes) y un montón de drives, el OPEX empieza a subir. - el coste operativo de manejar cintas, externalizarlas, etc. no se suele tener en cuenta... y es elevado. - el coste operativo de migrar las cintas cada una o, incluso, dos generaciones es enorme. La misma operativa sobre disco es muuuucho más sencilla y rápida.

... pierde esa ventaja.

Además, hay un coste que no se suele incluir: el error silencioso. Ocurre que, muy de vez en cuando, una drive puede guardar mal un dato en la cinta, o el dato 'pudrirse' en la cinta... y no hay forma de saberlo hasta que necesitas ese dato; entonces suele ser demasiado tarde.

Un disco, en cambio, suele ir protegido con RAID y las controladoras hacen un trabajo excelente controlando estas cosas y, en muchos casos, el sw de backup puede ejecutar tareas periódicas adicionales de comprobación de integridad con costes operativos muy bajos (no hay que andar montando y desmontando cintas que - aún de forma automática - es un proceso costoso en tiempo).

Finalmente, en cuanto a rendimiento: Realmente las cintas no son malas en cuanto a lecturas o escrituras *secuenciales*; cualquier cosa que no sea eso el rendimiento se reduce muchísimo... más o menos igual que un disco. Las operaciones de escritura de datos deduplicados tienen rendimientos aceptables... al contrario que la recuperación de datos... el rendimiento de 'rehidratación' no es brillante, siendo generosos :-)

En esta organización hemos dejado la cinta para aquellas situaciones en que doble copia a disco (una local, otra remota) no es posible por razones de línea de comunicación o legales (no es posible enviar datos fuera de ciertos países).

Just my two cents.

Donde, a pesar de todo, sí veo un caso de uso de libro para cintas es en 'archivado profundo': información no estructurada que nunca se consulta (o muy rarísima vez). Para este caso de uso, quizás LTFS pueda ser una solución. Las cintas basadas en BaFe (LTO, TS o T10000) son estupendas para eso, las partículas de BaFe son muy, muy estables en el tiempo y la posibilidad de una corrupción No obstante, también compite con soluciones de almacenamiento de objetos (yo las comparo con aspirina, sirve para casi todo), con un coste por TB de almacenamiento francamente competitivo. Un poco de info resumida de BaFe vs MP: http://www.fujifilmusa.com/products/tape_data_storage/innovations/barium_fer... -- Saludos, miguel Los agujeros negros son lugares donde dios dividió por cero. Black holes are places where god divided by zero. Steven Wright -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

Hola :) 2017-05-22 10:47 GMT+03:00 miguel gmail :

Buenas,

...

...

...

Actualmente LTO7. Yo prefiero LTO porque es un estándar. El de IBM es tecnológicamente mejor ... pero sólo de IBM.

Hay que distinguir varias cosas.

- la capacidad de las las cintas de 15 TB no dependen del fabricante, sino de la densidad de la cinta y de la longitud de ésta. Las densidades de las cintas de 15 TB son posibles gracias a un material relativamente reciente basado en Ferritas de Bario (BaFe): https://en.wikipedia.org/wiki/Barium_ferrite

Antes se usaban de 'Metal Particles' (MP). La diferencia es la forma que adoptan las partículas que se orientan a los campos magnéticos.

Es cierto que, además, influye el algoritmo de compresión que use cada drive... IBM promete 3x en sus TS, LTO 2,5x... no recuerdo cuánto promete STK (luego Sun, ahora Oracle) en sus T10000.

Agree en todo :)

...

...

Exacto, tiene sentido. Varios fabricantes, luego mejor servicio.

Psché... yo he vivido con librerías STK y... servicio inmejorable, la verdad. Creo que esto depende más del contrato de soporte que tengas. En cualquier caso, la tecnología de drive y cintas es muuuuy madura, dan poca guerra.

No me referia tanto a soporte o mantenimiento sino a la posibilidad de tener mas fabricantes (IIRC, LTO tiene 3 fabricantes) o competencia ... aunque ya sabemos como funciona con solo 3 fabricantes: se ponen de acuerdo y punto. Tambien porque es un estandar abierto. Estoy de acuerdo con lo que dices de que depende del contrato :)

...

...

...

...

Una cinta de 15 TB es algo muy interesante, pero costará una pasta gansa.

...

...

...

Hay que ver si es rentable. En entornos de HPC es rentable.

Esto no lo entendí... HPC me suena a exigencia de rendimiento rabioso, pero las cintas... salvo en lectura secuencial no tienen el rendimiento que supongo necesita un HPC. A qué te refieres?

No se utilizarian para "trabajar" (en plan LTFS) sino para Archivado y HSM/ILM en el mundo de HPC. Para este tipo de cosas no requieres una gran velocidad ni baja latencia sino volumen bruto. Aunque algunos fabricantes tienen buenas "bestias", como SpectraLogic con su T-Finity y su T950 (nosotros tenemos ambos modelos) que te permiten buen ancho de banda. El cientifico/ingeniero acaba un proyecto y se manda todo a cinta para dejar espacio libre en disco. El dato archivado o en HSM se utiliza muy rara vez.

...

...

Haces una inversión en el aparato, pero luego el coste por gigabyte compensa. Para usuarios pequeños, gastar 1500$ en el aparato es difícil de justificar, es más que un ordenador.

Cierto.

Para volúmenes pequeños no te vale la pena una unidad de cinta, es preferible un sistema de ficheros fiable (ZFS o XFS, mi orden de preferencia) en un servidor con memoria ECC y discos buenos (HGST si son rotacionales y Samsung EVO si son SSD, es mi preferencia aunque YMMV).

Para grandes volúmenes de datos la unidad de cinta tiene dos ventajas: - el consumo del aparato en sí (mucho menos que el equivalente en disco). La necesidad de refrigeración que necesita es mucho menor. - poder almacenar datos fuera, físicamente te puedes llevar las cintas a otro lugar.

Eso sí, el disco ocupa mucho menos espacio y es más rápido (más ancho de banda y menor latencia). Aunque la primera ... se puede discutir según el tipo de librería, ...

OJO, me refiero sólo al hardware, hay software de backup muy caro que te dispara el precio ;)

Las cuentas que yo hice la para organización para la que trabajo (grande, muy grande) concluían que *para backup* - sin contar costes de electricidad - el almacenamiento en disco es más rentable que la cinta. Las razones de esto son:

- La deduplicación es más eficiente que la compresión (cerca de 8x vs 2.5x) - El coste del sw de backup es un factor considerable. Algunos proveedores permiten ciertos trucos pero, en general, el mantenimiento del sw de backup, es un coste muy elevado.

Yup, eso es lo que mencionaba en mi correo anterior. El SW de backup es muy caro (prohibitivo). La rentabilidad me referia a HW. Es mas, es la principal razon por la que personalmente huiria de cinta: no tener que pagar los precios de los proveedores de SW de backup ;)

- El coste de la cinta puede parecer bajo frente al disco, pero cuando incluyes otros factores: - mantenimiento de las librerías (las grandes) y un montón de drives, el OPEX empieza a subir.

Esto no lo hemos visto nosotros y tenemos la T-Finity (20 PB) y la T-950 (5 PB). De hecho, una vez configuradas ... ahi estan. Lo unico que hicimos fue cambiar de LTO-6 a LTO-7 cuando estuvo disponible. Tarde unas 4 horas: comprobar firmwar, sacar fisicamente los drives LTO-6 y meter los nuevos, arrancar y seguir currando. El coste de consumo (incluyendo la refrigeracion) en cinta es mucho menor que en disco a mismo volumen de datos (incluso discos MAID). Lo digo porque tenemos 17 PB en Lustre y casi 3 PB en GPFS frente a los 25 PB de cinta. y mas de 500 TB en Ibrix. Otros sistemas de ficheros que hay por aqui son ZFS y BeeGFS. Es mas, hemos tenido muchos mas problemas con los discos que con las cintas, incluyendo perdida de datos: en uno de los casos los dos discos de un mismo RAID 1 de los metadatos se estropearon: adios metadatos ... adios datos. Esto era un GPFS. Discos andamos cambiando todas las semanas. Por si alguien tiene curiosidad, esto es lo que tenemos: Ibrix en servidores y almacenamiento HPE GPFS en DDN ZFS y BeeGFS en Supermicro No quiere decir que las cintas sean perfectas. Un cliente que tuve en ES tuvo una cinta atascada en un drive la primera semana (IIRC). Las cintas hay que tensarlas correctamente, hay que limpiar los cabezales, ... de lo contrario puedes tener problemas. En el caso de SpectraLogic, el firmware realiza muchas mas comprobaciones que otros fabricantes. Y todo el rollo de tensar cintas y limpiar cabezales lo tienen muy automatizado :)

- el coste operativo de manejar cintas, externalizarlas, etc. no se suele tener en cuenta... y es elevado.

En nuestro caso tenemos edificio para eso (un edificio de respaldo dentro del Campus). El que tenga que llevar las cintas a una caja fuerte y alquilar/comprar un local para eso, es otro gasto que tiene que tener en cuenta.

- el coste operativo de migrar las cintas cada una o, incluso, dos generaciones es enorme. La misma operativa sobre disco es muuuucho más sencilla y rápida.

En disco es mucho mas sencillo, especialmente si utilizas sistemas de ficheros modernos (SDS). En el caso de cinta, no es algo que hagas todos los dias. Migramos de una librerias de IBM antigua a la nueva y fue cosa de paciencia mientras se copiaban los datos. Sip, de disco a disco hubiese sido mas rapido. Pero esto era archivado asi que tampoco habia mucha prisa :) Cuando migramos de LTO-6 a 7 tampoco fue mucho curro, mas bien paciencia. No lo hice yo asi que no puedo dar detalls 0:)

... pierde esa ventaja.

Además, hay un coste que no se suele incluir: el error silencioso. Ocurre que, muy de vez en cuando, una drive puede guardar mal un dato en la cinta, o el dato 'pudrirse' en la cinta... y no hay forma de saberlo hasta que necesitas ese dato; entonces suele ser demasiado tarde.

Esto lo tienes con discos tambien: silent data crruption. Depende del sistema de ficheros que uses el que se pueda solucionar. RAID no ayuda porque te comprueba la paridad al escribir, pero no al leer de nuevo el dato. El bit flip puede ocurrir una vez que el dato ya se haya escrito y hay pasado un tiempo. ZFS y XFS, por ejemplo, te hacen un CRC (ZFS hace mas comprobaciones). GPFS tambien protege contra esto (ahora no me acuerdo como). RAID tampoco sabe si de RAM a disco el bit ha cambiado (ZFS si lo comprueba, XFS no).

Un disco, en cambio, suele ir protegido con RAID y las controladoras hacen un trabajo excelente controlando estas cosas y, en muchos casos, el sw de backup puede ejecutar tareas periódicas adicionales de comprobación de integridad con costes operativos muy bajos (no hay que andar montando y desmontando cintas que - aún de forma automática - es un proceso costoso en tiempo).

El disco tiene otro problema: las caches del propio disco. Los discos sufren microcortes de electricidad y pierden datos de la cache (mas habitual de lo que nos imaginamos). En mi epoca en SGI ya recomendabamos a los clientes deshabilitar la cache del propio deisco debido a su baja fiabilidad. El RAID que conocemos a dia de hoy es poco eficiente porque: - los discos son demasiado grandes. Una regla "aceptada" es que 1 disco de 1 TB SATA en RAID 5/6 te tarda 24 horas en recostruir (mas o menos). Teniendo en cuenta que tenemos discos de 10 TB ... Es muy grande el tiempo de reconstruccion. - el volumen de datos que se maneja es brutal - mientras reconstruye, se pierde rendimiento del almacenamiento Es mucho mejor utilizar un SDS en el que se utilizan Erasure Codes ya que: - solo se reconstruyen los bits afectados (RAID te reconstruye el disco entero, por eso tarda tanto) - en la reconstruccion intervienen todos los discos por lo que el rendimiento "no cae" (es despreciable) - puedes aplicar diferentes niveles de proteccion individualmente a cada fichero y directorio en el mismo sistema de ficheros. Por ejemplo, el directorio small_files puede tener un mirror (RAID1) mientras que el directorio big_files puede tener una proteccion N+4 (similar a RAID5, pero con 4 discos de paridad) y todo en el mismo sistema de ficheros. Con RAID tradicional, tienes que montar sistemas de ficheros diferentes en diferentes RAID (bueno, con LVM lo puedes trampear, pero no controlas donde se colocan los ficheros) - puedes crecer y decrecer el sistema de ficheros sin parada (en RAID por HW y LVM tambien lo puedes hacer) con un simple comando (a lo mejor dos ;) No pretendo defender la cinta "a capa y espada", creo que cada uno tiene su utilidad.

Finalmente, en cuanto a rendimiento: Realmente las cintas no son malas en cuanto a lecturas o escrituras *secuenciales*; cualquier cosa que no sea eso el rendimiento se reduce muchísimo... más o menos igual que un disco. Las operaciones de escritura de datos deduplicados tienen rendimientos aceptables... al contrario que la recuperación de datos... el rendimiento de 'rehidratación' no es brillante, siendo generosos :-)

Estoy de acuerdo, cintas tienen buen ancho de banda si es secuencial, como hagas I/O aleatoria ... estas perdido, especialmente si tienes que saltar de cinta a cinta.

En esta organización hemos dejado la cinta para aquellas situaciones en que doble copia a disco (una local, otra remota) no es posible por razones de línea de comunicación o legales (no es posible enviar datos fuera de ciertos países).

Ufff ... los temas legales son de lo mas entretenido ;) En temas de comunicacion (bajo ancho de banda y gran volumen de datos), podria ser interesante el tema de SDS. Algunos sistemas de ficheros te permiten delimitar copias o datos a una zona geografica determinada. Ceph (IIRC) te permitia algo por el estilo. MHO Rafa -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

On 2017-05-22 09:47, miguel gmail wrote:

Buenas,

...

...

...

Actualmente LTO7. Yo prefiero LTO porque es un estándar. El de IBM es tecnológicamente mejor ... pero sólo de IBM.

Hay que distinguir varias cosas.

- la capacidad de las las cintas de 15 TB no dependen del fabricante, sino de la densidad de la cinta y de la longitud de ésta. Las densidades de las cintas de 15 TB son posibles gracias a un material relativamente reciente basado en Ferritas de Bario (BaFe): https://en.wikipedia.org/wiki/Barium_ferrite

Antes se usaban de 'Metal Particles' (MP). La diferencia es la forma que adoptan las partículas que se orientan a los campos magnéticos.

Es cierto que, además, influye el algoritmo de compresión que use cada drive... IBM promete 3x en sus TS, LTO 2,5x... no recuerdo cuánto promete STK (luego Sun, ahora Oracle) en sus T10000.

Los 15 TB de IBM son sin compresión. La capacidad citada de los LTO es (dicen) con compresión. ...

Además, hay un coste que no se suele incluir: el error silencioso. Ocurre que, muy de vez en cuando, una drive puede guardar mal un dato en la cinta, o el dato 'pudrirse' en la cinta... y no hay forma de saberlo hasta que necesitas ese dato; entonces suele ser demasiado tarde.

¡vaya! Llevo mucho tiempo diciendo que en Linux no he visto archivadores o programas de backup que tengan "forward error recovery" incluido. Por ejemplo, el tar.gz que se usa con tanta frecuencia es vulnerable. El dar lo es menos. Pero el rar (comercial) sí lo tiene. Pero no trata bien los atributos de los ficheros Linux. En cuanto a lo que hagan las aplicaciones de backup comerciales en Linux, pues lo desconozco. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" (Minas Tirith))

Buenas,

Agree en todo :)

:'-)

No me referia tanto a soporte o mantenimiento sino a la posibilidad de tener mas fabricantes (IIRC, LTO tiene 3 fabricantes) o competencia ... aunque ya sabemos como funciona con solo 3 fabricantes: se ponen de acuerdo y punto.

Tambien porque es un estandar abierto.

A mí, es que eso de abierto no sé qué significa en este contexto. Cuántos fabricantes pueden usar y construir LTO? Pero sí, oye, que sea abierto no es malo.

No se utilizarian para "trabajar" (en plan LTFS) sino para Archivado y HSM/ILM en el mundo de HPC. Para este tipo de cosas no requieres una gran velocidad ni baja latencia sino volumen bruto. Aunque algunos fabricantes tienen buenas "bestias", como SpectraLogic con su T-Finity y su T950 (nosotros tenemos ambos modelos) que te permiten buen ancho de banda.

El cientifico/ingeniero acaba un proyecto y se manda todo a cinta para dejar espacio libre en disco. El dato archivado o en HSM se utiliza muy rara vez.

Ah, eso. Sí, lo que yo llamo archivado profundo. Justo ese caso de uso. Trabajo para una organización de esas (de esas que generan ficheros cuyo tamaño individual es de varios TB). El reto es convencer a los ingenieros implantar una política de ILM. Lo guardan todo, son como diógenes... o peor. Van pasando el dato de un sitio a otro sin borrarlo de ningún sitio.

...

- El coste de la cinta puede parecer bajo frente al disco, pero cuando incluyes otros factores: - mantenimiento de las librerías (las grandes) y un montón de drives, el OPEX empieza a subir.

Esto no lo hemos visto nosotros y tenemos la T-Finity (20 PB) y la T-950 (5 PB). De hecho, una vez configuradas ... ahi estan. Lo unico que hicimos fue cambiar de LTO-6 a LTO-7 cuando estuvo disponible. Tarde unas 4 horas: comprobar firmwar, sacar fisicamente los drives LTO-6 y meter los nuevos, arrancar y seguir currando.

Uhm... Sí, esto sí es 'fácil'. El asunto es que LTOn puede leer escribir en la generación 'n' y 'n-1', y solo leer de la 'n-2'. Lo normal es que las cintas 'n-2' vayan siendo migradas a generación 'n'. Esto, en una infraestructura con cientos de cintas... uhm... :-)

El coste de consumo (incluyendo la refrigeracion) en cinta es mucho menor que en disco a mismo volumen de datos (incluso discos MAID). Lo digo porque tenemos 17 PB en Lustre y casi 3 PB en GPFS frente a los 25 PB de cinta. y mas de 500 TB en Ibrix. Otros sistemas de ficheros que hay por aqui son ZFS y BeeGFS.

Sin duda. Es un coste a tener en cuenta. En este caso, además, este tipo de datos deduplica fatal, con lo que la ventaja de la dedup frente a la compresión se pierde.

Es mas, hemos tenido muchos mas problemas con los discos que con las cintas, incluyendo perdida de datos: en uno de los casos los dos discos de un mismo RAID 1 de los metadatos se estropearon: adios metadatos ... adios datos. Esto era un GPFS. Discos andamos cambiando todas las semanas.

Absolutamente normal lo de cambiar discos. (lo siento, no me sale nada por IIRC más allá de https://en.wikipedia.org/wiki/IIRC)

Por si alguien tiene curiosidad, esto es lo que tenemos: Ibrix en servidores y almacenamiento HPE

¿3PAR?

GPFS en DDN ZFS y BeeGFS en Supermicro

Interesante lo de Supermicro. Cuantas CPUs? Compráis soporte?

No quiere decir que las cintas sean perfectas. Un cliente que tuve en ES tuvo una cinta atascada en un drive la primera semana (IIRC). Las cintas hay que tensarlas correctamente, hay que limpiar los cabezales, ... de lo contrario puedes tener problemas.

En el caso de SpectraLogic, el firmware realiza muchas mas comprobaciones que otros fabricantes. Y todo el rollo de tensar cintas y limpiar cabezales lo tienen muy automatizado :)

Lo poquito que me han contado del mundo de fabricantes es que... no son exactamente las mismas librerías las Scalar y Spectra que luego venden a los IBM, HPE, etc?

...

- el coste operativo de manejar cintas, externalizarlas, etc. no se suele tener en cuenta... y es elevado.

En nuestro caso tenemos edificio para eso (un edificio de respaldo dentro del Campus). El que tenga que llevar las cintas a una caja fuerte y alquilar/comprar un local para eso, es otro gasto que tiene que tener en cuenta.

Hablamos de Enterprise, claro.

...

- el coste operativo de migrar las cintas cada una o, incluso, dos generaciones es enorme. La misma operativa sobre disco es muuuucho más sencilla y rápida.

En disco es mucho mas sencillo, especialmente si utilizas sistemas de ficheros modernos (SDS). En el caso de cinta, no es algo que hagas todos los dias. Migramos de una librerias de IBM antigua a la nueva y fue cosa de paciencia mientras se copiaban los datos. Sip, de disco a disco hubiese sido mas rapido. Pero esto era archivado asi que tampoco habia mucha prisa :)

Cuando migramos de LTO-6 a 7 tampoco fue mucho curro, mas bien paciencia. No lo hice yo asi que no puedo dar detalls 0:)

Es un proceso que compite contra: - operaciones de backup: si los drives están ocupados haciendo backup toca esperar. - operaciones de restore: se suelen configurar los restores con la máxima prioridad, así que si hay un restores se paran hasta los backups, ni te cuento las migraciones :-)

Esto lo tienes con discos tambien: silent data crruption. Depende del sistema de ficheros que uses el que se pueda solucionar. RAID no ayuda porque te comprueba la paridad al escribir, pero no al leer de nuevo el dato. El bit flip puede ocurrir una vez que el dato ya se haya escrito y hay pasado un tiempo.

Uhm, esto no lo he conocido... Interesante.

El disco tiene otro problema: las caches del propio disco. Los discos sufren microcortes de electricidad y pierden datos de la cache (mas habitual de lo que nos imaginamos). En mi epoca en SGI ya recomendabamos a los clientes deshabilitar la cache del propio deisco debido a su baja fiabilidad.

Y cuáles son los efectos de esto? Lo digo porque no observo yo esas corrupciones habitualmente :-?

El RAID que conocemos a dia de hoy es poco eficiente porque: - los discos son demasiado grandes. Una regla "aceptada" es que 1 disco de 1 TB SATA en RAID 5/6 te tarda 24 horas en recostruir (mas o menos). Teniendo en cuenta que tenemos discos de 10 TB ... Es muy grande el tiempo de reconstruccion. - el volumen de datos que se maneja es brutal - mientras reconstruye, se pierde rendimiento del almacenamiento

El RAID era una cosa estupenda hasta que los sistemas de almacenamiento han escalado tanto que ocurre lo que dices. Hay que inventarse otra cosa. Oh, wait!

Es mucho mejor utilizar un SDS en el que se utilizan Erasure Codes ya que: - solo se reconstruyen los bits afectados (RAID te reconstruye el disco entero, por eso tarda tanto) - en la reconstruccion intervienen todos los discos por lo que el rendimiento "no cae" (es despreciable) - puedes aplicar diferentes niveles de proteccion individualmente a cada fichero y directorio en el mismo sistema de ficheros. Por ejemplo, el directorio small_files puede tener un mirror (RAID1) mientras que el directorio big_files puede tener una proteccion N+4 (similar a RAID5, pero con 4 discos de paridad) y todo en el mismo sistema de ficheros. Con RAID tradicional, tienes que montar sistemas de ficheros diferentes en diferentes RAID (bueno, con LVM lo puedes trampear, pero no controlas donde se colocan los ficheros) - puedes crecer y decrecer el sistema de ficheros sin parada (en RAID por HW y LVM tambien lo puedes hacer) con un simple comando (a lo mejor dos ;)

No pretendo defender la cinta "a capa y espada", creo que cada uno tiene su utilidad.

Erasure Coding es una cosa estupenda :-) Y es lo que usan las soluciones de object storage (swift si os gusta open source, S3 para el estándar de facto...).

...

Finalmente, en cuanto a rendimiento: Realmente las cintas no son malas en cuanto a lecturas o escrituras *secuenciales*; cualquier cosa que no sea eso el rendimiento se reduce muchísimo... más o menos igual que un disco. Las operaciones de escritura de datos deduplicados tienen rendimientos aceptables... al contrario que la recuperación de datos... el rendimiento de 'rehidratación' no es brillante, siendo generosos :-)

Estoy de acuerdo, cintas tienen buen ancho de banda si es secuencial, como hagas I/O aleatoria ... estas perdido, especialmente si tienes que saltar de cinta a cinta.

--> La muerte (pero lenta, claro).

En temas de comunicacion (bajo ancho de banda y gran volumen de datos), podria ser interesante el tema de SDS. Algunos sistemas de ficheros te permiten delimitar copias o datos a una zona geografica determinada. Ceph (IIRC) te permitia algo por el estilo.

Sí, es estupendo. -- Saludos, miguel Los agujeros negros son lugares donde dios dividió por cero. Black holes are places where god divided by zero. Steven Wright -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

Wenas :) 2017-05-22 15:29 GMT+03:00 Carlos E. R. :

On 2017-05-22 10:10, Rafa Griman wrote:

...

Wenas :)

2017-05-21 22:36 GMT+03:00 Carlos E. R. <>:

...

...

Yo hago un simple rsync.

Para mi casa, yo tambien :)

Para PYMES, algo en plan Bacula puede ser mas util por tema de precio y porque te permite recuperar copias por fecha. Con rsync tambien tienes scripts ya hechos que te permiten hacer un tipo de copiado incremental. Nunca los he probado (que yo recuerde), pero me han dicho que funcionan bastante bien.

Sí, hay scripts que te lo gestionan, pero también lo puedes hacer directamente con rsync. Le dices que haga un backup nuevo y le das también la dirección (path) del backup antiguo, que tiene que estar en la misma partición. Lo que hace es crear hardlinks a la versión antigua de cada fichero que no cambie, y copia nueva para los que hayan cambiado.

Es lo que estoy haciendo yo.

Hay otros métodos: por ejemplo, rdiff-backup convierte las versiones antiguas en rdiffs (reverse-rdiffs). El ultimo backup es un espejo. la ventaja es que se ahorra sitio, y supongo que se pueden emplear varios discos (no lo he comprobado).

Ese es !! rdiff-backup, me han hablado muy bien de esta herramienta, pero nunca la he probado. Gracias por el refresco de memoria ;) Rafa -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

...

Interesante lo de Supermicro. Cuantas CPUs? Compráis soporte?

Lo de SuperMicro son unas bestias que tenemos que encadenar al suelo porque llevan 24 discos NVMe ... Espera que se me cae la baba ... Para que te hagas una idea: un compi decidio hacer un "benchmark" con 80 mil ficheros en no se cuantos directorios y subdirectorios. Decidio hacer un ls -lR /mnt/nvme /mnt/ssd. Mismo numero de discos SSD y NMVe, en el mismo servidor y exportando por NFS. Tenia 2 terminales abiertas: en una tecleaba ls -lR /mnt/nvme o bien ls -lR /mnt/ssd pinchaba en la otra terminal y tecleaba iotop*

Pues con los NVMe no le daba tiempo a pincha en la otra terminal. Instantaneo. Se me ponen los pelos de punta solo de pensarlo. Al compi los SSD le parecen lentos y anticuados xD xD xD

Normal. Yo tb soy fan de NVMe, es lo que hay que poner para usar flash como está mandado. (por cierto, me acuerdo cuando pasamos de IDE a SAS porque el acceso serie era muuuucho mejor que el paralelo... xD)

Si quieres te paso datos tecnicos con mas detalle del bicho este.

Nah, deja, p'a qué sufrir.

El drive es el mismo, lo que ocurre es que los fabricantes luego tienen permiso (o no) para modificar el firmware. En el caso de SpectraLogic, aumentan el numero de cosas que monitorizan para mejorar la fiabilidad.

Preguntaba porque vamos a montar unas librerías pequeñas de Quantum... y alguien decía que son las mismas que las de IBM y, por tanto, scripteables. No sé si serán TAN iguales.

...

...

Esto lo tienes con discos tambien: silent data crruption. Depende del sistema de ficheros que uses el que se pueda solucionar. RAID no ayuda porque te comprueba la paridad al escribir, pero no al leer de nuevo el dato. El bit flip puede ocurrir una vez que el dato ya se haya escrito y hay pasado un tiempo.

Uhm, esto no lo he conocido... Interesante.

https://en.wikipedia.org/wiki/Data_corruption#SILENT

http://changelog.complete.org/archives/9769-silent-data-corruption-is-real

Cuento del abuelo cebolleta. Organización pública importante. El dato tiene la siguientes copias: - copia de producción. - copia síncrona - copia asíncrona - copia de backup en cinta (SL8500, drives 9940B) - copia de segundo backup en cinta (SL8500, drives 9940B) Se corrompe/borra (no me acuerdo) algo en producción. La réplica síncrona no la tiene. La asíncrona tampoco. No pasa nada, vayamos al backup. Primera copia de backup... cinta jodida. <tragar saliva muy fuerte> Segunda copia de backup... sí, esa sí. <suspiros profundos de alivio>

Perdida de datos. Yo no lo he visto, desde hace 12 anos deshabilito siempre las caches de los discos (las controladoras RAID de LSI lo hacen automaticamente si quieres y con hdparm tambien lo puedes hacer).

Preguntaré por aquí, a ver qué hacen con eso.

Creo recordar (tendria que repasar la documentacion de ZFS), que cuando usas ZFS te recomiendan que tambien deshabilites la cocahe de la controladora RAID (configurar la controladora en modo write-through en lugar de write-back). Lo hacen porque ZFS utiliza la RAM como cache, por eso recomiendan ECC RAM.

[...]

Para ciertos casos de uso he propuesto ZFS, pero ni caso. Y nos vendría muy bien para sustituir las NASes de Netapp (snaps + réplicas). Montaríamos lo que llamamos nuestras 'monster VM' con linux con ZFS para exportar NFS... pero ná, no queremos nada con Oracle, y aquí no podemos vivir sin soporte oficial.

Bueno que lo confirmes. Usas Ceph (u otro SDS) para Geoclustering? Por saber que tal funciona, nunca lo he usado.

No, nuestra solución es algo más... propietario. EMC ECS. Y no estoy nada contento con sus funcionalidades. -- Saludos, miguel Los agujeros negros son lugares donde dios dividió por cero. Black holes are places where god divided by zero. Steven Wright -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

Wenas :) 2017-05-23 17:13 GMT+03:00 miguel gmail :

...

...

Interesante lo de Supermicro. Cuantas CPUs? Compráis soporte?

Se me olvidó contestar a la pregunta de soporte. Nop, no compramos soporte, compramos piezas extra que tenemos guardadas en un cajón, además de mantenimiento a 3 años. Es que pedir una pieza de recambio se lleva una eternidad aquí así que preferimos tener piezas a mano :) [...]

(por cierto, me acuerdo cuando pasamos de IDE a SAS porque el acceso serie era muuuucho mejor que el paralelo... xD)

¡¡Qué tiempos!! Me acuerdo la primera vez que me compré un disco de 1 GB (IDE, claro) ... pensé: "No lo llenaré en la vida" ...

...

Si quieres te paso datos tecnicos con mas detalle del bicho este.

Nah, deja, p'a qué sufrir.

xD xD xD

...

El drive es el mismo, lo que ocurre es que los fabricantes luego tienen permiso (o no) para modificar el firmware. En el caso de SpectraLogic, aumentan el numero de cosas que monitorizan para mejorar la fiabilidad.

Preguntaba porque vamos a montar unas librerías pequeñas de Quantum... y alguien decía que son las mismas que las de IBM y, por tanto, scripteables. No sé si serán TAN iguales.

Ni idea, no he trabajado con Quantum 0:) [...]

Cuento del abuelo cebolleta.

<Sentado y con palomitas> :)

Organización pública importante. El dato tiene la siguientes copias:

- copia de producción. - copia síncrona - copia asíncrona - copia de backup en cinta (SL8500, drives 9940B) - copia de segundo backup en cinta (SL8500, drives 9940B)

Se corrompe/borra (no me acuerdo) algo en producción. La réplica síncrona no la tiene. La asíncrona tampoco.

No pasa nada, vayamos al backup.

Primera copia de backup... cinta jodida.

<tragar saliva muy fuerte>

Segunda copia de backup... sí, esa sí.

<suspiros profundos de alivio>

xD xD xD xD ... Perdona que me ría, pero es que me estaban cayendo las gotas de sudor frío. A mi lo que me ha pasado es que un servidor con 2 RAIDS (RAID1 para OS y RAID5 de 4 discos para datos) pierde los 4 discos del RAID 5 ... los 4 !! Y no hay backups :O Llaman al "valiente voluntario" (aka Rafa) y le dicen: "Oye que este servidor tiene un problema, échale un vistazo a ver qué le pasa" ... Cuando llego y veo los 4 discos con LED rojo pienso ... "vaya marrón me ha caído". Me pongo manos a la obra y consigo recuperar 2 discos, pero los ortos 2 ... rechinaban: cabezal tocando el platter como si fuera un DJ ... Mandamos los discos a una empresa de recuperación de datos y nos dijeron que no se podía hacer nada. Lo malo es que la cosa pasó de problema técnico a problema político a nivel de jefes ... Ahora el profesor nos odia (obviamente) porque ha perdido 3 años de datos. Al final todos se señalaban con el dedo y un misterio quién tenía que haberse encargado del servidor y las copias de seguridad. [...]

...

Creo recordar (tendria que repasar la documentacion de ZFS), que cuando usas ZFS te recomiendan que tambien deshabilites la cocahe de la controladora RAID (configurar la controladora en modo write-through en lugar de write-back). Lo hacen porque ZFS utiliza la RAM como cache, por eso recomiendan ECC RAM.

[...]

Para ciertos casos de uso he propuesto ZFS, pero ni caso. Y nos vendría muy bien para sustituir las NASes de Netapp (snaps + réplicas). Montaríamos lo que llamamos nuestras 'monster VM' con linux con ZFS para exportar NFS... pero ná, no queremos nada con Oracle, y aquí no podemos vivir sin soporte oficial.

Échale un vistazo a TrueNAS de ixSystems. Es similar a un NetApp y cuesta la tercera parte. Pedí presupuesto y NetApp era $1 millón y estos $300 mil ... sin descuento para Educación !!! Al ser cuenta nueva, educación, ... me hacían un descuento del carajo !!! En el presupuesto me ponían el mismo volumen de datos neto, soporte 24x7 remoto (Gold o algo así) y no sé cuántas cosas más. Te puedo pasar contacto. Muy majetes. Está basado en FreeBSD con ZFS, son los que desarrollan FreeNAS.

...

Bueno que lo confirmes. Usas Ceph (u otro SDS) para Geoclustering? Por saber que tal funciona, nunca lo he usado.

No, nuestra solución es algo más... propietario. EMC ECS. Y no estoy nada contento con sus funcionalidades.

OK. De EMC conozco Isilon, me parece muy bueno, pero muy caro ... Rafa -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

On 2017-05-23 20:19, Rafa Griman wrote:

Wenas :)

¡¡Qué tiempos!! Me acuerdo la primera vez que me compré un disco de 1 GB (IDE, claro) ... pensé: "No lo llenaré en la vida" ...

Yo dije lo mismo con mi primer disco duro. Tenía 32 megas.

Cuando llego y veo los 4 discos con LED rojo pienso ... "vaya marrón me ha caído". Me pongo manos a la obra y consigo recuperar 2 discos, pero los ortos 2 ... rechinaban: cabezal tocando el platter como si fuera un DJ ... Mandamos los discos a una empresa de recuperación de datos y nos dijeron que no se podía hacer nada.

Lo malo es que la cosa pasó de problema técnico a problema político a nivel de jefes ... Ahora el profesor nos odia (obviamente) porque ha perdido 3 años de datos. Al final todos se señalaban con el dedo y un misterio quién tenía que haberse encargado del servidor y las copias de seguridad.

¿Y luego te extrañas que tengan veinte copias por ahí que ni saben que están? :-P para una vez que les hace falta... Yo empecé un proyecto para encontrar duplicados de ficheros por todo el arbol, comparando los checksums. Pero lo tengo parado. Mi ilusión era una vez encontrados ofrecer crear symlinks o hardisks. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" (Minas Tirith))

...

...

Cuando llego y veo los 4 discos con LED rojo pienso ... "vaya marrón me ha caído". Me pongo manos a la obra y consigo recuperar 2 discos, pero los ortos 2 ... rechinaban: cabezal tocando el platter como si fuera un DJ ... Mandamos los discos a una empresa de recuperación de datos y nos dijeron que no se podía hacer nada.

Lo malo es que la cosa pasó de problema técnico a problema político a nivel de jefes ... Ahora el profesor nos odia (obviamente) porque ha perdido 3 años de datos. Al final todos se señalaban con el dedo y un misterio quién tenía que haberse encargado del servidor y las copias de seguridad.

¿Y luego te extrañas que tengan veinte copias por ahí que ni saben que están? :-P

No, de hecho la chica tiene copias por todos lados ahora :) Lo malo de eso es que luego no saben cual es la copia "buena" :(

Lo que me da rabia es que en vez de intentar ayudar al usuario, se estuvieron senalando con el dedo unos a otros >:-|

...

para una vez que les hace falta...

Ya. La historia me suena. Mucho. Yo cortaría cabezas por hacer esas copias fuera de la política de backup. Mi enfoque es: 1. definir una política de backup con varios sabores (por favor, no más de cinco, como mucho). Lo de doble copia de backup debería ser obligatorio. Abarcar todo el conjunto de datos que lo requiera (ficheros planos, bases de datos, aplicaciones rarunas, etc.). Lo de disco o cinta... depende de presupuesto, ventana de backup, volumen a proteger, etc. 2. asignar (estimar) costes a cada política. 3. comunicar la política y dejar que cada aplicación elija su sabor. Dicha política puede estar definida en términos de RPO, RTO, VRO y GRO (por ejemplo) y explicitar los límites del servicio de backup. 4. imputar mensualmente el coste de ese backup. Al que se salga de la política... palo. Y sí, a veces hay que hacer ajustes... lo típico del DBA que decide que se hace su copia local de un export que destroza la dedup porque cambia un bit... Se puede llegar a acuerdos y excluir cierto tipo de ficheros, pero no se puede permitir que los usuarios saquen sus copias de backup por su cuenta y riesgo. Si ocurre algún tipo de desgracia que haga irrecuperable un dato... mala suerte. La protección infinita tiene un coste infinito (o muuuy elevado, inasumible, pero improbable). Y punto. -- Saludos, miguel Los agujeros negros son lugares donde dios dividió por cero. Black holes are places where god divided by zero. Steven Wright -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

On 2017-05-24 15:48, miguel gmail wrote:

Ya. La historia me suena. Mucho.

Yo cortaría cabezas por hacer esas copias fuera de la política de backup.

Mi enfoque es: 1. definir una política de backup con varios sabores (por favor, no más de cinco, como mucho). Lo de doble copia de backup debería ser obligatorio. Abarcar todo el conjunto de datos que lo requiera (ficheros planos, bases de datos, aplicaciones rarunas, etc.). Lo de disco o cinta... depende de presupuesto, ventana de backup, volumen a proteger, etc. 2. asignar (estimar) costes a cada política. 3. comunicar la política y dejar que cada aplicación elija su sabor. Dicha política puede estar definida en términos de RPO, RTO, VRO y GRO (por ejemplo) y explicitar los límites del servicio de backup. 4. imputar mensualmente el coste de ese backup.

Al que se salga de la política... palo.

Y sí, a veces hay que hacer ajustes... lo típico del DBA que decide que se hace su copia local de un export que destroza la dedup porque cambia un bit... Se puede llegar a acuerdos y excluir cierto tipo de ficheros, pero no se puede permitir que los usuarios saquen sus copias de backup por su cuenta y riesgo.

¿porqué no? :-? Que ellos saquen sus propias copias de lo que consideran muy importante no fastidia la copia de seguridad general. Salvo que lo hagan a un disco que también se salvaguarda, duplicando el espacio de copia. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" (Minas Tirith))

On 2017-05-24 15:49, miguel gmail wrote:

...

Eso es muy peculiar, porque la teoría dice que tiene que ser lo contrario. Lo cual quiere decir que es más rápido porque la circuitería (todo: chips, cables, enchufes) es mejor. Aplicando las mismas técnicas al paralelo debería ser mucho más rápido.

Ahora bien, si podemos conseguir esas velocidades con cableado serie pues mejor, porque el cableado es más sencillo.

Mejor aún, en NVMe no hay cableado :-)

A ver a ver, que me has dejado pasmado. A ver, wikipedia... [...] Huh, tengo que leerlo más despacio, que es madrugada y estoy cansado y no me entero. ¿Ese chisme se conecta al bus PCIe directamente, teniendo por tanto un bus de direcciones completo, y otro de datos? A ver, entonces lo que tienes es un "cableado" paralelo masivo, como la RAM. Tiempo de "acceso" casi nulo. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" (Minas Tirith))

Hola :) 2017-05-25 2:22 GMT+03:00 Carlos E. R. :

On 2017-05-24 15:02, Rafa Griman wrote:

...

Hola :)

2017-05-24 2:50 GMT+03:00 Carlos E. R. :

...

On 2017-05-23 20:19, Rafa Griman wrote:

...

...

¡¡Qué tiempos!! Me acuerdo la primera vez que me compré un disco de 1 GB (IDE, claro) ... pensé: "No lo llenaré en la vida" ...

Yo dije lo mismo con mi primer disco duro.

Tenía 32 megas.

:O

No te rias tanto X-)

Mi ordenador era un Amstrad PC con dos flopies de 360 KB. 32 megas era una barbaridad: un amigo tenía 10, y se hablaban de los de 20 como en sueños. Uno de 32 ni te cuento: se decia que el MsDOS no soportaba tanto. No recuerdo lo que hice inicialmente, pero al final se quedó con dos particiones, la segunda comprimida. Una cosa que Linux todavía no sabe hacer.

Buenos tiempos, yo tenia un Spectrum ... Si usas ZFS, te comprime :) Esta bien porque ZFS te comprime ... y te permite hacer multiples copias del fichero (en el mismo sistema de ficheros), como si fuera un RAID1 automatico a nivel de ficheros 8) La verdad es que ZFS esta muy bien. [...]

...

...

¿Y luego te extrañas que tengan veinte copias por ahí que ni saben que están? :-P

No, de hecho la chica tiene copias por todos lados ahora :) Lo malo de eso es que luego no saben cual es la copia "buena" :(

Juas. Eso me pasa a mi a veces.

Yo ya lo tengo bajo control: version original en un disco y las copias 2 y 3 en discos separados :) [...]

...

Al final la chica pudo reconstruir sus datos a base de correos, ficheros por aqui y por alli, lanzar simulaciones de nuevo, ...

Buf.

Yup, y encima es su Doctorado ...

...

...

Yo empecé un proyecto para encontrar duplicados de ficheros por todo el arbol, comparando los checksums. Pero lo tengo parado. Mi ilusión era una vez encontrados ofrecer crear symlinks o hardisks.

fdupes ;) Funciona de maravilla. Bueno, no hace lo de ofrecer crear los symlinks o hardlinks.

No recuerdo porqué, pero no me vale.

Es que el objeto es hacer limpieza, no sólo encontrarlos. Y además con ventanitas browser de ficheros, que me quedé parado tratando de elegir alguna librería para ello. Ah, y hecho en Pascal (Lazarus).

:O Eso ya son palabras mayores, el fdupes es muy simplon ... pero muy util si buscas ficheros duplicados. Tambien te permite automatizar el borrado de los ficheros duplicados, pero ... eso prefiero que sea "amanuense" ;) Rafa -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

On 2017-05-25 10:54, miguel gmail wrote:

...

...

Al que se salga de la política... palo.

Y sí, a veces hay que hacer ajustes... lo típico del DBA que decide que se hace su copia local de un export que destroza la dedup porque cambia un bit... Se puede llegar a acuerdos y excluir cierto tipo de ficheros, pero no se puede permitir que los usuarios saquen sus copias de backup por su cuenta y riesgo.

¿porqué no? :-?

Por, fundamentalmente, dos razones:

1. Coste. El backup cuesta dinero: licencias, espacio en disco, gestión, , riesgos de robo de información (no dejan de ser copias no controladas de datos), tiempo de gestión...

A ver. Si yo hago una copia de mis datos en un stick, eso no altera el coste del backup en nada. Lo de robo de información, es una posibilidad, sí. Para eso nos dan cajones con llave. Pero esa práctica viene de que en muchos sitios no se hace copia de seguridad. En ninguno de los sitios donde he estado, algunos corporativos, se hacían copias de seguridad alguna, excepto si las hacía yo por mi cuenta. Yo he perdido una base de datos de clientes en empresa gorda y no había copia de seguridad alguna. A partir de entonces hicimos nuestras propias copias, creando un zip de nuestro ordenador y guardándolo en el PC de al lado, y él otro en el nuestro. Programado como tarea programada (equivalente windows de cron). Cuando en una empresa gorda me dieron un portátil, tenía que hacerme mi propio backup en mi casa con mi dinero, porque ellos nada de nada.

Hazte idea: 1 TB de datos de producción puede tener otro TB en réplica. Y según qué política de backup tengas, considerando ratio de dedup, etc., puedes tener otro TB (o más!!) por cada copia de backup que hagas. Estos datos que te doy no son imaginados, son datos que yo he medido en dos organizaciones 'grandes' (no 'web scale', pero sí 'multi PB').

Un TB de datos genera más del triple de volumen ocupado. Y a eso quieres añadir 'más copias por si acaso'... y raro es el que hace limpieza de sus copias antiguas, etc. etc.

Y, además, no están catalogadas en ningun inventario.

A ver, si yo pierdo un fichero, ¿cuanto tardáis en darme una copia antigua? En los sitios donde yo he estado, *nunca*.

...

Que ellos saquen sus propias copias de lo que consideran muy importante no fastidia la copia de seguridad general. Salvo que lo hagan a un disco que también se salvaguarda, duplicando el espacio de copia.

Uhm.

A ver, esto hay que discutirlo: Qué significan datos 'muy importantes'. Importantes para quién o para qué. En mi experiencia, estas copias están solo para comodidad del administrador del servidor/bbdd/etc., porque un restore le consume más tiempo que usar lo que tiene al lado.

Y no. Las políticas de backup no se han (no se deben, 'quicir) decidir por capricho ni del responsable de backup, ni del proveedor... se deben decidir en base a un BIA (Business Impact Analysis). Si la solución de backup y política implementada no soluciona el BIA entonces hay que revisar o la tecnología, o los procedimientos o lo que sea, pero no solucionar un aparente problema por tu cuenta, con recursos caros.

O sea, que no hay copia de seguridad de mis cosas. Por ejemplo, la base de datos de clientes perdida, teniendo que meter lo que teníamos desde papel de nuevo. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" (Minas Tirith))

On 2017-05-25 09:17, Rafa Griman wrote:

Hola :)

2017-05-25 2:22 GMT+03:00 Carlos E. R. :

...

On 2017-05-24 15:02, Rafa Griman wrote:

...

Hola :)

2017-05-24 2:50 GMT+03:00 Carlos E. R. :

...

On 2017-05-23 20:19, Rafa Griman wrote:

...

...

¡¡Qué tiempos!! Me acuerdo la primera vez que me compré un disco de 1 GB (IDE, claro) ... pensé: "No lo llenaré en la vida" ...

Yo dije lo mismo con mi primer disco duro.

Tenía 32 megas.

:O

No te rias tanto X-)

Mi ordenador era un Amstrad PC con dos flopies de 360 KB. 32 megas era una barbaridad: un amigo tenía 10, y se hablaban de los de 20 como en sueños. Uno de 32 ni te cuento: se decia que el MsDOS no soportaba tanto. No recuerdo lo que hice inicialmente, pero al final se quedó con dos particiones, la segunda comprimida. Una cosa que Linux todavía no sabe hacer.

Buenos tiempos, yo tenia un Spectrum ...

Si usas ZFS, te comprime :) Esta bien porque ZFS te comprime ... y te permite hacer multiples copias del fichero (en el mismo sistema de ficheros), como si fuera un RAID1 automatico a nivel de ficheros 8) La verdad es que ZFS esta muy bien.

Creo que miré algo, pero no está en el kernel. O algo.

...

...

No, de hecho la chica tiene copias por todos lados ahora :) Lo malo de eso es que luego no saben cual es la copia "buena" :(

Juas. Eso me pasa a mi a veces.

Yo ya lo tengo bajo control: version original en un disco y las copias 2 y 3 en discos separados :)

Bueno, yo me refiero más bien a copias en otro path del sistema. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" (Minas Tirith))

...

Mejor aún, en NVMe no hay cableado :-)

A ver a ver, que me has dejado pasmado. A ver, wikipedia... [...] Huh, tengo que leerlo más despacio, que es madrugada y estoy cansado y no me entero. ¿Ese chisme se conecta al bus PCIe directamente, teniendo por tanto un bus de direcciones completo, y otro de datos? A ver, entonces lo que tienes es un "cableado" paralelo masivo, como la RAM. Tiempo de "acceso" casi nulo.

Sastamente. Las herramientas de monitorización no miden (o medían, ahora no sé cómo están) tiempos de respuesta por debajo de 1 ms... así que daban 0 cuando lanzabas una transacción. Espectacular. Es el tipo de disco que monta el Mac Pro, por cierto (ahora duda si es NVMe o solo PCIe) De hecho, esto no hace sino mejorar. Están a punto de llegar un tipo de memorias flash nuevas de Intel llamadas X-Point (Cross Point)... casi casi tan rápidas como la RAM por un coste casi de NAND. Estas memorias XPoint son lo siguiente en llegar... si os vais montar un PC y queréis que sea potente... esperad un par de años. -- Saludos, miguel Los agujeros negros son lugares donde dios dividió por cero. Black holes are places where god divided by zero. Steven Wright -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

...

1. Coste. El backup cuesta dinero: licencias, espacio en disco, gestión, , riesgos de robo de información (no dejan de ser copias no controladas de datos), tiempo de gestión...

A ver. Si yo hago una copia de mis datos en un stick, eso no altera el coste del backup en nada. Lo de robo de información, es una posibilidad, sí. Para eso nos dan cajones con llave.

Pero esa práctica viene de que en muchos sitios no se hace copia de seguridad. En ninguno de los sitios donde he estado, algunos corporativos, se hacían copias de seguridad alguna, excepto si las hacía yo por mi cuenta. Yo he perdido una base de datos de clientes en empresa gorda y no había copia de seguridad alguna.

A partir de entonces hicimos nuestras propias copias, creando un zip de nuestro ordenador y guardándolo en el PC de al lado, y él otro en el nuestro. Programado como tarea programada (equivalente windows de cron).

Cuando en una empresa gorda me dieron un portátil, tenía que hacerme mi propio backup en mi casa con mi dinero, porque ellos nada de nada.

Ah, hablas de tus datos de usuario (tu ofimática, para entendernos). Este es un caso distinto. Y es un problema absolutamente distinto tanto en gestión como en problemática. Lo que he podido ver es lo siguiente: 1. Organización 'búscate la vida'. La mayoría. 2. Organización: 'te pongo aquí una carpeta de red y pones ahí tus mierdas, y yo hago backup del share. Algo es algo, pero esto tiene agujeros. 3. Organización: 'sé cuánto valen tus datos y tu tiempo, voy a protegerlos como dios manda'. Las menos. Rara vez se calcula cuánto cuesta la pérdida de un portátil... más que el portátil, lo que se pierde es la información que hay ahí. Y no es solo perder el dato, es que no sabes ni quién lo tiene, ni para qué lo va a usar, y eso puede ser un riesgo 'reputacional' enorme. El portátil cuesta, vamos a decir, 1000€, pero el tiempo de recuperar los datos no se suele contabilizar... según el perfil (y el cargo/responsabilidad/perfil) del usuario puede subir la factura a mucho más de lo imaginado. El problema es que este tipo de datos no debe ser protegidos por herramientas de backup tradicionales (para entendernos, ni netbackup, ni TSM, ni...), porque, entre otras cosas, los restores requieren del administrador de la herramienta para recuperar un fichero; esto, en una organización grande, es una pérdida de tiempo lamentable. El enfoque suele ser elegir una herramienta que protega o bien un directorio: - la organización pide a sus usuarios que vuelquen toda la información a cierto directorio o se protege todo 'C:' y 'D:', por ejemplo. - se permite al usuario proteger los directorios que ellos decidan. Además, puede haber funcionalidades para proteger archivos de correo, etc. Las herramientas que hay en el mercado para backup de puesto de usuario tienen dos grandes ventajas (al menos las que yo elegiría): 1. Las recuperaciones son llevadas a cabo por el usuario (a veces el inglés mola, el término user-driven es perfecto), ahorrando tiempo y esfuerzo del administrador. Esto es un valor incalculable. 2. Pueden tener funcionalidades avanzadas de tipo 'dropbox corporativo': Sincronizar varios dispositivos (PC/portátil, smartphone, tablet), y compartir (mediante links), pero manteniendo el control de dato que se comparte (tanto OnPremise como el Cloud, con cifrado si es necesario) y, sobre todo, quién comparte qué. 3. También es interesante que tengan funcionalidades de cumplimiento regulatorio: permiten retener una copia de seguridad de todo fichero que haya sido protegido... esto a los departamentos legales les gusta o les aterra, según ;-) Este tipo de herramientas, si os interesan, se llaman EFSS (Enterprise File Sync & Share) con funcionalidades de backup (mantiene varias versiones de los ficheros y recupera de borrados accidentales). Molan mucho. Y sí, deberían usarse más :-)

...

Y no. Las políticas de backup no se han (no se deben, 'quicir) decidir por capricho ni del responsable de backup, ni del proveedor... se deben decidir en base a un BIA (Business Impact Analysis). Si la solución de backup y política implementada no soluciona el BIA entonces hay que revisar o la tecnología, o los procedimientos o lo que sea, pero no solucionar un aparente problema por tu cuenta, con recursos caros.

O sea, que no hay copia de seguridad de mis cosas. Por ejemplo, la base de datos de clientes perdida, teniendo que meter lo que teníamos desde papel de nuevo.

Eso no habría pasado el BIA más básico... de verdad me quieres decir que hay una bbdd de clientes en un excel en tu PC sin backup? De verdad una organización permite semejante riesgo?? En caso de pérdida de dicho fichero... cuánto puede sobrevivir esa organización? Espero que mi enfoque de backup específico de puesto de usuario cubra tus expectativas :-) -- Saludos, miguel Los agujeros negros son lugares donde dios dividió por cero. Black holes are places where god divided by zero. Steven Wright -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

Pero no sólo portátiles, sino equipos de sobremesa hechos y derechos.

Valen también para equipos de sobremesa, no hay limitación en este sentido. En los portátiles, este tipo de soluciones tienen la ventaja añadida de que saben, o pueden saber, qué tipo de red están usando (y eliminar gastos de roaming, por ejemplo), cifrado, deduplicación en origen... y un par de notas curiosas: geolocalización y, más importante, borrado remoto del equipo. Pero, como digo, estas herramientas se pueden implantar perfectamente en equipos de sobremesa.

...

El enfoque suele ser elegir una herramienta que protega o bien un directorio: - la organización pide a sus usuarios que vuelquen toda la información a cierto directorio o se protege todo 'C:' y 'D:', por ejemplo. - se permite al usuario proteger los directorios que ellos decidan.

Cosa que no sirve de nada con un wanacry.

Oh, sí que sirve :-) Muchas de estas soluciones, con el objeto de reducir costes, usan almacenamiento de objetos como repositorio de backup. Este repositorio puede estar tan OnPremise como en Cloud... Y, en cualquier caso: - usa otro tipo de estándares de comunicación, típicamente S3 (o SWIFT, para el caso). Hasta ahora, al menos, los ataques wanacry no han usado un vector basado en S3, sino en vulnerabilidades de SMB, por ejemplo. - más aún, incluso si son : los objetos pueden no modificarse por definición, sino que si se genera una nueva versión de un fichero, se genera un objeto complemtamente nuevo y dejar los objetos existentes como inmutables. Si el fichero es cifrado, generarás un objeto igualmente cifrado, pero es posible recuperar un objeto que represente/contenga la versión anterior del fichero cifrado. En cualquiera de estos casos, no hay pérdida de datos :-)

...

Y sí, deberían usarse más :-)

Pues no había nada.

Las cosas van mejorando. Hace 15 años tampoco había tecnología de replicación síncrona a 100 kms de distancia :-) Y las empresas van aprendiendo que el valor de lo que tienen es, con mucha frecuencia, superior al coste de protegerlo :-)

En una de las empresas en las que estuve, el portatil se podían grabar tus cosas en un directorio compartido de algún servidor. Ahora, estando donde el cliente pues era imposible, no había conectividad con nuestra sede. Un modem para el correo. Había que trasladarse fisicamente a nuestra sede y buscar una mesa con enchufe.

En la mía tenemos algo más pedrestre que lo que te he contado: un directorio que sincroniza ficheros contra un recurso de almacenamiento en nuestro CPD. No es perfecto, pero algo es algo (esto sí era susceptible de un wanacry). El único requisito es estar en la oficina o conectase con VPN (algo muy común y poco problemático a día de hoy).

...

...

...

Y no. Las políticas de backup no se han (no se deben, 'quicir) decidir por capricho ni del responsable de backup, ni del proveedor... se deben decidir en base a un BIA (Business Impact Analysis). Si la solución de backup y política implementada no soluciona el BIA entonces hay que revisar o la te

...

Eso no habría pasado el BIA más básico... de verdad me quieres decir que hay una bbdd de clientes en un excel en tu PC sin backup? De verdad una organización permite semejante riesgo?? En caso de pérdida de dicho fichero... cuánto puede sobrevivir esa organización?

Era el servidor del grupo, y efectivamente, no tenía backup.

<un calambrazo recorre mi espina dorsal al leer eso...> Pues mal. TI ahí no hizo su trabajo.

Claro, la "organización" tendría que dedicarse a crear las herramientas que necesitásemos, como esta base de datos y sus programas clientes. Si les hubiésemos esperado, hubieran pasado años antes de que hicieran algo, y hubiéramos estado trabajando años en papel, sin ordenador. Usando el ordenador como máquina de escribir nada mas.

Así que como no lo habían hecho ellos, no había backup.

En estos casos entiendo que un usuario salve su propia información, sí.

Claro que los jefes locales y el que hizo la herramienta podría haber hecho backup en otra maquina local, que es lo que yo hice a partir de entonces.

...

Espero que mi enfoque de backup específico de puesto de usuario cubra tus expectativas :-)

Tienes que pensar también en que muchos de estos grupos son subcontratas. La empresa contratada no puede hacer backups porque están en otra sede y no hay conectividad. Y la empresa cliente tampoco. Y pasan. Y luego pasa lo que pasa.

Esto ya es un problema distinto. Se me ocurren varios enfoques: - la subcontrata sube los entregables a una herramienta colaborativa (sharepoint, o el que más rabia os de). De eso ya tiene que existir backup. - el contrato exige que los datos estén protegidos,y es responsabilidad de la empresa proveedora de servicios cubrir este requisito. - la empresa exige al proveedor trabajar sobre recursos propios de la empresa cliente. Esto es bastante habitual en, por ejemplo, desarrollo de sw. El repositorio de sw puede estar en el cliente, y son los puestos de los desarrolladores los que se conectan a dicho reposotorio. En fin, esto ya es un problema de organización, metodología, etc., no un problema tecnológico. -- Saludos, miguel Los agujeros negros son lugares donde dios dividió por cero. Black holes are places where god divided by zero. Steven Wright -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org