Jugando con las bases de datos de contenido de SharePoint

¿Hay alguien que no tenga a estas alturas experiencia con atachar y desatachar (¿Asociar y desasociar en castellano?) bases de datos de contenido del SharePoint? Sí hay alguien, de hecho hay mucha gente.
Gracias a esto es fácil hacer backups y restores con las herramientas de SQL, mover las bases de datos a otros servidores, por ejemplo para ampliar granjas, guardar los datos en una cinta y olvidarte de ellos hasta el día que te hagan falta y todos los procesos que se te ocurran con bases de datos con tranquilidad fiabilidad y en cuestión de segundos (quizá más de 60, o más de 86400 segundos si las bases de datos son realmente gordas).
¿Que pasa si la base de datos de contenido de tu SharePoint crece tanto que no cabe en el disco duro que la alberga? pues que nos compramos un disco duro más gordo y la movemos a el.
Por ejemplo, el caso más extremo que se me ocurre es desplegar una base de datos en una granja diferente y ¿quién dijo miedo? es el que intentaré reflejar en este post (lo malo es que en mi casa solo tengo una VM, pero bueno intentaré simularlo lo mejor posible).
Lo primero que necesitamos es tener instalado el SQL Server Management Studio. Si tienes el el SQL Server Express te lo tendrás que descargar de aquí y si instalaste una versión de pago es posible que ya lo tengas instalado o bien que tengas que ir a por tu DVD de instalación del SQL Server e instalar las herramientas.
Lo segundo es que ambas granjas tengan la misma versión, ya puestos la última (SP1). Ya sabes, instalamos WSS 3.0 SP1 primero y luego MOSS 2007 SP1.
Y yo creo que con esto es suficiente, arremangarse niñio.
1.- ¿Cuales son mis bases de datos de contenido?
Antes de empezar a hacer el trasvase tenemos que saber cómo se llaman las bases de datos que queremos trasvasar. Para ello abrimos la administración central y desde allí --> Administración de aplicaciones y luego Bases de datos de contenido.

Como seguramente, por defecto te tomará cualquier aplicación web menos la que tu quieres cambiaremos la aplicación web:

Y una vez que hayamos seleccionado la aplicación web buena podremos ver la lista de bases de datos de contenido que la nutren. En mi caso y muy convenientemente solo es una, la archiconocida por todos WSS_Content.
(Un breve inciso: A mi entender, la única explicación plausible para tener más de una base de datos de contenido por aplicación web es porque, en caso de catástrofe, es más rápido restaurar una base de datos pequeña que una grande, pero NO PASA ABSOLUTAMENTE NADA POR TENER CONTENT DATABASES TAN GRANDES COMO QUERÁIS, Microsoft no pone límite y yo he trabajado con bases de datos de 500GB sin ningún problema de rendimiento.)
Ahora ya sabemos qué queremos copiar, así que vamos con el siguiente paso.
2.- Hacemos backup de nuestra base de datos:
Para ello nos vamos al SQL Server Management Studio y…

Tras pulsar backup debemos configurar la copia en la ventanita que nos sale a continuación. No tiene demasiado misterio, solo hay que recordar que existen los backups diferenciales y que es mejor guardar la copia en un sitio que conozcamos.
(Otro breve inciso: Como habrás imaginado no es la mejor idea del mundo hacer este proceso en el momento de mayor actividad del servidor, aunque se puede hacer en ese momento si te gusta el riesgo)
3.- Nos llevamos la BD al servidor nuevo
Como tenemos una memoria excelente y nos acordamos de dónde hemos guardado el ficherito .bak pues nos vamos allí y lo pasamos al otro server. Dicen las malas lenguas que el SQL Server 2008 comprime los backups, yo no lo he probado todavía, pero si estoy seguro de una cosa el 2005 no lo hace, así que si vas a pasar la base de datos por internet a alguien es una buena idea comprimirla.
4.- Restauramos la base de datos en el servidor nuevo
Algunas veces cuesta un poco de trabajo esto de restaurar las bases de datos.

Si en el servidor donde vais a hacer la restauración de la base de datos ya hay una base de datos con el mismo nombre que la que vais a restaurar y además está en uso el SQL os va a decir que no puede tener acceso exclusivo a ella y va a fallar. Esto es normal, una cosa es hacer el backup en caliente y otra es restaurar una copia de seguridad en caliente.
En ese caso, antes del restore, haremos un detach (Desasociar en castellano) de la base de datos marcando la casilla de Drop Connections (¿Cerrar conexiones?) así:

Si todavía os falla será porque necesita sobreescribir la base de datos antigua, id a Options en la ventana de configuración del restore y dadle permiso al pobrecito.
5.- Configurando la aplicación web para que use nuestra flamante base de datos de contenido:
Igual que en el paso uno, pero esta vez en el servidor nuevo, Abrimos la administración central y desde allí --> Administración de aplicaciones y luego Bases de datos de contenido, después cambiaremos la aplicación web a la que nos convenga.
Una vez hecho esto tendremos que quitar la base de datos de contenido que tiene la aplicación, pulsamos sobre ella y en la ventana que nos sale marcaremos “Quitar base de datos de contenido” luego Aceptar y Aceptar.

Y luego:

(Si la tienes demasiado grande SharePoint se asustará al verla y habrá que metérsela por la puerta trasera) Si la base de datos que estamos adjuntando a nuestra aplicación web es demasiado grande nos dará un error, no pasa nada, para las cosas serias siempre podemos usar el socorrido stsadm el comando sería más o menos:

stsadm -o addcontentdb -url http://erChan -databasename wss_content

6.- Abrimos la web y listo…
Si todo ha ido bien ya podríamos entrar en nuestra aplicación web con su recién atachada base de datos, pero es posible que si has cambiado de entorno el usuario administrador ya no sea el mismo… En este caso tendrías que ir a Administración central –> Administración de aplicaciones –> Directiva de aplicación Web y meter allí como control total al administrador de esta granja.

Y fin, qué post más largo. Ya paso de comentar más nada ¡UF!.
Hay quien dice que este método solo funciona si mientras esperas lees un libro de yoga, pero no creo yo que sea para tanto, de hecho creo que el post en sí ya es un libro de yoga.