Recuperar info despues de ser borrada con rm -r????

Aldrin Gonzalo Martoq Ahumada amartoq en dcc.uchile.cl
Lun Dic 24 18:11:09 CLST 2007


On Dec 24, 2007 3:48 PM, Roberto Leiva M. (Lista)
<rlm_lista en floresinternacional.cl> wrote:
> Aldrin Gonzalo Martoq Ahumada escribió:
> > On Dec 24, 2007 12:43 PM, Roberto Leiva M. (Lista)
> > <rlm_lista en floresinternacional.cl> wrote:
> >> Aldrin Gonzalo Martoq Ahumada escribió:
> >>> On Dec 24, 2007 4:26 AM, Ismael Cantieri <kaleimn en gmail.com> wrote:
> >>>> 2007/12/24, Alvaro Herrera <alvherre en alvh.no-ip.org>:
> >>>>> Lo que me pregunto es para que diablos estaria respaldando
> >>>>> /var/cache/apt ...
> >>>> Yo lo pedí pues hay que instalar otras maquinas y para no bajar
> >>>> actualización y paquetes en todas las maquinas.
> >>> Es mucho mejor configurar un cache web como squid para estas cosas.
> >> y no será mejor crear un repositorio local, y que todos los equipos se instalen/actualicen a traves
> >> de el.
> > En mi opinion no, pues en un repositorio local bajaras mas cosas de
> > las que necesitas (como saber que paquete usare?)
> Depende del tipo de instalacion, aca se utiliza para actualizar los servidores (15 aprox) y a veces
> las estaciones de usuario (100 aprox). Y respecto a saber que paquetes todo depende para que
> utilices la maquina.

Lo que relatas puede que sea bastante bueno para distros basadas en
redhat, pero no es el caso para distros basadas en Debian. Quien
pregunto esta usando Debian, no Fedora ni CentOS.

>   y el tiempo de
> > sincronizacion del repositorio local puede variar con el repositorio
> > maestro (si usas un cache web, se compara la fecha ~ cada vez que el
> > cliente pide un request [basado en eventos], en cambio el repositorio
> > local tendras que mantenerlo sincronizado mediante algun mecanismo
> > tipo crontab [basado en polling]).
> no veo lo complicado, un crontab en la noche con rsync y listo

No hay complicacion, solo asegurar tener lo mas fresco al momento
(lease actualizaciones de seguridad). Un rsync en la noche no me
asegura la frescura de un update a las 4 de la tarde. Un cache web si.

> > Por supuesto que si tienes muchas, muchas maquinas puedes darte el
> > lujo del ancho de banda y espacio en disco sobre-gastado;
> la idea es reducir el ancho de banda de internet, solo el mirror baja los paquetes y luego las
> estaciones y/o servidores se actualizan con el.
> Por lo del espacio en disco es despreciable, considerando lo economico que estan.
> Mirror Local:\
[...]
> en total 87 gb aprox

El cache web tambien reduce el ancho de banda de internet (no vuelves
a bajar de nuevo lo que ya bajaste, acelera los apt-get update -el
catalogo de paquetes-), la diferencia es que bajas menos cosas: solo
lo estrictamente necesario.

Esto es critico para el esquema de un repositorio Debian. De partida,
Debian posee muchos mas paquetes que Fedora y muchos mas que CentOS.
Ademas, la forma en que esta construido no es tan simple como bajar
debian/etch; acabo de medir pool en debian.utalca.cl; creo que pesa
112GB para i386 y x86_64 para unos 3 releases... aun no considero los
upgrade de seguridad ni los catalogos de paquetes... BTW alguien puede
dar numeros mas exactos?

Ademas, la idea no es descargar y tener esos 80, 120 GB de espacio (lo
cual me parece razonable para 150 estaciones, pero hay maneras mas
eficientes ;) ). Por ejemplo, cada vez que instalo Ubuntu al poco
tiempo estoy bajando 200-600 MB de actualizaciones (lo mismo que me
costo la instalacion inicial); asi que el mirror de instalacion es la
mayoria de las veces inutil en Debian: la instalacion inicial es
minima, asi que cuando bajes el paquete X no bajaras la version del
release, sino que la ultima version siempre.

Como la pregunta era para Debian, te aseguro en mi opinion que es
mucho mejor utilizar algun cache web en vez de crear un repositorio
local para todos, tanto para instalaciones pequen~as (un par de
maquinas tras un modem ADSL de 256KB) como grandes instalaciones.
Ademas que apt es mucho mejor que yum, hace unos meses utilice CentOS
5 con un mirror local bastante rapido (digamos 1000KiBi/seg) y yum era
tan tan tan lento y engorros que me desesperaba: se demoraba minimo 2
_minutos_ para cualquier cosa, incluso para el mensaje "no hay
updates"... Otra razon para migrar a Debian :P


-- 
Aldrin Martoq



Más información sobre la lista de distribución Linux