E’ stato recentemente pubblicato un articolo di KB relativo al comando restore di stsadm e quindi riguardante WSS/MOSS su un problema che viene trattato anche dall’articolo con una certa leggerezza ma che secondo me può essere molto dannoso e anche in questo caso il messaggio di errore nasconde qualcosa…
stsadm can inadvertently delete a root site collection if erroneous URL path used Inadvertently vicino a delete e root site collection è simpatico :)
Con il più classico (default) degli esempi abbiamo creato il nostro portale senza creare managed paths e quindi abbiamo la root site collection sotto http://myserver e tutti le altre site colls sotto /sites/site1, /sites/site2, ecc…
Dobbiamo restorare un backup di una site collection secondaria per ripristinare versioni precedenti, per riorganizzare la nostra gerarchia o perchè vogliamo rinominarla (cambiargli URL) (sì questo è l’unico modo). Quindi
stsadm -o restore -url http://myserver/sites/sitename -filename DRIVE:\file.bak -overwrite
e l’articolo ci dice che se sbagliamo qualcosa nel parametro url ad esempio sites riceviamo il messaggio che non ci sono content databases disponibili ad ospitare il sito:
ERROR:
No content databases are available for this operation. Create a content database , and then try the operation again. To create a content database, click "Content databases" on the Application Management page, select the Web application to use, and then click "Add a content database".
Il che può risultare poi curioso quando si va nell’amministrazione dei content databases e si nota che il default creato ne ha all’incirca ancora 14.995 disponibili.
Il pegno di questo mistyping si paga caro invece e lo si nota andando col browser all’indirizzo http://myserver (portale principale dell’azienda, divisione, .com) e scoprendo che la site collection principale appunto è stata eliminata senza possibilità di recuperarla.
Ma un altro caso simile altrettanto grave e pericoloso sempre col parametro –overwrite che non viene citato nell’articolo accade quando ci dimentichiamo di creare un managed path e stiamo sempre spostando le nostre site colls, ed eseguiamo prima restore senza –overwrite
stsadm -o restore -url http://myportal/divisions/admin/finance -filename DRIVE:\finance.bak
perchè stiamo spostando la site coll finance sotto administration mentre prima stava da un’altra parte e otteniamo:
Another site already exists at ‘/divisions/admin/finance’. Choose a new URL, or specify the –overwrite flag to overwrite flag to overwrite the existing site.
In realtà nessun sito esiste a ‘/divisions/admin/finance’, ma ci siamo dimenticati di creare il managed path (che funzionano all’inverso rispetto a WSSv2/SPS) e le inclusioni vanno esplicitate.
Comunque fino qui tutto bene… (cit.), non ci è stato cancellato nulla, ma non riusciamo a navigare la nostra finance e il restore non è andato su. Decidiamo quindi di seguire il consiglio di stsadm e provare con il –overwrite (magari è come -uninstallfeature che il –force ci va sempre :D)
stsadm -o restore -url http://myportal/divisions/admin/finance -filename DRIVE:\finance.bak –overwrite
Operation completed succesfully.
Perfetto. Andiamo a navigare finance e scopriamo che finance non è disponibile, ma in compenso se navighiamo admin scopriamo che questo è stato sovrascritto con il backup di finance. Se, avvicinando questo caso a quello dell’articolo: abbiamo creato correttamente il managed path, ma sbagliamo a digitare divisions otteniamo un messaggio di successo, ma non riusciamo a navigare finance e abbiamo la root site collection sovrascritta.
In tutti questi casi l’errore, la dimenticanza o la leggerezza ci può costare molto cara.. Se siamo/sono stati bravi un disaster recovery e un ritorno all’ultimo backup, della site collection o del content DB.
Quindi la regola è: se quello che hai scritto non è valido ti cancello o sovrascrivo la prima cosa buona che riesco a trovare.