La importancia de particionar correctamente un disco en Linux

Soy un firme defensor de la simplicidad y del principio de que menos es más, pero en cuanto a la seguridad y el rendimiento de los sistemas de información se refiere, debemos ser capaces de encontrar un equilibrio entre mantener las cosas sencillas y exponernos lo mínimo posible a potenciales amenazas al mismo tiempo que tratamos de obtener las máximas prestaciones de los elementos que configuran nuestro sistema.

Viene siendo una práctica habitual que las distintas distribuciones de Linux, e incluso las imágenes a partir de las que poner en marcha instancias de servidores virtuales Linux como en el caso de las AMI’s de AWS, implementen por defecto un esquema de particionamiento de lo más simple basado en una única partición que ocupa todo el disco. Es en esa única partición donde se monta el sistema de ficheros raíz (/) y en el que se integran los principales directorios que configuran el sistema de ficheros de un sistema operativo Linux.

Pero una de las características de Linux es precisamente que permite ser enormemente flexible a la hora de ubicar cada uno de esos directorios en distintas particiones o en distintos discos si es necesario. Se puede ir incluso más allá y montarlos a través de la red en distintas máquinas emplazadas en distintas localizaciones geográficas. Y esto no es así por capricho, sino que se debe a que cada uno de los directorios del árbol raiz de Linux aloja archivos y librerías para llevar a cabo diferentes misiones con distintos objetivos y necesidades, por lo que englobarlos todos en una única partición puede ser interesante de cara a la simplicidad para usuarios que están empezando y no desean complicaciones. Pero si lo que quieres es ser un administrador de sistemas serio y ser capaz de desplegar sistemas críticos que sean fiables y seguros no va a quedar más remedio que complicarse la vida y definir una estructura de particiones y un esquema de opciones de montaje más sofisticado.

Distintas particiones para distintos cometidos

De todo el árbol de directorios que cuelgan del directorio raíz en un sistema Linux, hay algunos que merecen especial atención como candidatos a ser montados en un sistema de ficheros aparte:

/var

Una de las incidencias más frecuentes que ocurre en un sistema en producción, aun siendo fácilmente evitable, es el llenado al 100% de un sistema de ficheros y que ya no quede espacio disponible para escribir nuevos datos en él. De forma similar a como ocurre en un barco, que un compartimento se inunde puede ser algo muy desagradable, pero si el sistema está bien compartimentado el problema no pasará a mayores. Por el contrario, si no hay esta separación en compartimentos estancos, la inundación afectará a todo el conjunto y el barco se hundirá. De la misma manera, si nuestro sistema tiene una única partición y ésta se llena completamente, las aplicaciones no podrán seguir escribiendo datos a disco, por lo que pueden producirse todo tipo de situaciones con resultados imprevisibles, desde corrupción de datos por no poderse volcar el contenido de las cachés a disco, aplicaciones que dejan de funcionar por no poder escribir sobre ficheros temporales necesarios para su funcionamiento, o directamente el colapso de todo el sistema por no poder seguir funcionando correctamente el sistema operativo.

Error: Your Requested widget " ai_widget-6" is not in the widget list.

• [do_widget_area above-nav-left]
• [do_widget_area above-nav-right]
• [do_widget_area footer-1]
  • [do_widget id="wpp-4"]
• [do_widget_area footer-2]
  • [do_widget id="recent-posts-4"]
• [do_widget_area footer-3]
  • [do_widget id="recent-comments-3"]
• [do_widget_area footer-4]
  • [do_widget id="archives-4"]
• [do_widget_area logo-bar]
  • [do_widget id="oxywidgetwpml-3"]
• [do_widget_area menu-bar]
  • [do_widget id="search-3"]
• [do_widget_area sidebar]
  • [do_widget id="search-4"]
  • [do_widget id="ai_widget-2"]
  • [do_widget id="categories-5"]
  • [do_widget id="ai_widget-3"]
  • [do_widget id="ai_widget-4"]
  • [do_widget id="ai_widget-5"]
• [do_widget_area sub-footer-1]
  • [do_widget id="text-4"]
• [do_widget_area sub-footer-2]
• [do_widget_area sub-footer-3]
• [do_widget_area sub-footer-4]
• [do_widget_area upper-footer-1]
  • [do_widget id="search-2"]
  • [do_widget id="recent-posts-2"]
  • [do_widget id="recent-comments-2"]
  • [do_widget id="archives-2"]
  • [do_widget id="categories-2"]
  • [do_widget id="meta-2"]
• [do_widget_area upper-footer-2]
• [do_widget_area upper-footer-3]
• [do_widget_area upper-footer-4]
• [do_widget_area widgets_for_shortcodes]
  • [do_widget id="search-5"]
  • [do_widget id="ai_widget-6"]
• [do_widget_area wp_inactive_widgets]
  • [do_widget id="wpp-2"]
  • [do_widget id="text-1"]
  • [do_widget id="recent-posts-3"]
  • [do_widget id="categories-3"]
  • [do_widget id="archives-3"]
  • [do_widget id="icl_lang_sel_widget-3"]

El directorio /var es el más representativo de esta situación por ser el utilizado para almacenar los ficheros de log del sistema. Por tanto es típicamente de los que más escrituras recibe y el de mayor ritmo de incremento, por lo que si no se le presta la debida atención puede llegar fácilmente al límite de ocupación de la partición que lo aloja. Así, si no se separa del resto es fácil que en algún momento podamos sufrir una caída total del sistema.

También puede ser deseable separar en distintas particiones otros subdirectorios que cuelgan de /var por razones operativas, como /var/www para tener separados del resto del sistema los distintos sitios web alojados en un servidor web, el /var/lib/mysql para aislar nuestras bases de datos de posibles saturaciones que se den en /var, /var/log para aislar específicamente los ficheros de log, etc.

/tmp

Aparte de los problemas de denegación de servicio o de corrupción de datos mencionados en el punto anterior, hay problemas inherentes a la seguridad que se pueden atajar tan solo con configurar ciertas opciones de montaje en un sistema de ficheros. Por ejemplo, podemos anular ciertos tipos comunes de ataque impidiendo que se pueda establecer el flag setuid en los permisos de un fichero mediante la opción de montaje nosuid, se puede impedir la creación de ficheros de dispositivo con la opción nodev, o se puede impedir la ejecución de programas no permitiendo la activación del permiso de ejecución (x) en ningún fichero con noexec.

Todas estas opciones son altamente recomendables especialmente en el caso de /tmp, ya que por su naturaleza es un directorio al que puede acceder sin restricciones cualquier usuario del sistema, pues tiene permisos 777 o -rwxrwxrwx. Por tanto es un blanco fácil para que un atacante instale software malicioso en él y desde ahí pueda comprometer otras partes del sistema.

Al margen de la seguridad, puede resultar muy interesante de cara al rendimiento montar el directorio /tmp sobre un sistema de ficheros en memoria en lugar de en disco. Dado que muchas aplicaciones lo usan habitualmente para su funcionamiento normal, su rendimiento se verá mejorado si pueden leer los ficheros directamente desde la memoria RAM, mucho más rápida. Al final del artículo presento una propuesta de esquema de particionamiento teniendo en cuenta todos estos conceptos y principios, y en ella puede verse cómo montar el /tmp en memoria.

/home

Al igual que en el caso de /var, el directorio /home puede crecer sin control debido que es el lugar donde los usuarios almacenan sus documentos, y a no ser que establezcamos un sistema de cuotas, éstos pueden fácilmente llenarlo por completo, ya sea de forma voluntaria o involuntaria. Esto provocaría el colapso del sistema si no lo llevamos a una partición aparte. Pero además, precisamente porque es otro lugar donde los usuarios pueden escribir libremente, también ofrece peligros potenciales parecidos a los de /tmp, por lo que es recomendable establecer las opciones de montaje nosuid y nodev. La activación de la opción noexec dependerá del uso que se les vaya a permitir hacer a los usuarios de su directorio personal. Desde luego a priori sería mejor no permitirles ejecutar ningún programa, pero en muchas ocasiones será legítimo que los usuarios puedan hacerlo, y de hecho puede ser un requisito imprescindible.

Lo que sí es conveniente entonces es activar las opciones acl y user_xattr para poder establecer reglas de control de acceso a los ficheros más sofisticadas y hacer uso de los atributos extendidos de usuario.

Error: Your Requested widget " ai_widget-6" is not in the widget list.

• [do_widget_area above-nav-left]
• [do_widget_area above-nav-right]
• [do_widget_area footer-1]
  • [do_widget id="wpp-4"]
• [do_widget_area footer-2]
  • [do_widget id="recent-posts-4"]
• [do_widget_area footer-3]
  • [do_widget id="recent-comments-3"]
• [do_widget_area footer-4]
  • [do_widget id="archives-4"]
• [do_widget_area logo-bar]
  • [do_widget id="oxywidgetwpml-3"]
• [do_widget_area menu-bar]
  • [do_widget id="search-3"]
• [do_widget_area sidebar]
  • [do_widget id="search-4"]
  • [do_widget id="ai_widget-2"]
  • [do_widget id="categories-5"]
  • [do_widget id="ai_widget-3"]
  • [do_widget id="ai_widget-4"]
  • [do_widget id="ai_widget-5"]
• [do_widget_area sub-footer-1]
  • [do_widget id="text-4"]
• [do_widget_area sub-footer-2]
• [do_widget_area sub-footer-3]
• [do_widget_area sub-footer-4]
• [do_widget_area upper-footer-1]
  • [do_widget id="search-2"]
  • [do_widget id="recent-posts-2"]
  • [do_widget id="recent-comments-2"]
  • [do_widget id="archives-2"]
  • [do_widget id="categories-2"]
  • [do_widget id="meta-2"]
• [do_widget_area upper-footer-2]
• [do_widget_area upper-footer-3]
• [do_widget_area upper-footer-4]
• [do_widget_area widgets_for_shortcodes]
  • [do_widget id="search-5"]
  • [do_widget id="ai_widget-6"]
• [do_widget_area wp_inactive_widgets]
  • [do_widget id="wpp-2"]
  • [do_widget id="text-1"]
  • [do_widget id="recent-posts-3"]
  • [do_widget id="categories-3"]
  • [do_widget id="archives-3"]
  • [do_widget id="icl_lang_sel_widget-3"]

Otra característica interesante relacionada con la seguridad que nos permitirá la división en diferentes particiones es la posibilidad de cifrar el contenido de /home y poner a salvo así nuestros documentos personales aunque el resto de particiones no estén encriptadas. Es cierto que siempre podríamos encontrar un mecanismo alternativo para cifrar el contenido de nuestro directorio personal, pero tenerlo separado en una partición aparte facilita esta labor y en mi opinión es más elegante.

/boot

En /boot están alojados tanto el cargador de arranque del sistema como los distintos kernels que tengamos instalados en nuestro sistema. Su contenido no se utiliza en la operación normal del sistema, sólo en el arranque del mismo, y debe poder ser leída directamente por la BIOS para la máquina pueda arrancar correctamente. Este requerimiento hace por tanto imprescindible tener una partición dedicada para /boot en algunos casos, por ejemplo si estamos usando volúmenes RAID o LVM y nuestra BIOS no soporta el arranque directo desde ese tipo de volúmenes, o si necesitamos que el sistema de ficheros raíz (/) esté encriptado, pues tanto el bootloader como el kernel no pueden ser cifrados y deben ser accesibles de forma sencilla y directa por la BIOS. También si la BIOS es antigua puede tener la limitación de que la partición de arranque sólo pueda ocupar los primeros 1.024 cilindros de disco, por lo que si nuestro disco es muy grande esta limitación puede hacer obligatorio que disponer de una partición pequeña al comienzo del disco sobre la que montar el directorio /boot.

En sistemas más modernos que disponen de UEFI en sustitución de la antigua BIOS es necesario disponer de una partición formateada con sistema de ficheros FAT32 o vfat en /boot/efi para cumplir con el estándar EFI y poder almacenar distintos cargadores de arranque y drivers que permitan que la máquina pueda arrancar múltiples sistemas operativos.

Por tanto, aunque no es imprescindible en la mayoría de los casos, sí es recomendable disponer de una partición dedicada para /boot y otra para /boot/efi para tener mayor flexibilidad a la hora de hacer cambios sobre un sistema existente. Desde el punto de vista de la seguridad también nos puede servir para aplicar una capa adicional de protección montando los sistemas de ficheros /boot y /boot/efi como sólo lectura con la opción de montaje ro, o directamente no montarlos (opción noauto), ya que como decía al principio sólo se necesitan en el arranque y no durante el funcionamiento normal. De esta forma un atacante no podría alterar el arranque del sistema, y aunque el sistema de permisos de Linux ya se encarga de impedir cualquier modificación a usuarios que no sean root, esto es como digo una capa adicional de seguridad.

Una medida más eficaz sería instalar el gestor de arranque grub y las particiones /boot y /boot/efi en un dispositivo distinto que permita activar el modo de sólo lectura a nivel físico, como por ejemplo en una tarjeta SD con interruptor de bloqueo de escritura, o en entornos virtualizados, mediante por ejemplo volúmenes inmutables o cuyo modo de sólo lectura pueda controlarse desde el hipervisor y no desde la instancia virtualizada. De esta forma sería imposible para un atacante alterar el arranque de nuestra máquina sin tener acceso físico a ella o al hipervisor.

/usr

La razón más interesante por la que separar el sistema de ficheros /usr es poder establecer opciones de montajes nodev o errors=remount-ro, lo que permitirá que se monte en modo sólo lectura si se produce algún error en el arranque del sistema y aumentar así las probabilidades de que un sistema defectuoso llegue a arrancar y nos permita intentar recuperarlo y/o salvar cierta información.

Es importante señalar que en algunas distribuciones como Fedora se está haciendo un esfuerzo por modificar el estándar de facto que suponía tener algunos directorios como /bin o /lib colgando directamente de / y llevarlos a través de un enlace simbólico a /usr/lib o /usr/bin. Por tanto, en estos casos puede no ser recomendable separar /usr y mantenerlo en la misma partición que /.

/data

Imaginemos que necesitamos almacenar información con características muy específicas que hagan recomendable usar un sistema de ficheros distinto al habitual ext4, por ejemplo. Imaginemos que necesitamos montar un servidor de ficheros destinado a almacenar archivos de gran tamaño como vídeos o fichero .tar.gz de gran tamaño. En ese caso puede resultar más indicado usar un sistema de ficheros que ofrezca un mejor rendimiento a la hora de manejar ficheros de gran tamaño, como por ejemplo XFS. También podríamos encontrarnos en la necesidad de usar alguna de las características específicas para las que han sido optimizados otros sistemas de ficheros, como la posibilidad de tomar snapshots o instantáneas de nuestros datos, compresión de datos de forma transparente, o desfragmentación en línea, para lo cual usaríamos otros tipos de filesystems como ZFS o BtrFS.

swap

Aunque es posible establecer áreas de intercambio o swap directamente en ficheros y almacenarlos en cualquiera de los directorios del sistema, lo más habitual es destinar una partición específicamente para este cometido, lo cual tiene la ventaja de poder llevar el área de intercambio a otro dispositivo más adecuado. Por ejemplo, si para nosotros es muy importante minimizar la penalización de rendimiento que se produce cuando el sistema de queda sin memoria RAM y comienza a paginar o «swapear», podríamos llevar la partición de swap a un disco SSD a pesar de que hoy por hoy eso suponga acortarle la vida. Por el contrario, si nuestra máquina dispone de memoria RAM de sobra, podemos destinar los discos SSD a otras particiones donde su uso será más productivo y utilizar un disco magnético de bajo coste para el área de intercambio, ya que su uso será más infrecuente al no haber escasez de RAM.

Desde el punto de vista de la seguridad puede ser interesante usar algún mecanismo de cifrado como Cryptswap para proteger los datos temporales alojados en el área de intercambio, pues puede tratarse de información sensible.

Sistema de ficheros raíz o /

Por último, y a propósito del sistema de ficheros raíz, me gustaría puntualizar que no todos los directorios que cuelgan de / son susceptibles de ser separados en distintas particiones. Hay directorios como /etc, /lib o /bin que nunca deben ubicarse en particiones separadas y deben ser todos parte de este sistema de ficheros ráiz.

Otros motivos por los que establecer un esquema de particionamiento

Además de las ventajas ya expuestas en puntos anteriores, crear un buen esquema de particionamiento puede ofrecernos posibilidades adicionales:

Flexibilidad

Es posible que nos equivoquemos en nuestra previsión inicial en cuanto al espacio que va a ser necesario destinar a cada una de las particiones de nuestro esquema de particionamiento, pero al mismo tiempo esto nos proporcionará de gran flexibilidad a la hora de redimensionar el espacio cuando detectemos que una partición se nos queda corta o que por el contrario tiene demasiado espacio que nunca llegaremos a utilizar.

Redundancia de datos

Hay sistemas de ficheros que puede ser necesario duplicar (mirroring), o que requieran incluso el uso de algún sistema de ficheros distribuido como GlusterFS o CephFS,

Sistema de ficheros en red

Mediante el uso de herramientas como Samba o NFS es posible compartir en red el contenido de un sistema de ficheros. Aunque es posible compartir sólo una parte de él, es decir, un subdirectorio, esto hace más complicado gestionar la seguridad y es más recomendable emplear una partición específica para este cometido.

Error: Your Requested widget " ai_widget-6" is not in the widget list.

• [do_widget_area above-nav-left]
• [do_widget_area above-nav-right]
• [do_widget_area footer-1]
  • [do_widget id="wpp-4"]
• [do_widget_area footer-2]
  • [do_widget id="recent-posts-4"]
• [do_widget_area footer-3]
  • [do_widget id="recent-comments-3"]
• [do_widget_area footer-4]
  • [do_widget id="archives-4"]
• [do_widget_area logo-bar]
  • [do_widget id="oxywidgetwpml-3"]
• [do_widget_area menu-bar]
  • [do_widget id="search-3"]
• [do_widget_area sidebar]
  • [do_widget id="search-4"]
  • [do_widget id="ai_widget-2"]
  • [do_widget id="categories-5"]
  • [do_widget id="ai_widget-3"]
  • [do_widget id="ai_widget-4"]
  • [do_widget id="ai_widget-5"]
• [do_widget_area sub-footer-1]
  • [do_widget id="text-4"]
• [do_widget_area sub-footer-2]
• [do_widget_area sub-footer-3]
• [do_widget_area sub-footer-4]
• [do_widget_area upper-footer-1]
  • [do_widget id="search-2"]
  • [do_widget id="recent-posts-2"]
  • [do_widget id="recent-comments-2"]
  • [do_widget id="archives-2"]
  • [do_widget id="categories-2"]
  • [do_widget id="meta-2"]
• [do_widget_area upper-footer-2]
• [do_widget_area upper-footer-3]
• [do_widget_area upper-footer-4]
• [do_widget_area widgets_for_shortcodes]
  • [do_widget id="search-5"]
  • [do_widget id="ai_widget-6"]
• [do_widget_area wp_inactive_widgets]
  • [do_widget id="wpp-2"]
  • [do_widget id="text-1"]
  • [do_widget id="recent-posts-3"]
  • [do_widget id="categories-3"]
  • [do_widget id="archives-3"]
  • [do_widget id="icl_lang_sel_widget-3"]

Sistema de cuotas más potente

Las cuotas de uso de disco se establecen por usuario y partición, por lo que para establecer un buen sistema de cuotas es más interesante planificar un buen esquema de particionamiento para poder asignar distintas cuotas a un mismo usuario para /home, /tmp o /var, por ejemplo.

Realización de backups

Al margen de la posibilidad de realizar snapshots ya comentada anteriormente, la realización de copias de seguridad en un sistema suele ser más sencilla si éste está dividido en diferentes particiones, pues hay herramientas de backup que funcionan específicamente a nivel de partición, es más fácil dimensionar el espacio necesario para dichos backups al estar limitado al tamaño de las particiones, ciertas particiones permiten ser desmontadas sin afectar al resto del sistema con el fin de respaldar de forma consistente su contenido impidiendo que se sigan escribiendo datos mientras dura la operación, etc.

Mantenimiento más sencillo

Es conveniente realizar de forma períodica una comprobación de la integridad del sistema de ficheros con herramientas como fsck. Del mismo modo que a la hora de realizar backups, si podemos desmontar ciertas particiones bajo demanda y realizar el chequeo de forma consistente y sin necesidad de reiniciar el sistema, las labores de mantenimiento del mismo se ven facilitadas.

Mejor aprovechamiento de la geometría de los discos

Los cilindros exteriores de los discos giran a mayor velocidad que los interiores, por lo que los primeros ofrecen un mejor rendimiento que los segundos. Es interesante colocar las particiones más utilizadas en los cilindros exteriores. Dado que los cilindros empiezan a numerarse por el exterior, esto quiere decir que es mejor poner las particiones que se van a usar más intensivamente al principio del disco y al final las menos utilizadas. También puede ser interesante colocar las particiones más utilizadas en el medio, de forma que las cabezas tengas que desplazarse menos y aumentar así a la larga el tiempo de vida de los discos.

Mi propuesta de esquema de particionamiento

Para terminar voy a presentar a modo de ejemplo el fichero /etc/fstab y la salida del comando df -h correspondiente a dos esquemas de particionamiento distintos: uno para un disco de tamaño medio (55 GB), y otro para un disco de mayor tamaño (250 GB). A parte de que te sirva como punto de partida para empezar a definir tu propio esquema, esto lo hago también para ilustrar la idea de que un sistema Linux estándar no requiere de una gran capacidad de almacenamiento para funcionar a pleno rendimiento y con garantías de crecimiento futuro, pues las particiones principales tiene un tamaño de un orden similar, dejando la mayor parte del espacio de los discos más grandes disponible para las aplicaciones del usuario.

Ambas propuestas corresponden a sistemas reales basados en sistema operativo Ubuntu 16.04.2 LTS.

Fichero /etc/fstab

# /etc/fstab: static file system information. 
# 
# Use 'blkid' to print the universally unique identifier for a 
# device; this may be used with UUID= as a more robust way to name devices 
# that works even if disks are added and removed. See fstab(5). 
# 
# <file system> <mount point>   <type>  <options>       <dump>  <pass> 
# / was on /dev/sda2 during installation 
UUID=7d5ba82c-3085-49e2-b662-6a133ad8e9bf  /              ext4    defaults,discard,noatime,errors=remount-ro     0       1 
# /boot was on /dev/sda3 during installation 
UUID=7919506c-a13c-4a2c-b27a-8984edd28484  /boot          ext4    defaults,noatime                               0       2 
# /home was on /dev/sda8 during installation 
UUID=2efc9c4c-5e24-4be5-8076-1135576583f0  /home          ext4    defaults,noatime,acl,user_xattr,nodev,nosuid   0       2 
# /tmp was on /dev/sda5 during installation
#UUID=1e9e3d25-7988-435c-954d-601ea59bd6fd /tmp           ext4    defaults,nodev,noexec,nosuid                   0       2 
tmpfs                                      /tmp           tmpfs   defaults,nodev,noexec,nosuid,size=512m         0       0 
# /usr was on /dev/sda6 during installation 
UUID=02dd782a-0c87-4f2d-b7d0-b0b1f9bc2982  /usr           ext4    defaults,noatime,nodev,errors=remount-ro       0       2 
# /var was on /dev/sda7 during installation 
UUID=b3595283-11ee-4965-8948-b862000678a8  /var           ext4    defaults,noatime,nodev,nosuid                  0       2 
# /var/www was on /dev/sda9 during installation 
UUID=27eec030-7a45-43a6-8594-d6112e92c345  /var/www       ext4    defaults,noatime,acl,user_xattr,nodev,nosuid   0       2 
# swap was on /dev/sda4 during installation 
UUID=47c588d7-4a4a-4f30-8f91-e653cb27e94c none            swap    sw                                             0       0 
#/dev/mapper/cryptswap1 none swap sw 0 0 
UUID=95b03a51-f0d2-4196-bb54-036cba2d166d /var/data       ext4    defaults,noatime,acl,user_xattr,nodev,nosuid   0       2

Propuesta de particionamiento para un volumen de 55 GB

Filesystem      Size  Used Avail Use% Mounted on 
udev            2.0G     0  2.0G   0% /dev 
tmpfs           396M   41M  355M  11% /run 
/dev/xvda1      7.8G  757M  6.6G  11% / 
/dev/xvda6      4.8G  1.5G  3.1G  33% /usr 
tmpfs           2.0G     0  2.0G   0% /dev/shm 
tmpfs           5.0M     0  5.0M   0% /run/lock 
tmpfs           2.0G     0  2.0G   0% /sys/fs/cgroup 
tmpfs           128M  112K  128M   1% /tmp 
/dev/xvda7       30G   13G   16G  46% /var 
/dev/xvda5      3.9G  515M  3.1G  14% /home 
cgmfs           100K     0  100K   0% /run/cgmanager/fs 
tmpfs           396M     0  396M   0% /run/user/1000

Propuesta de particionamiento para un volumen de 250 GB

S.ficheros              Tamaño Usados  Disp Uso% Montado en 
udev                      7,8G      0  7,8G   0% /dev 
tmpfs                     1,6G    97M  1,5G   7% /run 
/dev/sda2                 9,1G   1,8G  6,9G  21% / 
/dev/sda6                  23G   6,8G   15G  32% /usr 
tmpfs                     7,8G   851M  7,0G  11% /dev/shm 
tmpfs                     5,0M   4,0K  5,0M   1% /run/lock 
tmpfs                     7,8G      0  7,8G   0% /sys/fs/cgroup 
tmpfs                     512M    42M  471M   9% /tmp 
/dev/sda3                 2,3G   236M  1,9G  11% /boot 
/dev/sda7                  16G   8,6G  6,6G  57% /var 
/dev/sda9                 124G   103G   15G  88% /var/www 
/dev/sda8                  46G    24G   20G  55% /home 
/dev/sdb1                 917G   828G   44G  96% /var/data 
tmpfs                     1,6G      0  1,6G   0% /run/user/118 
tmpfs                     1,6G    72K  1,6G   1% /run/user/1000 
/home/daniloaz/.Private    46G    24G   20G  55% /home/daniloaz