Historias de terror con copias de seguridad

[Baku]

Mira, no sabia yo que el + ese existia y podia hacer como de xargs. Cosas que se aprenden. Y tambien puedes tirar procesos en paralelo con xargs, pero ya me parece demasiado. Voy a hacerme unas pruebas a ver. Y el -print0 me lo pide el cacharro para el find y un -0 con el xargs.

Sí­, eso también.

[patillotes]

% time rm -f gato*
0.247u 4.564s 0:27:05 17.7% ....

[patillotes]

% time find . -type f -name "gato*" -exec rm {} +
0.209u 4.795s 0:26:51 18.8% ...

---------

Es curioso, pero el rm a palo ha funcionado. Estoy con una maquina virtual de freebsd. ¿Tienes algun linux a mano para probar si desborda el numero de argumentos, Baku?

[patillotes]

y el time de (lo he metido en un escript, que no tengo ganas de jugar a escapar caracteres y tal):

find . -type f -name "gato*" -print0 | xargs -0 -P 4 rm
0.114u 4.345s 0:25.94 17.1% ...

Tirando cosas en paralelo. Y acabo de darme cuenta que he escrito mal los formatos de los archivos. Voy a ver con un solo proceso y reescribo el escript, que le cuesta un huevor.

[patillotes]

para:

find . -type f -name "gato*" -print0 | xargs -0 rm -f
0.173u 4.421s 0:27.01 16.9% ...

---------------------------------

El mejor a palo es el find como decias. Si te pones a tirar procesos en paralelo si que parece ir mejor el xargs. Al menos he descubierto la opcion esa del +, que no la conocia y tal.

[Baku]

time find . -type f -name "gato*" -exec rm {} +

real   0m0.198s
user   0m0.030s
sys   0m0.160s

sin el "+"
time find . -type f -name "gato*" -exec  rm -f {} \;

real   0m13.911s
user   0m4.600s
sys   0m10.000s

con xargs:

real   0m0.149s
user   0m0.010s
sys   0m0.150s
...
...
...
...

Pues no me sale el error, cagontó. El caso es que ayer mismo, en el curro, haciendo algo igual, pero cambiando permisos en vez de borrar archivos  me cantó.

[patillotes]

Parece que el rm admite miles (¿numero arbitrario?) de argumentos. Groar. A mi tambien me han petado cosas por numero de argumentos, como a todo cristo haciendo limpiezas y tal.

Voy a ver donde lo tiene, proxima parada 50k.

[Baku]

Parece que el rm admite miles (¿numero arbitrario?) de argumentos. Groar. A mi tambien me han petado cosas por numero de argumentos, como a todo cristo haciendo limpiezas y tal.

Voy a ver donde lo tiene, proxima parada 50k.

Yo he llegao hasta 30k y buscando desde /. Ya paso, El martes, cuando vuelva,  me repasare el history a ver si es que estaba metiendo la pata en algo.

[patillotes]

FreeBSD 8 peta con 50k argumentos para rm. He leido por ahi que no es cosa de los comandos (rm, etc) sino del kernel, que no deja pasar de noseque tamaño del buffer y blabla.

[al bundy]

find . -type f -name "gato*" -print0 | xargs -0 rm â€"f

A mí­ me parece una temeridad innecesaria usar esta instrucción. Te arriesgas a que cualquier error, ya sea de escritura, por prisas, por resaca o carácter no escapado te lie un pollo del copón. Y como no redirecciona la salida al terminal, te das cuenta del error cuando ya no tiene arreglo.

Yo hago lo mismo, pero en lugar de empiparlo hací­a rm, lo redirecciono a un fichero. Le echo un vistazo al archivo a ver que no se me haya colado nada imprevisto (como aquello que decí­as de los mp3) y luego los borro uno por uno con un sencillo script con for- while-do-done - etc…) Así­ tampoco tendrás lí­mites de argumentos. A ver si mañana en el curro me acuerdo de pegarte algún ejemplo.


Otro truquillo para el find:

Si tienes una máquina en la que se creen pocos archivos nuevos (como un servidor de bases de datos), es una buena práctica hacer un find desde /  y enviarlo a /tmp/indice.txt . Cuando quieras localizar un fichero, sólo tienes que hacer un:

grep â€"i nombre-de-fichero /tmp/indice.txt.

Naturalmente, puedes crear tantos ficheros como quieras: por tipo, por tamaño … Lo puedes programar cada noche en el cron y cada mañana tendrás los ficheros actualizados.

Es mucho más rápido y le ahorrarás rascadas al disco.

grep/egrep/fgrep: probablemente, el comando más útil de unix.

[al bundy]

¿Y cuanto vale una unidad de cinta ultrium?, por seguir con el acojone a la muchachada.

- La unidad en si no es muy cara (así­ de memoria, 1500- 2000 euros, ni me acuerdo). Lo jodido son las cintas, que salen a 40 â,¬ cada una y necesitas 15 como mí­nimo para una rotación cutrilla (8 diarias, 4 semanales, 2 mensuales y 1 anual) o 25 para hacerlo como dios manda, siempre que no haya bases de datos por medio. Además, hay que renovarlas cada cierto número de usos y comprar cintas limpiadoras y de repuesto.

- Ahora que leo a Yonon, se me ha ocurrido un error tí­pico: las cintas no pueden estar jamás en la misma estancia que el servidor. Se deben retirar cada mañana y guardarlas en un sitio diferente. Cuando tienes un robot de copias, da mucha grima hacerlo, pero también es necesario. En mi curro, dejamos las diarias en el robot indefinidamente, pero cada lunes retiramos la copia semanal. Si hay pollo en el CPD te puedes quedar sin nada: a mí­ se me llego a prender fuego en el SAI, y gracias que tenemos el gas halon.

- Otra buena práctica que tenemos implementada es intercambiarnos las cintas mensuales entre CPD's, por si hay un 11S o un terremoto. También hacemos una replicación nocturna de bases de datos entre las EVA's de los CPD's y nos cruzamos los archivers de oracle cada hora.

- Las cintas, en armario de seguridad: el nuestro aguanta una caí­da de siete pisos y es totalmente igní­fugo.

- Hacer pruebas de restauración periódicamente. Yo no lo hago, pero es canónico.

Todo esto es muchí­sima pasta, pero cuando guardas información de 10, 15 o 20 años resulta imprescindible.

En cualquier caso, acojónalos: no tener copia de seguridad es despido justificado.

[patillotes]

Antes de lanzar una tuberia asi le pongo un less al final o un grep, tampoco me voy cepillando las cosas en plan automatico y tal. Y eso de barato es otra cosa que quiero que pillen, 2000â,¬ es 4 o 5 ordenadores de los que gastan ellos.

A ver si el acojoune funciona. El examen sera practico, ya les he dicho que se lo monten como quieran, llevare una imagen de disco con un pogamra destructor, que hagan las copias como quieran y que luego corran el bicho y restauren. A ver que tal lo hacen.