Home » SharePoint Online » Include a Back Up Method Before Deciding on a SharePoint Online Implementation

Include a Back Up Method Before Deciding on a SharePoint Online Implementation

Few organizations can afford to risk exposing proprietary information to a single data storage solution, regardless of whether the solution is on premise, or in the cloud. But there is no clear, simple path to backing up SharePoint Online data, and or even Apps. Therefore, it makes sense to plan on back up before finalizing a commitment to SharePoint Online.

Back in October, 2011, Jesper Osgaard wrote a post for TechNet Blogs titled How to back-up a Office 365 SharePoint Online Site and Data. The solution Mr. Osgaard presents is “a manual process using the ‘Connect & Export’ section of the Ribbon in SharePoint Online” (quoted from Mr. Osgaard’s post). Unfortunately, in 2014, the “Connect & Export” section is no where to be found in SharePoint Online. Mr. Osgaard’s post also has a number of references to SharePoint Workspace, which has since been sunsetted.

But even if SharePoint Online maintained the features required to implement the manual methods Mr. Osgaard presents in his post, he makes no mention of backing up Apps, or, more specifically, Access Databases published to SharePoint as Apps.

Backing up an App built on an Access database can be particularly difficult. We have at least one of these Apps running in our SharePoint Online instance. But when we connect to it, with Access 2013, and attempt to save it locally, we receive some surprising information. If we want to store the database locally, the best we can do is use the “Report on my Data” feature of Access 2013. The report, in turn, will merely create “read only credentials for directly connecting to the web database behind your app.” (quoted from the dialog which is served when an Access 2013 user clicks on the “Create Reports” button for the “Report on my Data Feature”). So the database still resides online, only, without a local back up.

There are two other messages, which appear in the dialogs served as the user attempts to proceed through the steps required to create the report, which we recommend administrators carefully consider. The first is a rather chilling message: “If necessary, this action will automatically enable a Read-Only Connection and open the firewall to your database”. I’m not sure any administrator would sanction using a tool with the necessary permissions already on board, which are required to automatically open a firewall.

The second of these messages amounts to a disclosure. Although the database was published to SharePoint Online from Access 2013, in its present form it may require “SQL Server Native Client drivers if they are not already installed” (quoted from an error message dialog served when our effort to locally save one of our Apps failed). In fact, as Darvish Shadravan presents in our video training set on SharePoint 2013: Enterprise Forms, once SharePoint 2013 processes data from Access 2013, the data is then actually reposed in SQL Server.

If your organization is open to using third party tools, you may want to review the specifications on the Office 365 Suite from Metavis.

In the meantime, we are researching some other methods of handling the back up requirement for SharePoint Online and our Access 2013 App. Any truly useful information we find on this point will be included in a follow up post on this topic.

Ira Michael Blonder

©Rehmani Consulting, Inc. & Ira Michael Blonder 2014 All Rights Reserved