En esta semana nos encontramos con un escenario muy particular relacionado con comandos Import/Export SPWeb en SharePoint 2010. Al correr Export-SPWeb o Import-SPWeb el proceso en algún punto marcaba error y la razón fue porque la unidad C: llegaba a su capacidad máxima de almacenamiento.
Es increíble, ya que es bien sabido que debemos contar con volúmenes de disco duro adicionales para guardar los LOGS de SharePoint y en el caso de la base de datos los LOGS y MDFs de SQL. Además, la unidad C: solo es para guardar los archivos del sistema y debemos tener libre el doble equivalente de memoria RAM en capacidad de almacenamiento en disco duro. En otras palabras, si tengo 8GB de RAM, siempre debería tener por lo menos 16GB de espacio almacenamiento libre en C:
Entonces si tengo el almacenamiento de mi servidor de aplicaciones debidamente configurado con diversos volúmenes e incluso con cierto nivel de RAID, ¿porque se llena el disco duro al ejecutar comandos Import-SPWeb y Export-SPWeb?
Resulta que estos comandos son la alternativa disponible para mover sitios web de SharePoint entre colecciones de sitio, son capaces de mover permisos, contenido, versiones, workflows, etc. En estos tiempos donde muchas empresas carecen de gobernabilidad y planeación de un servicio SharePoint es común ver sitios web de SharePoint realmente grandes con una jerarquía de sitios muy profunda y desde la perspectiva de almacenamiento realmente enormes y esto tiene una implicación importante a considerar cuando trabajamos con Import-SPweb y Export-SPWeb. En realidad y de forma interna estos comandos hacen uso de una funcionalidad pre-construida en SharePoint llamada Content Deployment.
Content Deployment ofrece una alternativa para mover contenido de un lugar a otro y cuenta con todo un proceso para realizarlo. Este proceso es invocado tanto por los comandos Import-SPWeb, Export-SPWeb, Content Deployment del Central Administracion, los respaldos granulares y el modelo de objetos de SharePoint entre otros. En primer instancia este proceso requiere de varios atributos como tipo de exportación (full o incremental), sitios o contenido que será incluido, rutas y paths de archivos donde se exporta el contenido y los logs de los procesos, entre otras opciones de configuración. El caso es que en algún punto, este proceso construye un archivo XML que describe todas las instrucciones detalladas de exportación o importación que proceso deberá seguir y por consiguiente si el sitio a exportar es muy grande, este archivo y algunos otros temporales que genera lo será también. Y bueno, ¿En dónde crees que estos archivos tras bambalinas se almacenan de forma temporal? Pues en el TEMP del usuario firmado y ¿En dónde se almacena el TEMP del usuario firmado? Pues en el disco duro C: y he ahí la razón.
Una alternativa de solución a esto es modificar la variable de entorno TEMP para que su ruta de almacenamiento apunte a una unidad que si tenga la capacidad de almacenamiento necesaria para soportar nuestros procesos de importación y exportación.
También si estás trabajando con PowerShell puedes usar $env:temp para obtener la ruta del TEMP y modificarla usando set-item -path env:temp -value "F:TEMP".
Cosas de la vida! Saludos
UPDATE: Existe el switch NoFileCompression que podemos utilizar para evitar que de forma temporal se generen los archivos adicionales que se comentaron durante el post. Por default, NoFileCompression es False y esto genera en la carpeta TEMP los archivos temporales previos a los que genera el proceso. Este switch lo deberas especificar tanto en Export-SPWeb como Import-SPWeb.
Originalmente publicado en msmvps.com
