Rsync y discos cifrados o con Btrfs falla
Buenas: Esperando estén todos bien con esto que nos cae. Tengo un problema al hacer una copia en discos con rsync, el sistema se reinicia aleatoriamente cuando está haciéndola. Pero solo pasa con dos discos uno cifrado y el otro con btrfs. Para saber si era eso o el disco lo formatee con xfs y problema solucionado (me fastidia por los snap que son rápidos y me costó su tiempo, eran 8TB). Pero el disco cifrado debe seguir así. Y sincronizar 8TB me lleva todo el día con un motón de reinicios. Y si, pasa con otro disco en las mismas circunstancias. Log, ni flores, empiezan a salir puntos y reinicio, otras ni eso. Falta de memoria no porque tiene 4GB y apenas consume 500MB. Con el btrfs me creo que pueda pasar porque no es una maravilla con según que cosas, pero con el cifrado llevo mucho tiempo usándolo y no había tenido problemas. Así que se aceptan sugerencias. Saludos
Wenas :) On Thu, Mar 11, 2021 at 8:51 AM Francisco F. <admin-listas@satel-sa.com> wrote:
Buenas:
Esperando estén todos bien con esto que nos cae.
Tengo un problema al hacer una copia en discos con rsync, el sistema se reinicia aleatoriamente cuando está haciéndola.
Vaya ... ¿Cuándo se reinicia? Me refiero a cuando ha pasado siempre la misma cantidad de tiempo, siempre cuando copia el mismo directorio, ...
Pero solo pasa con dos discos uno cifrado y el otro con btrfs.
Puede ser el IO. rsync castigo mucho el IO, requiere muchos IOPS. BTRFS es un sistema de ficheros CoW y eso le hace lento. En el caso del cifrado, dependería del cifrado, pero puede que sea el mismo caso. Lo normal es que si el btrfs o cifrado no puede soportar tanto IO, el kernel deje procesos en D (uninterruptible sleep) ... pero si hay algún bug ... eso puede llevar a un reinicio (me imagino).
Para saber si era eso o el disco lo formatee con xfs y problema solucionado (me fastidia por los snap que son rápidos y me costó su tiempo, eran 8TB).
Buena prueba :) Yo estoy muy contento con XFS :)
Pero el disco cifrado debe seguir así. Y sincronizar 8TB me lleva todo el día con un motón de reinicios. Y si, pasa con otro disco en las mismas circunstancias.
Se me ocurre que utilices sar u otra herramienta de monitorización (que guarde histórico) par poder saber en qué punto se reinicia: si hay mucho uso de RAM, CPU, context switches, ...
Log, ni flores, empiezan a salir puntos y reinicio, otras ni eso.
Otra cosa que puedes hacer es rsync más reducidos, es decir, por directorios: rsync <opciones> /dir1/ /destino/dir1/ sync sleep 60 rsync <opciones> /dir2/ /destino/dir2/ sync sleep 60 Algo así. Si, ya, puedes usar un for o un while, ... como más te guste ;) Esto, además, te podría valer para saber si es en un directorio en particular donde falla. Por ejemplo, en un directorio con muchísimos ficheros pequeños y/o subdirectorios.
Falta de memoria no porque tiene 4GB y apenas consume 500MB.
Con el btrfs me creo que pueda pasar porque no es una maravilla con según que cosas, pero con el cifrado llevo mucho tiempo usándolo y no había tenido problemas.
Así que se aceptan sugerencias.
Por ahora no se me ocurre nada más. HTH Rafa
On 11/03/2021 10.39, Rafa Griman wrote:
Wenas :)
On Thu, Mar 11, 2021 at 8:51 AM Francisco F. <admin-listas@satel-sa.com> wrote:
Buenas:
Esperando estén todos bien con esto que nos cae.
Tengo un problema al hacer una copia en discos con rsync, el sistema se reinicia aleatoriamente cuando está haciéndola.
Vaya ... ¿Cuándo se reinicia? Me refiero a cuando ha pasado siempre la misma cantidad de tiempo, siempre cuando copia el mismo directorio, ...
Pero solo pasa con dos discos uno cifrado y el otro con btrfs.
Puede ser el IO. rsync castigo mucho el IO, requiere muchos IOPS. BTRFS es un sistema de ficheros CoW y eso le hace lento. En el caso del cifrado, dependería del cifrado, pero puede que sea el mismo caso.
Lo normal es que si el btrfs o cifrado no puede soportar tanto IO, el kernel deje procesos en D (uninterruptible sleep) ... pero si hay algún bug ... eso puede llevar a un reinicio (me imagino).
Para saber si era eso o el disco lo formatee con xfs y problema solucionado (me fastidia por los snap que son rápidos y me costó su tiempo, eran 8TB).
Buena prueba :) Yo estoy muy contento con XFS :)
Pero el disco cifrado debe seguir así. Y sincronizar 8TB me lleva todo el día con un motón de reinicios. Y si, pasa con otro disco en las mismas circunstancias.
Se me ocurre que utilices sar u otra herramienta de monitorización (que guarde histórico) par poder saber en qué punto se reinicia: si hay mucho uso de RAM, CPU, context switches, ...
Log, ni flores, empiezan a salir puntos y reinicio, otras ni eso.
Otra cosa que puedes hacer es rsync más reducidos, es decir, por directorios: rsync <opciones> /dir1/ /destino/dir1/ sync sleep 60 rsync <opciones> /dir2/ /destino/dir2/ sync sleep 60
Algo así. Si, ya, puedes usar un for o un while, ... como más te guste ;)
Esto, además, te podría valer para saber si es en un directorio en particular donde falla. Por ejemplo, en un directorio con muchísimos ficheros pequeños y/o subdirectorios.
Falta de memoria no porque tiene 4GB y apenas consume 500MB.
Con el btrfs me creo que pueda pasar porque no es una maravilla con según que cosas, pero con el cifrado llevo mucho tiempo usándolo y no había tenido problemas.
Así que se aceptan sugerencias.
Por ahora no se me ocurre nada más.
Yo hago precisamente backup por rsync, con destino en un disco cifrado con LUKS y formateado con btrfs comprimido. Sin snapshots. Funciona perfecto. El sistema de destino es un mini PC sin ventilador. Ocho gigas de ram. El disco es externo via USB. La única pega es que se recalienta durante este trabajo, así que he limitado el uso de CPU del demonio rsync mediante una modificación de su fichero de servicio de systemd. El ordenador de destino tiene actualmente Leap 15.2, pero el ultimo backup lo hice con 15.1 (tengo pendiente hacer otro pero se me olvida dispararlo). Francisco: no has dicho la versión del sistema del ordenador que se cuelga. Cual se cuelga, el de origen o el destino? Y cual es el btrfs, cual el cifrado, método de cifrado, etc. Mismo ordenador o dos, no me queda claro. -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
El so es 15.2 actualizado Los discos de 12TB cifrados (con el que da por defecto yast) y formateados con XFS. El disco de 12TB y btrfs ya lo quité. Me queda uno de 2TB y btrfs que nunca ha dado error Ultima prueba limitando el ancho de banda (--bwlimit=5000) a ver que hace. Ahora el rsync es en el mismo equipo entre dos discos de 12TB El 11/3/21 a las 10:39, Rafa Griman escribió:
Wenas :)
On Thu, Mar 11, 2021 at 8:51 AM Francisco F. <admin-listas@satel-sa.com> wrote:
Buenas:
Esperando estén todos bien con esto que nos cae.
Tengo un problema al hacer una copia en discos con rsync, el sistema se reinicia aleatoriamente cuando está haciéndola.
Vaya ... ¿Cuándo se reinicia? Me refiero a cuando ha pasado siempre la misma cantidad de tiempo, siempre cuando copia el mismo directorio, ...
Es aleatorio, hoy solo tres veces.
Pero solo pasa con dos discos uno cifrado y el otro con btrfs.
Puede ser el IO. rsync castigo mucho el IO, requiere muchos IOPS. BTRFS es un sistema de ficheros CoW y eso le hace lento. En el caso del cifrado, dependería del cifrado, pero puede que sea el mismo caso.
Lo normal es que si el btrfs o cifrado no puede soportar tanto IO, el kernel deje procesos en D (uninterruptible sleep) ... pero si hay algún bug ... eso puede llevar a un reinicio (me imagino).
No creo porque lo estuve mirando y es lento, los discos no son rápidos. Maximo a 50mb/s
Para saber si era eso o el disco lo formatee con xfs y problema solucionado (me fastidia por los snap que son rápidos y me costó su tiempo, eran 8TB).
Buena prueba :) Yo estoy muy contento con XFS :)
Yo también, pero para ir probando lo de los snap usé un disco a ver si iba mas rápido. Me salió rana el experimento
Pero el disco cifrado debe seguir así. Y sincronizar 8TB me lleva todo el día con un motón de reinicios. Y si, pasa con otro disco en las mismas circunstancias.
Se me ocurre que utilices sar u otra herramienta de monitorización (que guarde histórico) par poder saber en qué punto se reinicia: si hay mucho uso de RAM, CPU, context switches, ...
Log, ni flores, empiezan a salir puntos y reinicio, otras ni eso.
Otra cosa que puedes hacer es rsync más reducidos, es decir, por directorios: rsync <opciones> /dir1/ /destino/dir1/ sync sleep 60 rsync <opciones> /dir2/ /destino/dir2/ sync sleep 60
Eso ya lo tengo, si sincronizacese el disco entero de golpe hago una copia al año.
Algo así. Si, ya, puedes usar un for o un while, ... como más te guste ;)
Esto, además, te podría valer para saber si es en un directorio en particular donde falla. Por ejemplo, en un directorio con muchísimos ficheros pequeños y/o subdirectorios.
El 90% son dos directorios con mucha carga de ficheros y tamaño, pero también ha cascado a veces con otros mas pequeños.
Falta de memoria no porque tiene 4GB y apenas consume 500MB.
Con el btrfs me creo que pueda pasar porque no es una maravilla con según que cosas, pero con el cifrado llevo mucho tiempo usándolo y no había tenido problemas.
Así que se aceptan sugerencias.
Por ahora no se me ocurre nada más.
HTH
Rafa
Nada, después de dos semanas de pruebas sigue haciendo lo mismo. Uno de los discos con btrfs lo pase a XFS y problema resuelto, ya van dos copias sin cuelgues. Los otros discos cifrados y con XFS no hay manera, cuando le da se reinicia todo. Y eso que la copia es entre discos y no se implica la red. Los consumos de todo son mínimos. El cifrado es obligatorio, ya que es una copia que sale de la oficina. Solo me queda una por hacer y es formatearlo otra vez y empezar de cero, lo cual me da pereza, son 8TB. Si alguna vez se arregla lo anuncio a bombo y platillo. Saludos El 11/3/21 a las 12:53, Francisco F. escribió:
El so es 15.2 actualizado Los discos de 12TB cifrados (con el que da por defecto yast) y formateados con XFS.
El disco de 12TB y btrfs ya lo quité.
Me queda uno de 2TB y btrfs que nunca ha dado error
Ultima prueba limitando el ancho de banda (--bwlimit=5000) a ver que hace.
Ahora el rsync es en el mismo equipo entre dos discos de 12TB
El 11/3/21 a las 10:39, Rafa Griman escribió:
Wenas :)
On Thu, Mar 11, 2021 at 8:51 AM Francisco F. <admin-listas@satel-sa.com> wrote:
Buenas:
Esperando estén todos bien con esto que nos cae.
Tengo un problema al hacer una copia en discos con rsync, el sistema se reinicia aleatoriamente cuando está haciéndola.
Vaya ... ¿Cuándo se reinicia? Me refiero a cuando ha pasado siempre la misma cantidad de tiempo, siempre cuando copia el mismo directorio, ...
Es aleatorio, hoy solo tres veces.
Pero solo pasa con dos discos uno cifrado y el otro con btrfs.
Puede ser el IO. rsync castigo mucho el IO, requiere muchos IOPS. BTRFS es un sistema de ficheros CoW y eso le hace lento. En el caso del cifrado, dependería del cifrado, pero puede que sea el mismo caso.
Lo normal es que si el btrfs o cifrado no puede soportar tanto IO, el kernel deje procesos en D (uninterruptible sleep) ... pero si hay algún bug ... eso puede llevar a un reinicio (me imagino).
No creo porque lo estuve mirando y es lento, los discos no son rápidos. Maximo a 50mb/s
Para saber si era eso o el disco lo formatee con xfs y problema solucionado (me fastidia por los snap que son rápidos y me costó su tiempo, eran 8TB).
Buena prueba :) Yo estoy muy contento con XFS :)
Yo también, pero para ir probando lo de los snap usé un disco a ver si iba mas rápido. Me salió rana el experimento
Pero el disco cifrado debe seguir así. Y sincronizar 8TB me lleva todo el día con un motón de reinicios. Y si, pasa con otro disco en las mismas circunstancias.
Se me ocurre que utilices sar u otra herramienta de monitorización (que guarde histórico) par poder saber en qué punto se reinicia: si hay mucho uso de RAM, CPU, context switches, ...
Log, ni flores, empiezan a salir puntos y reinicio, otras ni eso.
Otra cosa que puedes hacer es rsync más reducidos, es decir, por directorios: rsync <opciones> /dir1/ /destino/dir1/ sync sleep 60 rsync <opciones> /dir2/ /destino/dir2/ sync sleep 60
Eso ya lo tengo, si sincronizacese el disco entero de golpe hago una copia al año.
Algo así. Si, ya, puedes usar un for o un while, ... como más te guste ;)
Esto, además, te podría valer para saber si es en un directorio en particular donde falla. Por ejemplo, en un directorio con muchísimos ficheros pequeños y/o subdirectorios.
El 90% son dos directorios con mucha carga de ficheros y tamaño, pero también ha cascado a veces con otros mas pequeños.
Falta de memoria no porque tiene 4GB y apenas consume 500MB.
Con el btrfs me creo que pueda pasar porque no es una maravilla con según que cosas, pero con el cifrado llevo mucho tiempo usándolo y no había tenido problemas.
Así que se aceptan sugerencias.
Por ahora no se me ocurre nada más.
HTH
Rafa
El jue, 25 mar 2021 a las 9:38, Francisco F. (<admin-listas@satel-sa.com>) escribió:
Nada, después de dos semanas de pruebas sigue haciendo lo mismo. Uno de los discos con btrfs lo pase a XFS y problema resuelto, ya van dos copias sin cuelgues.
Los otros discos cifrados y con XFS no hay manera, cuando le da se reinicia todo. Y eso que la copia es entre discos y no se implica la red. Los consumos de todo son mínimos.
El cifrado es obligatorio, ya que es una copia que sale de la oficina.
Solo me queda una por hacer y es formatearlo otra vez y empezar de cero, lo cual me da pereza, son 8TB.
Si alguna vez se arregla lo anuncio a bombo y platillo.
Parece que algunos se están olvidando QUE NO DEBEMOS HACER TOP-POSTING... Primero y principal: ¿Tiene sentido hacer backups de una partición BTRFS cuando si tiene correctamente configurado Snapper hace sus propios backups de forma automática? Segundo: ¿No será que rsync "está pasado de moda" y no es la herramienta más adecuada para hacer backups de particiones encriptadas? https://superuser.com/questions/1394918/efficiently-mix-encryption-and-rsync... https://unix.stackexchange.com/questions/506832/encrypting-a-currently-used-... https://security.stackexchange.com/questions/179109/how-to-externally-backup... Salu2
On 25/03/2021 14.34, Juan Erbes wrote:
El jue, 25 mar 2021 a las 9:38, Francisco F. (<admin-listas@satel-sa.com>) escribió:
Nada, después de dos semanas de pruebas sigue haciendo lo mismo. Uno de los discos con btrfs lo pase a XFS y problema resuelto, ya van dos copias sin cuelgues.
Los otros discos cifrados y con XFS no hay manera, cuando le da se reinicia todo. Y eso que la copia es entre discos y no se implica la red. Los consumos de todo son mínimos.
El cifrado es obligatorio, ya que es una copia que sale de la oficina.
Solo me queda una por hacer y es formatearlo otra vez y empezar de cero, lo cual me da pereza, son 8TB.
Si alguna vez se arregla lo anuncio a bombo y platillo.
Parece que algunos se están olvidando QUE NO DEBEMOS HACER TOP-POSTING...
Primero y principal: ¿Tiene sentido hacer backups de una partición BTRFS cuando si tiene correctamente configurado Snapper hace sus propios backups de forma automática?
Para nada. Si se te rompe el disco o se corrompe la partición, lo pierdes todo. Es necesario tener copias de seguridad en un disco duro físicamente distinto.
Segundo: ¿No será que rsync "está pasado de moda" y no es la herramienta más adecuada para hacer backups de particiones encriptadas?
No lo creo. Yo también uso rsync para hacer backups, precisamente a discos encriptados y comprimidos con btrfs, sin problemas.
https://superuser.com/questions/1394918/efficiently-mix-encryption-and-rsync...
https://unix.stackexchange.com/questions/506832/encrypting-a-currently-used-...
https://security.stackexchange.com/questions/179109/how-to-externally-backup...
Bueno, yo obviamente estoy haciendo sin problemas lo que esa gente dice que no consigue hacer. Que me pregunten a mí y se cambien a openSUSE y les ayudo >:-P O me contraten, que necesito la pasta :-) -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
El jue, 25 mar 2021 a las 10:47, Carlos E. R. (<robin.listas@telefonica.net>) escribió:
On 25/03/2021 14.34, Juan Erbes wrote:
El jue, 25 mar 2021 a las 9:38, Francisco F. (<admin-listas@satel-sa.com>) escribió:
Nada, después de dos semanas de pruebas sigue haciendo lo mismo. Uno de los discos con btrfs lo pase a XFS y problema resuelto, ya van dos copias sin cuelgues.
Los otros discos cifrados y con XFS no hay manera, cuando le da se reinicia todo. Y eso que la copia es entre discos y no se implica la
red.
Los consumos de todo son mínimos.
El cifrado es obligatorio, ya que es una copia que sale de la oficina.
Solo me queda una por hacer y es formatearlo otra vez y empezar de cero, lo cual me da pereza, son 8TB.
Si alguna vez se arregla lo anuncio a bombo y platillo.
Parece que algunos se están olvidando QUE NO DEBEMOS HACER TOP-POSTING...
Primero y principal: ¿Tiene sentido hacer backups de una partición BTRFS cuando si tiene correctamente configurado Snapper hace sus propios backups de forma automática?
Para nada. Si se te rompe el disco o se corrompe la partición, lo pierdes todo. Es necesario tener copias de seguridad en un disco duro físicamente distinto.
Segundo: ¿No será que rsync "está pasado de moda" y no es la herramienta más adecuada para hacer backups de particiones encriptadas?
No lo creo. Yo también uso rsync para hacer backups, precisamente a discos encriptados y comprimidos con btrfs, sin problemas.
https://superuser.com/questions/1394918/efficiently-mix-encryption-and-rsync...
https://unix.stackexchange.com/questions/506832/encrypting-a-currently-used-...
https://security.stackexchange.com/questions/179109/how-to-externally-backup...
Bueno, yo obviamente estoy haciendo sin problemas lo que esa gente dice que no consigue hacer. Que me pregunten a mí y se cambien a openSUSE y les ayudo >:-P
O me contraten, que necesito la pasta :-) ¿Que clase de fideos?😂😂😂😂😂😂😂
Algo que no le pregunté a Francisco, es si no se trata de un problema con la placa controladora de los discos, donde el driver no maneja correctamente todas las instrucciones. El jueves pasado, amén de tener que lidiar con un enfermo psiquiátrico, tuve que lidiar también con un problema con el sistema de audio. Ocurrió que desde que arranqué la pc por primera vez, en la conexión de fibra óptica al sintoamplificador el audio viajaba codificado en 88.2 KHz o 96 KHz y el sintoamplificador no podía decodificar en surround 5.1 + LFE. Probé casi todo, toqueteando las configuraciones de pulseaudio, quitar y volver a agregar la tarjeta de sonido en Yast, reiniciar varias veces el sistema, cuando siempre había configurado la tarjeta de sonido de la misma forma. Finalmente, dentro de la configuración de la tarjeta de sonido en Yast, había un parámetro que nunca había seteado, llamado: Rate multiplier (default=2) Le coloqué el valor "1", y problema solucionado. Al menos como dice el refrán: "No hay mal que por bien no venga", conseguí mejorar la configuración de la tarjeta de sonido para aprovechar los 24 bits del DAC: https://www.cnet.com/products/creative-sound-blaster-x-fi-titanium-fatal1ty-... /proc/asound/card0/pcm0c/sub0> cat hw_params access: MMAP_INTERLEAVED format: S24_3LE subformat: STD channels: 2 rate: 44100 (44100/1) period_size: 4369 buffer_size: 21845 Tal como indica el siguiente link: https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/Supp... s24le: signed 24-bit little-endian integer (note: ALSA calls this "S24_3LE") Ajustando la configuración en /etc/pulse/daemon.conf default-sample-format = s24le default-sample-rate = 44100 alternate-sample-rate = 48000 default-sample-channels = 2 default-channel-map = front-left,front-right Ahora con estos ajustes el proceso "pulseaudio", según top en vez de consumir un 6% de una de las 8 cpu, consume alrededor del 3%, con una mejor calidad de sonido. Salu2 -- USA LINUX OPENSUSE QUE ES SOFTWARE LIBRE, NO NECESITAS PIRATEAR NADA Y NI TE VAS A PREOCUPAR MAS POR LOS VIRUS Y SPYWARES: http://www.opensuse.org/es/ Puedes visitar mi blog en: http://jerbes.blogspot.com.ar/
El 25/3/21 a las 14:34, Juan Erbes escribió:
El jue, 25 mar 2021 a las 9:38, Francisco F. (<admin-listas@satel-sa.com>) escribió:
Nada, después de dos semanas de pruebas sigue haciendo lo mismo. Uno de los discos con btrfs lo pase a XFS y problema resuelto, ya van dos copias sin cuelgues.
Los otros discos cifrados y con XFS no hay manera, cuando le da se reinicia todo. Y eso que la copia es entre discos y no se implica la red. Los consumos de todo son mínimos.
El cifrado es obligatorio, ya que es una copia que sale de la oficina.
Solo me queda una por hacer y es formatearlo otra vez y empezar de cero, lo cual me da pereza, son 8TB.
Si alguna vez se arregla lo anuncio a bombo y platillo.
Parece que algunos se están olvidando QUE NO DEBEMOS HACER TOP-POSTING...
Llevo toda la mañana haciéndolos, si no lo hago no se leen los correos. No les gusta tener que bajar para ver las respuestas.
Primero y principal: ¿Tiene sentido hacer backups de una partición BTRFS cuando si tiene correctamente configurado Snapper hace sus propios backups de forma automática?
No es eso. Es copia desde el servidor (XFS, servidor rsync) a la copia. Fallaba el disco formateado con BTRFS, no los XFS de las copias. Precisamente quería migrar todo a btrfs por los snapshots, mas rápidos que los enlaces del rsync. Pero me salió rana. Si tengo otro de 2TB para copia de otro servidor pequeño y este va muy bien, por eso me animé a hacerlo con el de 12TB.
Segundo: ¿No será que rsync "está pasado de moda" y no es la herramienta más adecuada para hacer backups de particiones encriptadas?
Llevo mucho tiempo con esto y nunca me dió ningún problema, si que no es la solución mas rápida. Lo de las placas, he probado con dos, con tarjetas PCIe sata, ponga donde ponga el disco falla. Así que mas bien parece un tema del tamaño de los discos 12TB (son dos de distinta marca) y algo mas con según que tipos de formateos. No se cual porque no encuentro ningún registro de fallos. En fin como dije antes me queda formatear todo de nuevo o seguir como hasta ahora y cada vez que se reinicia volver a mandar la copia con los directorios que faltan (menos mal que lo tengo segmentado). Gracias por las sugerencias
El jue, 25 mar 2021 a las 13:25, Francisco F. (<admin-listas@satel-sa.com>) escribió:
El 25/3/21 a las 14:34, Juan Erbes escribió:
El jue, 25 mar 2021 a las 9:38, Francisco F. (<admin-listas@satel-sa.com>) escribió:
Nada, después de dos semanas de pruebas sigue haciendo lo mismo. Uno de los discos con btrfs lo pase a XFS y problema resuelto, ya van dos copias sin cuelgues.
Los otros discos cifrados y con XFS no hay manera, cuando le da se reinicia todo. Y eso que la copia es entre discos y no se implica la
red.
Los consumos de todo son mínimos.
El cifrado es obligatorio, ya que es una copia que sale de la oficina.
Solo me queda una por hacer y es formatearlo otra vez y empezar de cero, lo cual me da pereza, son 8TB.
Si alguna vez se arregla lo anuncio a bombo y platillo.
Parece que algunos se están olvidando QUE NO DEBEMOS HACER TOP-POSTING...
Llevo toda la mañana haciéndolos, si no lo hago no se leen los correos. No les gusta tener que bajar para ver las respuestas.
Primero y principal: ¿Tiene sentido hacer backups de una partición BTRFS cuando si tiene correctamente configurado Snapper hace sus propios backups de forma automática?
No es eso. Es copia desde el servidor (XFS, servidor rsync) a la copia. Fallaba el disco formateado con BTRFS, no los XFS de las copias. Precisamente quería migrar todo a btrfs por los snapshots, mas rápidos que los enlaces del rsync. Pero me salió rana.
Si tengo otro de 2TB para copia de otro servidor pequeño y este va muy bien, por eso me animé a hacerlo con el de 12TB.
Segundo: ¿No será que rsync "está pasado de moda" y no es la herramienta más adecuada para hacer backups de particiones encriptadas?
Llevo mucho tiempo con esto y nunca me dió ningún problema, si que no es la solución mas rápida.
Lo de las placas, he probado con dos, con tarjetas PCIe sata, ponga donde ponga el disco falla.
Así que mas bien parece un tema del tamaño de los discos 12TB (son dos de distinta marca) y algo mas con según que tipos de formateos. No se cual porque no encuentro ningún registro de fallos.
En fin como dije antes me queda formatear todo de nuevo o seguir como hasta ahora y cada vez que se reinicia volver a mandar la copia con los directorios que faltan (menos mal que lo tengo segmentado).
Como diría la Ley de Murphy "Si algo puede fallar, va a fallar" Y muchas veces, aquello que no miramos o no tenemos en cuenta y pasamos por alto. Como mencioné antes, lo que me pasó con la tarjeta de sonido. ¿Revisaste el seteo de los jumpers de los discos duros? El seteo en la bios, los tienes como AHCI? https://hardzone.es/tutoriales/rendimiento/ahci-discos-duros-rendimiento/ Suerte, Juan -- USA LINUX OPENSUSE QUE ES SOFTWARE LIBRE, NO NECESITAS PIRATEAR NADA Y NI TE VAS A PREOCUPAR MAS POR LOS VIRUS Y SPYWARES: http://www.opensuse.org/es/ Puedes visitar mi blog en: http://jerbes.blogspot.com.ar/
Wenas :) On Thu, Mar 25, 2021 at 4:25 PM Francisco F. <admin-listas@satel-sa.com> wrote: [...]
Si tengo otro de 2TB para copia de otro servidor pequeño y este va muy bien, por eso me animé a hacerlo con el de 12TB.
Ahora que mencionas eso, acabo de caer en una cosa. El disco que falla, ¿no será SMR (shingled)? Esos "fallan" que da gusto. Pero OJO !!! No es que fallen es que no dan el rendimiento, han sido diseñados para bajo rendimiento (archivado de datos). La comunidad de OpenZFS y la gente de iXsystems (IIRC) lo han comentado mucho. Hubo un buen artículo en www.servethehome.com donde se comentaba. La verdad es que ha salido envarios blogs. Busca en Inet el número de serie, marca, modelo y a ver si es shingled o no. Si lo es ... vas a tener que limitar rsync de alguna manera: reducir las copias simultáneas, directorios, tamaño de directorio, ... [...]
Así que mas bien parece un tema del tamaño de los discos 12TB (son dos de distinta marca) y algo mas con según que tipos de formateos. No se cual porque no encuentro ningún registro de fallos.
Si son shingled, no ver'as fallos porque realmente no hay fallo ... b'asicamente, el disco "se cansa" ... Ya, ya sé que no es un término técnico xD
En fin como dije antes me queda formatear todo de nuevo o seguir como hasta ahora y cada vez que se reinicia volver a mandar la copia con los directorios que faltan (menos mal que lo tengo segmentado).
Espero que o resuelvas pronto ;)
Gracias por las sugerencias
HTH Rafa
On 25/03/2021 19.37, Rafa Griman wrote:
Wenas :)
On Thu, Mar 25, 2021 at 4:25 PM Francisco F. <admin-listas@satel-sa.com> wrote:
[...]
Si tengo otro de 2TB para copia de otro servidor pequeño y este va muy bien, por eso me animé a hacerlo con el de 12TB.
Ahora que mencionas eso, acabo de caer en una cosa. El disco que falla, ¿no será SMR (shingled)? Esos "fallan" que da gusto. Pero OJO !!! No es que fallen es que no dan el rendimiento, han sido diseñados para bajo rendimiento (archivado de datos). La comunidad de OpenZFS y la gente de iXsystems (IIRC) lo han comentado mucho.
Hubo un buen artículo en www.servethehome.com donde se comentaba. La verdad es que ha salido envarios blogs. Busca en Inet el número de serie, marca, modelo y a ver si es shingled o no. Si lo es ... vas a tener que limitar rsync de alguna manera: reducir las copias simultáneas, directorios, tamaño de directorio, ...
Hay un modo de averiguarlo. A ver si encuentro el dato... Ya. Ejecuta: hdparm -I /dev/sdX | grep -i TRIM Si es "oxido rotante" y retorna datos, es SMR. Las listas no son fiables: tengo un disco Seagate de 4 TB que está en la lista, pero no es SMR, porque dá una velocidad mantenida en escritura de 130MBps (escribí el disco entero). <https://hardzone.es/tutoriales/componentes/lista-disco-duro-smr/> saqué el comando de ahí. rsync tiene un parámetro para limitar el i/o, creo.
[...]
Así que mas bien parece un tema del tamaño de los discos 12TB (son dos de distinta marca) y algo mas con según que tipos de formateos. No se cual porque no encuentro ningún registro de fallos.
Si son shingled, no ver'as fallos porque realmente no hay fallo ... b'asicamente, el disco "se cansa" ... Ya, ya sé que no es un término técnico xD
:-D Sospecho que puedes forzar un trim y vuelve a responder cuando termine.
En fin como dije antes me queda formatear todo de nuevo o seguir como hasta ahora y cada vez que se reinicia volver a mandar la copia con los directorios que faltan (menos mal que lo tengo segmentado).
Espero que o resuelvas pronto ;)
Gracias por las sugerencias
HTH
Rafa
-- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
El 25/3/21 a las 19:58, Carlos E. R. escribió:
On 25/03/2021 19.37, Rafa Griman wrote:
Wenas :)
On Thu, Mar 25, 2021 at 4:25 PM Francisco F. <admin-listas@satel-sa.com> wrote:
[...]
Si tengo otro de 2TB para copia de otro servidor pequeño y este va muy bien, por eso me animé a hacerlo con el de 12TB.
Ahora que mencionas eso, acabo de caer en una cosa. El disco que falla, ¿no será SMR (shingled)? Esos "fallan" que da gusto. Pero OJO !!! No es que fallen es que no dan el rendimiento, han sido diseñados para bajo rendimiento (archivado de datos). La comunidad de OpenZFS y la gente de iXsystems (IIRC) lo han comentado mucho.
Hubo un buen artículo en www.servethehome.com donde se comentaba. La verdad es que ha salido envarios blogs. Busca en Inet el número de serie, marca, modelo y a ver si es shingled o no. Si lo es ... vas a tener que limitar rsync de alguna manera: reducir las copias simultáneas, directorios, tamaño de directorio, ...
Hay un modo de averiguarlo. A ver si encuentro el dato... Ya.
Ejecuta:
hdparm -I /dev/sdX | grep -i TRIM
Si es "oxido rotante" y retorna datos, es SMR.
Ninguno de ellos es de ese tipo
Las listas no son fiables: tengo un disco Seagate de 4 TB que está en la lista, pero no es SMR, porque dá una velocidad mantenida en escritura de 130MBps (escribí el disco entero).
<https://hardzone.es/tutoriales/componentes/lista-disco-duro-smr/>
saqué el comando de ahí.
rsync tiene un parámetro para limitar el i/o, creo.
Si, lo puse a 10Mb y mas de lo mismo
[...]
Así que mas bien parece un tema del tamaño de los discos 12TB (son dos de distinta marca) y algo mas con según que tipos de formateos. No se cual porque no encuentro ningún registro de fallos.
Si son shingled, no ver'as fallos porque realmente no hay fallo ... b'asicamente, el disco "se cansa" ... Ya, ya sé que no es un término técnico xD
:-D
Sospecho que puedes forzar un trim y vuelve a responder cuando termine.
Descarté el rsync haciendo la copia con mc, scp y se queda frito igual. Suele pasar cuando pilla archivos grandes. Otra prueba: Copia desde un disco (mc o scp) con XFS al de 2TB con btrfs de una carpeta de 10GB con dos ficheros de 3GB. Cuelgue total. Por lo general se cuelga al rato de empezar, alguna vez a la primera copia no se cuelga pero si repito el proceso se congela seguro. Así que confirmado que btrfs es el culpable por alguna razón o parámetro puñetero. Lo mismo con el cifrado+XFS, Probado entre discos XFS y todo bien aunque repita la operación 4 o 5 veces
En fin como dije antes me queda formatear todo de nuevo o seguir como hasta ahora y cada vez que se reinicia volver a mandar la copia con los directorios que faltan (menos mal que lo tengo segmentado).
Espero que o resuelvas pronto ;)
Gracias por las sugerencias
HTH
Rafa
On 30/03/2021 16.46, Francisco F. wrote:
El 25/3/21 a las 19:58, Carlos E. R. escribió:
On 25/03/2021 19.37, Rafa Griman wrote:
Wenas :)
On Thu, Mar 25, 2021 at 4:25 PM Francisco F. <> wrote:
...
Así que mas bien parece un tema del tamaño de los discos 12TB (son dos de distinta marca) y algo mas con según que tipos de formateos. No se cual porque no encuentro ningún registro de fallos.
Si son shingled, no ver'as fallos porque realmente no hay fallo ... b'asicamente, el disco "se cansa" ... Ya, ya sé que no es un término técnico xD
:-D
Sospecho que puedes forzar un trim y vuelve a responder cuando termine.
Descarté el rsync haciendo la copia con mc, scp y se queda frito igual. Suele pasar cuando pilla archivos grandes.
Otra prueba:
Copia desde un disco (mc o scp) con XFS al de 2TB con btrfs de una carpeta de 10GB con dos ficheros de 3GB. Cuelgue total. Por lo general se cuelga al rato de empezar, alguna vez a la primera copia no se cuelga pero si repito el proceso se congela seguro.
Así que confirmado que btrfs es el culpable por alguna razón o parámetro puñetero.
Lo mismo con el cifrado+XFS,
Probado entre discos XFS y todo bien aunque repita la operación 4 o 5 veces
Pues creo que ahí tienes información suficiente para escribir un bugzilla. -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
El 30/3/21 a las 18:32, Carlos E. R. escribió:
On 30/03/2021 16.46, Francisco F. wrote:
El 25/3/21 a las 19:58, Carlos E. R. escribió:
On 25/03/2021 19.37, Rafa Griman wrote:
Wenas :)
On Thu, Mar 25, 2021 at 4:25 PM Francisco F. <> wrote:
...
Así que mas bien parece un tema del tamaño de los discos 12TB (son dos de distinta marca) y algo mas con según que tipos de formateos. No se cual porque no encuentro ningún registro de fallos.
Si son shingled, no ver'as fallos porque realmente no hay fallo ... b'asicamente, el disco "se cansa" ... Ya, ya sé que no es un término técnico xD
:-D
Sospecho que puedes forzar un trim y vuelve a responder cuando termine.
Descarté el rsync haciendo la copia con mc, scp y se queda frito igual. Suele pasar cuando pilla archivos grandes.
Otra prueba:
Copia desde un disco (mc o scp) con XFS al de 2TB con btrfs de una carpeta de 10GB con dos ficheros de 3GB. Cuelgue total. Por lo general se cuelga al rato de empezar, alguna vez a la primera copia no se cuelga pero si repito el proceso se congela seguro.
Así que confirmado que btrfs es el culpable por alguna razón o parámetro puñetero.
Lo mismo con el cifrado+XFS,
Probado entre discos XFS y todo bien aunque repita la operación 4 o 5 veces
Pues creo que ahí tienes información suficiente para escribir un bugzilla.
Si, pero no tengo nada con que acompañarlo. Lo mas que sale en el log cuando se cuelga son ......................... He probado los dos discos en otro ordenador y misma versión 15.2 y funciona bien. Ya solo me queda la opción que nunca me gusta, formatear y empezar de cero, a ver si es algún parámetro que se ha quedado perdido.
On 31/03/2021 14.35, Francisco F. wrote:
El 30/3/21 a las 18:32, Carlos E. R. escribió:
On 30/03/2021 16.46, Francisco F. wrote:
El 25/3/21 a las 19:58, Carlos E. R. escribió:
On 25/03/2021 19.37, Rafa Griman wrote:
Wenas :)
On Thu, Mar 25, 2021 at 4:25 PM Francisco F. <> wrote:
...
Así que mas bien parece un tema del tamaño de los discos 12TB (son dos de distinta marca) y algo mas con según que tipos de formateos. No se cual porque no encuentro ningún registro de fallos.
Si son shingled, no ver'as fallos porque realmente no hay fallo ... b'asicamente, el disco "se cansa" ... Ya, ya sé que no es un término técnico xD
:-D
Sospecho que puedes forzar un trim y vuelve a responder cuando termine.
Descarté el rsync haciendo la copia con mc, scp y se queda frito igual. Suele pasar cuando pilla archivos grandes.
Otra prueba:
Copia desde un disco (mc o scp) con XFS al de 2TB con btrfs de una carpeta de 10GB con dos ficheros de 3GB. Cuelgue total. Por lo general se cuelga al rato de empezar, alguna vez a la primera copia no se cuelga pero si repito el proceso se congela seguro.
Así que confirmado que btrfs es el culpable por alguna razón o parámetro puñetero.
Lo mismo con el cifrado+XFS,
Probado entre discos XFS y todo bien aunque repita la operación 4 o 5 veces
Pues creo que ahí tienes información suficiente para escribir un bugzilla.
Si, pero no tengo nada con que acompañarlo.
Lo mas que sale en el log cuando se cuelga son .........................
Pues pones eso. Tu pon todo lo que sabes. Que copias de A a B, que B ha sido creado de tal forma, y que se cuelga o se reinicia, lo que sea. Que en cambio si B no es btrfs no pasa nada. -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
El mié, 31 mar 2021 a las 9:45, Francisco F. (<admin-listas@satel-sa.com>) escribió:
El 30/3/21 a las 18:32, Carlos E. R. escribió:
On 30/03/2021 16.46, Francisco F. wrote:
El 25/3/21 a las 19:58, Carlos E. R. escribió:
On 25/03/2021 19.37, Rafa Griman wrote:
Wenas :)
On Thu, Mar 25, 2021 at 4:25 PM Francisco F. <> wrote:
...
Así que mas bien parece un tema del tamaño de los discos 12TB (son dos de distinta marca) y algo mas con según que tipos de formateos. No se cual porque no encuentro ningún registro de fallos.
Si son shingled, no ver'as fallos porque realmente no hay fallo ... b'asicamente, el disco "se cansa" ... Ya, ya sé que no es un término técnico xD
:-D
Sospecho que puedes forzar un trim y vuelve a responder cuando termine.
Descarté el rsync haciendo la copia con mc, scp y se queda frito igual. Suele pasar cuando pilla archivos grandes.
Otra prueba:
Copia desde un disco (mc o scp) con XFS al de 2TB con btrfs de una carpeta de 10GB con dos ficheros de 3GB. Cuelgue total. Por lo general se cuelga al rato de empezar, alguna vez a la primera copia no se cuelga pero si repito el proceso se congela seguro.
Así que confirmado que btrfs es el culpable por alguna razón o parámetro puñetero.
Lo mismo con el cifrado+XFS,
Probado entre discos XFS y todo bien aunque repita la operación 4 o 5 veces
Pues creo que ahí tienes información suficiente para escribir un bugzilla.
Si, pero no tengo nada con que acompañarlo.
Lo mas que sale en el log cuando se cuelga son .........................
He probado los dos discos en otro ordenador y misma versión 15.2 y funciona bien.
Entonces te queda claro que no son los discos duros ni el sistema donde está el problema. Evidentemente, es el hardware donde los usas habitualmente. ¿Revisaste las fuente de alimentación?
Ya solo me queda la opción que nunca me gusta, formatear y empezar de cero, a ver si es algún parámetro que se ha quedado perdido.
Por lo que dije antes, creo que no es la opción correcta . Saludos
El mar, 30 mar 2021 a las 11:55, Francisco F. (<admin-listas@satel-sa.com>) escribió:
El 25/3/21 a las 19:58, Carlos E. R. escribió:
On 25/03/2021 19.37, Rafa Griman wrote:
Wenas :)
On Thu, Mar 25, 2021 at 4:25 PM Francisco F. <admin-listas@satel-sa.com> wrote:
[...]
Si tengo otro de 2TB para copia de otro servidor pequeño y este va muy bien, por eso me animé a hacerlo con el de 12TB.
Ahora que mencionas eso, acabo de caer en una cosa. El disco que falla, ¿no será SMR (shingled)? Esos "fallan" que da gusto. Pero OJO !!! No es que fallen es que no dan el rendimiento, han sido diseñados para bajo rendimiento (archivado de datos). La comunidad de OpenZFS y la gente de iXsystems (IIRC) lo han comentado mucho.
Hubo un buen artículo en www.servethehome.com donde se comentaba. La verdad es que ha salido envarios blogs. Busca en Inet el número de serie, marca, modelo y a ver si es shingled o no. Si lo es ... vas a tener que limitar rsync de alguna manera: reducir las copias simultáneas, directorios, tamaño de directorio, ...
Hay un modo de averiguarlo. A ver si encuentro el dato... Ya.
Ejecuta:
hdparm -I /dev/sdX | grep -i TRIM
Si es "oxido rotante" y retorna datos, es SMR.
Ninguno de ellos es de ese tipo
Las listas no son fiables: tengo un disco Seagate de 4 TB que está en la lista, pero no es SMR, porque dá una velocidad mantenida en escritura de 130MBps (escribí el disco entero).
<https://hardzone.es/tutoriales/componentes/lista-disco-duro-smr/>
saqué el comando de ahí.
rsync tiene un parámetro para limitar el i/o, creo.
Si, lo puse a 10Mb y mas de lo mismo
[...]
Así que mas bien parece un tema del tamaño de los discos 12TB (son dos de distinta marca) y algo mas con según que tipos de formateos. No se cual porque no encuentro ningún registro de fallos.
Si son shingled, no ver'as fallos porque realmente no hay fallo ... b'asicamente, el disco "se cansa" ... Ya, ya sé que no es un término técnico xD
:-D
Sospecho que puedes forzar un trim y vuelve a responder cuando termine.
Descarté el rsync haciendo la copia con mc, scp y se queda frito igual. Suele pasar cuando pilla archivos grandes.
Otra prueba:
Copia desde un disco (mc o scp) con XFS al de 2TB con btrfs de una carpeta de 10GB con dos ficheros de 3GB. Cuelgue total. Por lo general se cuelga al rato de empezar, alguna vez a la primera copia no se cuelga pero si repito el proceso se congela seguro.
Así que confirmado que btrfs es el culpable por alguna razón o parámetro puñetero.
Lo mismo con el cifrado+XFS,
Probado entre discos XFS y todo bien aunque repita la operación 4 o 5 veces
¿No tienes un problema de temperatura en el chipset? Algo así como un disipador que no hace un correcto contacto térmico con el chip, o la temperatura dentro del gabinete del cpu es demasiado elevada. También las soldaduras de algún chip, que por stress térmico se hayan cortado y hacen falso contacto en determinadas circunstancias. O tal vez sea tan solo polvo entre los pines de los chips, que ha adquirido cirta conductividad debido a la humedad ambiente. Suerte, Juan -- USA LINUX OPENSUSE QUE ES SOFTWARE LIBRE, NO NECESITAS PIRATEAR NADA Y NI TE VAS A PREOCUPAR MAS POR LOS VIRUS Y SPYWARES: http://www.opensuse.org/es/ Puedes visitar mi blog en: http://jerbes.blogspot.com.ar/
El 30/3/21 a las 19:55, Juan Erbes escribió:
El mar, 30 mar 2021 a las 11:55, Francisco F. (<admin-listas@satel-sa.com <mailto:admin-listas@satel-sa.com>>) escribió:
El 25/3/21 a las 19:58, Carlos E. R. escribió: > On 25/03/2021 19.37, Rafa Griman wrote: >> Wenas :) >> >> On Thu, Mar 25, 2021 at 4:25 PM Francisco F. >> <admin-listas@satel-sa.com <mailto:admin-listas@satel-sa.com>> wrote: >> >> [...] >> >>> Si tengo otro de 2TB para copia de otro servidor pequeño y este va muy >>> bien, por eso me animé a hacerlo con el de 12TB. >> >> Ahora que mencionas eso, acabo de caer en una cosa. El disco que >> falla, ¿no será SMR (shingled)? Esos "fallan" que da gusto. Pero OJO >> !!! No es que fallen es que no dan el rendimiento, han sido diseñados >> para bajo rendimiento (archivado de datos). La comunidad de OpenZFS y >> la gente de iXsystems (IIRC) lo han comentado mucho. >> >> Hubo un buen artículo en www.servethehome.com <http://www.servethehome.com> donde se comentaba. La >> verdad es que ha salido envarios blogs. Busca en Inet el número de >> serie, marca, modelo y a ver si es shingled o no. Si lo es ... vas a >> tener que limitar rsync de alguna manera: reducir las copias >> simultáneas, directorios, tamaño de directorio, ... > > Hay un modo de averiguarlo. A ver si encuentro el dato... Ya. > > Ejecuta: > > hdparm -I /dev/sdX | grep -i TRIM > > Si es "oxido rotante" y retorna datos, es SMR.
Ninguno de ellos es de ese tipo
>> Las listas no son fiables: tengo un disco Seagate de 4 TB que está en la > lista, pero no es SMR, porque dá una velocidad mantenida en escritura de > 130MBps (escribí el disco entero). > > <https://hardzone.es/tutoriales/componentes/lista-disco-duro-smr/ <https://hardzone.es/tutoriales/componentes/lista-disco-duro-smr/>> > > saqué el comando de ahí. > > > rsync tiene un parámetro para limitar el i/o, creo. >
Si, lo puse a 10Mb y mas de lo mismo
>> >> [...] >> >>> Así que mas bien parece un tema del tamaño de los discos 12TB (son dos >>> de distinta marca) y algo mas con según que tipos de formateos. No se >>> cual porque no encuentro ningún registro de fallos. >> >> >> Si son shingled, no ver'as fallos porque realmente no hay fallo ... >> b'asicamente, el disco "se cansa" ... Ya, ya sé que no es un término >> técnico xD > > :-D > > Sospecho que puedes forzar un trim y vuelve a responder cuando termine. > >
Descarté el rsync haciendo la copia con mc, scp y se queda frito igual. Suele pasar cuando pilla archivos grandes.
Otra prueba:
Copia desde un disco (mc o scp) con XFS al de 2TB con btrfs de una carpeta de 10GB con dos ficheros de 3GB. Cuelgue total. Por lo general se cuelga al rato de empezar, alguna vez a la primera copia no se cuelga pero si repito el proceso se congela seguro.
Así que confirmado que btrfs es el culpable por alguna razón o parámetro puñetero.
Lo mismo con el cifrado+XFS,
Probado entre discos XFS y todo bien aunque repita la operación 4 o 5 veces
¿No tienes un problema de temperatura en el chipset?
He probado con 3 distintos, la propia placa y 2 tarjetas SATA. Si fuese el chipset supongo que se fastidiaría con todos los discos, pero solo pasa con esos. He cambiado cables, las posiciones en la cabina, los he puesto sueltos. Los discos comprobados en otro PC y todo correcto, las copias se hacen bien. Así que me queda el borrado y vuelta a empezar, menos mal que no tengo configuraciones raras, el cron que lanza la copia. Y si con eso falla le pego fuego, porque que falle todo pase, pero solo esos dos formatos y sin ningún tipo de aviso ya mosquea. Seguiré contando
Algo así como un disipador que no hace un correcto contacto térmico con el chip, o la temperatura dentro del gabinete del cpu es demasiado elevada.
También las soldaduras de algún chip, que por stress térmico se hayan cortado y hacen falso contacto en determinadas circunstancias.
O tal vez sea tan solo polvo entre los pines de los chips, que ha adquirido cirta conductividad debido a la humedad ambiente.
Suerte, Juan
-- USA LINUX OPENSUSE QUE ES SOFTWARE LIBRE, NO NECESITAS PIRATEAR NADA Y NI TE VAS A PREOCUPAR MAS POR LOS VIRUS Y SPYWARES: http://www.opensuse.org/es/ <http://www.opensuse.org/es/> Puedes visitar mi blog en: http://jerbes.blogspot.com.ar/ <http://jerbes.blogspot.com.ar/>
El El jue, 25 de mar. de 2021 a la(s) 10:25, Francisco F. < admin-listas@satel-sa.com> escribió:
El 25/3/21 a las 14:34, Juan Erbes escribió:
El jue, 25 mar 2021 a las 9:38, Francisco F. (<admin-listas@satel-sa.com>) escribió:
Nada, después de dos semanas de pruebas sigue haciendo lo mismo. Uno de los discos con btrfs lo pase a XFS y problema resuelto, ya van dos copias sin cuelgues.
Los otros discos cifrados y con XFS no hay manera, cuando le da se reinicia todo. Y eso que la copia es entre discos y no se implica la
red.
Los consumos de todo son mínimos.
El cifrado es obligatorio, ya que es una copia que sale de la oficina.
Solo me queda una por hacer y es formatearlo otra vez y empezar de cero, lo cual me da pereza, son 8TB.
Si alguna vez se arregla lo anuncio a bombo y platillo.
Parece que algunos se están olvidando QUE NO DEBEMOS HACER TOP-POSTING...
Llevo toda la mañana haciéndolos, si no lo hago no se leen los correos. No les gusta tener que bajar para ver las respuestas.
Primero y principal: ¿Tiene sentido hacer backups de una partición BTRFS cuando si tiene correctamente configurado Snapper hace sus propios backups de forma automática?
No es eso. Es copia desde el servidor (XFS, servidor rsync) a la copia. Fallaba el disco formateado con BTRFS, no los XFS de las copias. Precisamente quería migrar todo a btrfs por los snapshots, mas rápidos que los enlaces del rsync. Pero me salió rana.
Si tengo otro de 2TB para copia de otro servidor pequeño y este va muy bien, por eso me animé a hacerlo con el de 12TB.
Segundo: ¿No será que rsync "está pasado de moda" y no es la herramienta más adecuada para hacer backups de particiones encriptadas?
Llevo mucho tiempo con esto y nunca me dió ningún problema, si que no es la solución mas rápida.
Lo de las placas, he probado con dos, con tarjetas PCIe sata, ponga donde ponga el disco falla.
Así que mas bien parece un tema del tamaño de los discos 12TB (son dos de distinta marca) y algo mas con según que tipos de formateos. No se cual porque no encuentro ningún registro de fallos.
En fin como dije antes me queda formatear todo de nuevo o seguir como hasta ahora y cada vez que se reinicia volver a mandar la copia con los directorios que faltan (menos mal que lo tengo segmentado).
Gracias por las sugerencias
Hola a todos, se que llegue tarde, pero pudiste solucionar? Me pareció interesante este mensaje.
--
rickygm http://gnuforever.homelinux.com
El 25/10/21 a las 1:53, Rick Gutierrez escribió:
El El jue, 25 de mar. de 2021 a la(s) 10:25, Francisco F. <admin-listas@satel-sa.com <mailto:admin-listas@satel-sa.com>> escribió:
El 25/3/21 a las 14:34, Juan Erbes escribió: > El jue, 25 mar 2021 a las 9:38, Francisco F. > (<admin-listas@satel-sa.com <mailto:admin-listas@satel-sa.com>>) escribió: >> >> Nada, después de dos semanas de pruebas sigue haciendo lo mismo. >> Uno de los discos con btrfs lo pase a XFS y problema resuelto, ya van >> dos copias sin cuelgues. >> >> Los otros discos cifrados y con XFS no hay manera, cuando le da se >> reinicia todo. Y eso que la copia es entre discos y no se implica la red. >> Los consumos de todo son mínimos. >> >> El cifrado es obligatorio, ya que es una copia que sale de la oficina. >> >> Solo me queda una por hacer y es formatearlo otra vez y empezar de cero, >> lo cual me da pereza, son 8TB. >> >> Si alguna vez se arregla lo anuncio a bombo y platillo. >> > > Parece que algunos se están olvidando QUE NO DEBEMOS HACER TOP-POSTING...
Llevo toda la mañana haciéndolos, si no lo hago no se leen los correos. No les gusta tener que bajar para ver las respuestas.
> > Primero y principal: > ¿Tiene sentido hacer backups de una partición BTRFS cuando si tiene > correctamente configurado Snapper hace sus propios backups de forma > automática? > No es eso. Es copia desde el servidor (XFS, servidor rsync) a la copia. Fallaba el disco formateado con BTRFS, no los XFS de las copias. Precisamente quería migrar todo a btrfs por los snapshots, mas rápidos que los enlaces del rsync. Pero me salió rana.
Si tengo otro de 2TB para copia de otro servidor pequeño y este va muy bien, por eso me animé a hacerlo con el de 12TB.
> Segundo: > ¿No será que rsync "está pasado de moda" y no es la herramienta más > adecuada para hacer backups de particiones encriptadas? >
Llevo mucho tiempo con esto y nunca me dió ningún problema, si que no es la solución mas rápida.
Lo de las placas, he probado con dos, con tarjetas PCIe sata, ponga donde ponga el disco falla.
Así que mas bien parece un tema del tamaño de los discos 12TB (son dos de distinta marca) y algo mas con según que tipos de formateos. No se cual porque no encuentro ningún registro de fallos.
En fin como dije antes me queda formatear todo de nuevo o seguir como hasta ahora y cada vez que se reinicia volver a mandar la copia con los directorios que faltan (menos mal que lo tengo segmentado).
Gracias por las sugerencias
Hola a todos, se que llegue tarde, pero pudiste solucionar?
Me pareció interesante este mensaje.
Como hubiese sido correcto no. Cambié la placa base y todo solucionado (algún módulo que no se llevaba bien), era una AMD, la otra una Intel. No tenía tiempo para mas pruebas. Ahora tengo unos 10 discos todos en btrfs y sin problemas. Y usando multi dispositivo single (el JBOD normal creo) )para ampliar capacidad ya que no me interesa redundancia de momento. Saludos
-- rickygm
http://gnuforever.homelinux.com <http://gnuforever.homelinux.com>
participants (6)
-
Carlos E. R. -
Francisco F. -
Juan Erbes -
Pinguino Patagonico -
Rafa Griman -
Rick Gutierrez