On a beau dire que le cloud est fiable et sécurisé, si je dois y confier mes données, j’aime avoir la certitude que mes données peuvent être sauvegardées et restaurées à volonté. Il en va de même avec SharePoint.

Mon client actuel souhaite migrer son SharePoint 2010 on premises vers un Office 365. Rien de spécial, jusque là, sauf que ce client est aussi un gros utilisateur de bases Access Services avec des données critiques. Les corruptions de données arrivent rarement mais elles font assez mal quand elles arrivent et j’en ais justement eu une sur une de ces bases Access Services. Sans difficulté, le SharePoint étant sauvegardé par DPM 2010, la restauration de la base récalcitrante a été immédiate. Je me suis alors mis à rechercher un moyen de sauvegarder (notamment) ces sites dans le cloud.

SharePoint Designer 2007 proposait de sauvegarder et restaurer des sites SharePoint ce qui correspond presque à ce que je souhaite à ça de près que :

• SharePoint Designer 2010 ne le propose plus
• Il faudrait que ce processus soit automatisable

Comprendre comment ça marche

Pour faire des tests et, ayant la flemme de provisionner une VM SharePoint 2007 sur mon portable, j’ai profité de l’opportunité pour essayer de le faire dans un VM Role Azure. Mission réussie, mon général ! Non seulement ça fonctionne à merveille mais on bénéficie de performances de folies.

J’ai alors utilisé notre bon ami Fiddler pour monitorer ce qui se passe quand on sauvegarde un site avec SharePoint Designer :

Un premier appel à sites.asmx et à la méthode ExportWeb crée un fichier d’export (.cmp) contenant toutes les données du site exporté et un fichier de rapport/contrôle (.snt). Ces fichiers sont stockés dans SharePoint puis, comme l’export est asynchrone, plusieurs appels vont “pinger” le fichier de rapport pour déterminer si la création est terminée et, si c’est le cas, récupérer le fichier pour le stocker localement.

Mettre les mains de le cambouie

L’API existant toujours dans SharePoint 2010 (et donc Office 365) on peut continuer l’utiliser.

Pour accéder aux Web Services comme au Client Object Model, il faut déjà passer la barrière de l’authentification. Je me baserai sur l’authentification  “headless” (silentieuse) en utilisant le code du post suivant :

http://blogs.msdn.com/b/cjohnson/archive/2011/05/14/part-2-headless-authentication-with-sharepoint-online-and-the-client-side-object-model.aspx

Une fois le sample ouvert, la première chose à faire est de rajouter une référence aux Web Service sites.asmx.

L’initialisation de l’authentification se fait grâce au code suivant :

string cmdSpoSite = args[0];
string cmdUserName = args[1];
string cmdPassword = args[2];

helper = new MsOnlineClaimsHelper(
            cmdUserName,
            cmdPassword, 
            cmdSpoSite);

Ici, l’adresse du site, le compte et le mot de passe sont passés en paramètres de l’application.

Ce helper nous permettra d’obtenir les cookies nécessaires à passer au proxy Web Service. J’ai modifié très légerement le sample MSDN pour retourner les cookies par une propriété. On instancie ensuite le proxy Web Service et on lui assigne les cookies d’Office 365 :

SitesProxy.Sites client = new SitesProxy.Sites();
client.CookieContainer = helper.CookieContainer;

Tous les appels de méthodes seront authentifiés avec le compte spécifié plus haut.

Maintenant, sauvegardons une base Access Services nommé “Contacts” dans la bibliothèque “Documents partagés” du site parent grâce au code suivant :

string exportJobName = "export_" + Guid.NewGuid().ToString();

int exportResult = client.ExportWeb(exportJobName,
    "https://toto.sharepoint.com/Contacts" /* Web Url */,
    "https://toto.sharepoint.com/Documents partages" /* Data Path*/,
    true /* Include Subwebs */,
    true /* Include Security */,
    true /* Overwrite */,
    0);
Console.WriteLine("Backup result: " + exportResult);

Les paramètres sont assez simples :

• Le premier paramètre est le “nom du travail”. Il s’agit du nom de base des fichiers .cmp et .snt générés.
• La premier URL indique ce que l’ont souhaite backuper
• La seconde où on veut le backuper
• Si on veut backuper les sous-sites
• Inclure la sécurité
• Ecraser les fichiers s’ils existent déjà.

Le paramètre de retour n’aide, par contre, pas beaucoup : il s’agit d’un magic number. En décompilant le Web Services avec Reflector ILSpy on trouvera un enum qui indique les différents statut retournés. Par exemple, si tout se passe bien, la méthode retournera 1 (Pending). 5 signifiera NoFileAccess : soit le compte n’a pas les droits, soit l’endroit spécifié n’existe pas.

Pour restaurer notre site, rien de plus simple :

string importJobName = "import_" + Guid.NewGuid().ToString();

int importResult = client.ImportWeb(importJobName,
    "https://toto.sharepoint.com/Restauration" /* Web Url*/,
    new[] { "https://toto.sharepoint.com/Documents partages/" + exportJobName + ".cmp" } /* Data Files */,
    "https://toto.sharepoint.com/Documents partages" /* Log Path */,
    true /* Include Security */,
    true /* Override */);
Console.WriteLine("Import result: " + importResult);

Les seules différences que l’on va noter par rapport à la sauvegarde sont :

• On peut restaurer plusieurs fichiers dans le même site.
• On doit spécifier un endroit où stocker les “logs” de restauration. Il s’agit simplement d’un fichier .snt qui indiquera le résultat de l’opération.
• Le site de destination peut ne pas exister (un site sera créé au besoin) mais s’il existe, il doit être de même template que celui du backup.

Voici des exemples de logs :

• Si on essaie de restaurer un package issu d’un autre template que le site de destination :

12,Error occurred while importing the web https://toto.sharepoint.com/Restauration.
Cannot import site. The exported site is based on the template ACCSRV#0 but the destination site is based on the template STS#1. You can import sites only into sites that are based on same template as the exported site.

• Si on essaie de restaurer un package invalide :

12,Error occurred while importing the web https://toto.sharepoint.com/Restauration.
Failed to read package file.

Et pour aller plus loin ?
On peut bien imaginer une tâche dans un Worker Role Azure ou bien sur un serveur On Premise qui ira sauvegarder les données critiques directement dans SharePoint, dans des blobs Azure…

A l’heure où Microsoft parle de réversibilité des données, ce genre de techniques est un moyen de calmer les craintes lors des migrations.

Pierrick