Particionar 80 Gb para mailserver?

[Aldrin Martoq]

On Tue, 2008-02-05 at 22:50 -0300, Germán Poó-Caamaño wrote:
> On Tue, 2008-02-05 at 20:40 -0300, Aldrin Martoq wrote:
> > De mi experiencia, estoy en contra de "sobre-particionar" cualquier
> > instalación. / y /usr/bin y /boot no tiene mucho sentido separarlas.
> > Además, tengo la sensación que LVM es algo lento (fueron unas pruebas
> > rápidas, no tengo números).
> > 
> > Mi recomendación es la siguiente:
> > / 5-10GB para S.O. (incluye /boot /bin /usr /etc /lib ... de sobra)
> > /tmp es buena idea separarlo (en particular si los usuarios acceden la
> > máquina), pero no estrictamente necesario... te recomiendo 5GB si lo
> > separas, o sumalos a / con 15GB en total
> > /var 65 GB (lo que sobra) Ahi tendras la base de datos y el correo.
> En estas situaciones /tmp *debe* estar separado.  Es mejor que se
> llene /tmp a quedarse sin espacio en /.  Además que lo que está en
> /usr, /lib, /etc, /bin y /boot suelen ser contenido estáticos; mientras
> que /tmp es altamente dinámico.

Esto es parte del "folklore y mitos" heredados de tiempos antigüos y
oscuros. Es como el clásico swap = 2*RAM o calcular el tamaño de una
máquina en SUMx*30%. Hoy en día la situación es MUY diferente.

Hagan la prueba. Llena / como usuario y como root (si usas ext3). Podrás
ingresar al sistema sin problemas y resolver la situación. Si, digamos,
el software de webmail no funciona porque se llenó /tmp da lo mismo si
esta en otra partición o en /: igual no va a funcionar en *ambas
situaciones*, asi que pierdes ese servicio igual.

Desde esta perspectiva, es mejor agrandar el espacio de /tmp. Y para
eso, lo dejas en /. Asi, si dejas 15GB como en mi ejemplo, en la
práctica tendrás mucho mas que 5GB de /tmp y las ocurrencias de este
tipo serán menores.

Distinto es el caso que los usuarios accedan a la máquina. Muchas
aplicaciones "de usuario" usan archivos temporales (hacer un "lsof -n"
en tu escritorio gnome) o los usuarios intencionalmente llenan los
temporales (solía dejar archivos en /var/tmp cuando no tenía donde
dejarlos...). Pero no deberías dar acceso a nadie en un servidor de
mail, mucho menos usar un ambiente gráfico... y deberías usar alguna
distro debian o basada en, que están mejor pensadas en varios aspectos
(en particular, borran /tmp al reiniciar la máquina ;) ).


> > Si deseas, puedes poner /var en LVM para futuros "agrandamientos"... /
> > no es necesario, 10 GB es suficiente.
> En un servidor de correo, debiera estar separado /var de 
> /var/donde/se/alojan/los/buzones.  Por ejemplo, /var/mail (para un
> sistama tradicional como wu-imap, /var/spool/cyrus
> 
> Así tienes control del espacio que
> ocupan los buzones, respecto de /var/tmp, /var/log, /var/cache, etc.
> Sería lamentable que los usuarios no pudieran recibir correos porque
> un archivo de logs creció demasiado.
> 
> /var/spool no es necesario que vaya aparte, nunca crece tanto. A menos
> que se vayan a quedar sin Internet por un mes y la gente siga enviando
> correos hacia el exterior.  En el sentido inverso, los mensajes suelen
> despacharse rápidamente.
> 
> Dado que quiera instalar MySQL, desconozco donde CentOS crea las
> bases de datos para MySQL, pero si fuera en /var/lib; tal vez se
> deba considerar si vale la pena una partición individual para
> /var/lib.  No creo que vaya a ocupar mucho espacio en todo caso.

Siento lo mismo que la respuesta de arriba... Si no puedes
escribir /var/log, de todas formas estás mal. Para el caso del correo,
no podrás recibir pero el host que envía se queda esperando un par de
días o el correo rebota. Para el caso de enviar, chilla altiro... Si
quieres "controlar" el espacio de los correos, primero declara políticas
de buen uso. Es mejor educar (lo dices un par de veces a todos tus
usuarios) que estar jugando al paco y al ladrón (cada vez que alguien
rompla la regla de cuota de disco, te preguntaran las N veces que pase
"por qué no puedo recibir correo???").




Insisto en la idea que es más fácil administrativamente unir los
espacios (particiones) que separarlos ya que todos los huecos libres se
aprovechan mejor y el sistema tiende menos a caerse porque se llenó un
sistema de archivos, sobre todo cuando no cuentas con un "gran" espacio.

O viéndolo al reves: cuando tiendes a "sobre-particionar" son mas
ocurrentes los problemas de discos al tope o casi llenos, usualmente
porque no pudiste adivinar el espacio que realmente requerían.

Por supuesto, es mi opinión y experiencia, quizás he tenido demasiada
suerte? ;)

> > [...]
> > Otra cosa importante: un sistema de respaldos mínimo mensual y ojalá
> > semanal. Lo que sea (DVD's, segundo disco, cintas, ...). El contenido
> > del correo para muchos de los usuarios es muy valioso para su trabajo.
> > Esto independiente que compres mas discos y armes algún arreglo como
> > raid o controladoras con baterías, ups, etc... Aún asi, alguien puede
> > borrar un correo y ser fatal si este no se encontraba en algún
> > respaldo.
> 
> Si alguien borró un correo, me parece complicado poder recuperarlo
> de un respaldo como el que indicas.  Es más, ni siquiera lo 
> anunciaría como servicio. Sólo útil si la ventana de tiempo en que
> el usuario borró el correo y el respaldo coinciden; de lo contrario,
> nada.
> 
> Es útil en situaciones cuando el disco falla.  Los usuarios de todas
> formas perderán correos, pero no todos.
> 
> Para poder recuperar los correos de los usuarios como servicio, 
> debieras tener otro lugar en donde recibir todos los correos y
> mantenerlos entre respaldos.

Claro que depende de que nivel de "seguridad" quieras/necesitas ofrecer,
pero un respaldo mensual no es caro. En muchas empresas e instituciones
el correo es muy vital para el negocio, de hecho una de las frase
típicas es "formalízalo por correo"...


> En todo caso, respaldar 30, 40 ó 50+ GB en DVD, debe ser ligeramente
> doloroso ;-)

No, no es descabellado: Un DVD es perfecto y bastante rápido para algún
sistema de respaldos incremental; la lata es lo manual: hay que meter y
sacar el disco. No me pregunten cuales (STFW), pero existen...


-- 
Aldrin Martoq <amartoq en dcc.uchile.cl>