Roger Clarke's Web-Site

 

© Xamax Consultancy Pty Ltd,  1995-2017


Roger Clarke's 'Practicable Backup of Cloud Data'

Can Small Users Recover from the Cloud?

Version of 8 March 2017

Roger Clarke **

© Xamax Consultancy Pty Ltd, 2014-17

Available under an AEShareNet Free
for Education licence or a Creative Commons 'Some
Rights Reserved' licence.

This document is at http://www.rogerclarke.com/EC/PBAR-SP.html

The previous version is at http://www.rogerclarke.com/EC/PBAR-SP-160727.html


Abstract

Large numbers of small organisations and prosumers have shifted away from managing data on their own devices and are now heavily reliant on service-providers for both storage and processing of their data. Most such entities are also dependent on those service-providers to perform backups and enable data recovery. Prior work defining users' backup needs was applied to this context in order to establish specifications for appropriate backup arrangements. A sample of service-providers was assessed against those specifications. Their backup and recovery mechanisms were found to fall seriously short of the need.


Contents


1. Introduction

Organisations are responsible for managing their data effectively, but only those that are of substantial size are capable of bringing sufficient resources to bear on the problem. The focus of this paper is on entities that lack scale and IT expertise. Further, the paper is concerned specifically with those aspects of data security that are addressed by backup and recovery arrangements.

1.1 Small Users

The entities within scope of the paper are of several kinds. One is 'micro-organisations' that involve at most one or two individuals. They may or may not be incorporated, their activities may be stimulated by economic or social motivations, and they may be for-profit or otherwise. Some small organisations, with up to c.20 employees, have similar characteristics.

A further relevant category of entities is individuals who make relatively sophisticated personal use of computing facilities. This may be for the management of personal finance, tax and pension fund, for correspondence, for databases of images, videos and audio, or for a family-tree. Such individuals are referred to here as 'prosumers'. The term was coined by Toffler (1970, 1980), and has progressively matured (Tapscott & Williams 2006, Clarke 2008). A prosumer is a consumer who is proactive (e.g. is demanding, and expects interactivity with the producer) and/or is a producer as well as a consumer. In the context of computer usage, a third attribute of relevance is professionalism, to some extent of the person themselves but also in relation to their expectation of the quality of the facilities and services that they use.

The significance of the work reported in this paper extends beyond micro-organisations and prosumers, however. During the last two centuries, workers were mostly engaged full-time by organisations under 'contracts of service'. The last few decades have seen increasing casualisation of workforces, with large numbers of individuals engaged through 'contracts for services'. This requires them to take a far greater degree of self-responsibility. To the extent that large organisations depend on sub-contractors' use of IT and management of data, the security risks faced by sub-contractors impact upon the organisations that engage them.

Risk importation occurs even in the case of conventional employees, because of the Bring Your Own Device (BYOD) phenomenon. On the one hand, this outsources IT device provision from the employer to the employee. On the other, it insources to the employer the insecurities of their employees' devices. A key risk is that data on which the organisation depends may not be subject to adequate backup and recovery arrangements.

A prior study was undertaken of the risks involved in consumer migration from local applications to remote services (Clarke 2011). That paper concluded with the following quotation: "Some cloud computing outfit is going to quickly and quietly shut down, taking with it the data (business, photos, video, memories, etc.) of tens of thousands of users.  Once we're storing everything in the cloud, what's to keep us from losing everything in the cloud?" (Cringely 2011, emphasis in original). Clarke (2012a) documented the extent and nature of cloud interruptions and failures in the period 2005-11. This paper is motivated by the need for clear guidance for small users faced with such service-provider frailties.

1.2 Backup and Recovery

The purpose of backup and recovery arrangements is to ensure that data continues to be available despite loss of, or compromise to, the primary copy. A range of alternative approaches exists. References of avlue to the research reported here were Chervenak et al. (1998), plus Lennon (2001), Gallagher (2002), Preston (2007), de Guise (2008), Strom (2010), TOB (2012) and Cole (2013).

Backup may be performed at the level of a database or a file, or multiple versions of, or changes to, data may be stored within a database or file. The separate copy/ies may be on the same storage-device, or on another local storage-device, or on a device in a known location that is sufficiently remote that it is not subject to the same local-area risks as the original copy, or on a device whose location is unknown. The copy/ies may be online or offline. The device(s) containing the copy/ies may be in the possession of the relevant entity or of another party. The relevant entity may or may not own the device(s) in question, and in either case the entity's rights may be subject to the interests of other parties.

Backup processes vary in terms of their immediacy and frequency, their scale, the quality assurance applied to the resulting copy/ies, and their accessibility by the relevant entity, and by other parties. A substantial range of alternative forms of backup procedures exists, including within-file backup in such a manner as to support identifiable versions, full and incremental backups of storage volumes, mirroring and spooling to new media.

A predecessor paper reported on an in-depth analysis of the backup needs of micro-organisations and prosumers that store the primary copy of their data in-house, under their own responsibility (Clarke 2016). That paper also addressed circumstances in which an entity relies on a remote file-hosting service for storage of the primary copy of the files, but processes the files on the entity's own devices. The predecessor paper contains a comprehensive catalogue of characteristics is in Appendices 2 and 3.

1.3 The Cloud

During the last decade, the user's proximity to their data has diminished. The data used to be 'here', on the consumer's own device. It moved to 'there', as consumers used relatively local Internet Services Providers, with a known footprint. As the dependency came to be on large national ISPs, and particularly on ISPs outside the consumer's local jurisdiction, the footprint became less visible, and the data moved 'somewhere'. To the extent that cloud computing is applied, consumers' data is now 'anywhere'.

At the applications level, cloud computing takes the form of so-called [Application] Software as a Service (SaaS) offerings. Under the SaaS model, the service-provider both stores the primary copy of the data and performs much of the processing (Armbrust et al. 2010, Höfer & Karagiannis 2011). The user has a relatively very thin application on their desktop and/or laptop, in many cases in the form of scripts downloaded to their browsers, or a small 'app' on their smartphone and/or tablet.

The term 'SaaS' is associated with office automation services such as Google Docs, and the customer relationship management (CRM) service Salesforce. However, the pattern was emergent for some years, in such forms as webmail (operated both by local ISPs and by large providers such as Hotmail, Yahoo! and Gmail), family-tree data (e.g. ancestry.com) and textual documents, commonly called web-logs or blogs (e.g. wordpress.com). The more sophisticated forms that have emerged since about 2005 extend 'outsourcing' to 'cloudsourcing' by taking advantage of inexpensive commoditised hosts and virtualisation features, and articulating the industry into a wholesale-retail network model.

A SaaS segmentation analysis was presented in Clarke (2011). Since then, however, there have been further developments in SaaS offerings. No empirically-based taxonomy was located in the formal literature. The following segments are proposed as a means of identifying potential objects of study, on the basis of examples and partial classification schemes evident in both refereed and commercial literatures:

1.4 SaaS and Backup

Dependence on Software as a Service gives rise to additional data risks (Clarke 2013), and backup and recovery processes have vital roles to play in managing a number of them. An early statement of the problem appeared in Armbrust et al. (2010): "customers cannot easily extract their data and programs from one site to run on another". This was more fully articulated by Buffington (2012): "What about if the SaaS provider goes dark? Maybe out of business? Perhaps a victim of Denial of Service attacks or broad data corruption (that is then replicated between sites). What is your plan? Do you back up the data from your SaaS provider? In what format(s) is the backup in? Is the data readable or importable into a platform that you own? How would you bring the functionality back online for your local users? for your remote users? Most importantly, have you tested that recovery?". Some further insights are available in the commercial literature (e.g. Taylor 2014, Buffington 2014, 2015).

In formal literatures, on the other hand, even within the cloud and SaaS security arena, the topic of backup and recovery has attracted limited attention. A Google Scholar search on <SaaS backup> in early 2017 delivered a small number of articles, only a handful of which have achieved Google citation-counts, the highest a mere 20. In the IEEE Library, <SaaS backup> finds only 3 hits, one of them a brief opinion piece by this author (Clarke 2015b). In the 30,000-entry eLibrary of the Association for Information Systems (AISeL), no articles had <SaaS AND backup> in the Title or Abstract, and the 12 with SaaS in the Abstract and backup in the text made only fleeting mention of backup, were almost all attitudinal surveys, and made no contributions to design. Even an article on selection criteria for SaaS services barely mentioned the topic (Repschlaeger et al. 2012).

Broader searches on <SaaS security> delivered far more articles, with far more citations. The IEEE library using < cloud security backup> found 70 hits, but few of these focus on backup issues. A 350-page book on `cloud security' has less than a page on backups, and only 8 pages on business continuity and disaster recovery as a whole (Krutz & Vines 2010). Of the highly-cited papers in the area, Balachandra et al. (2009), Subashini & Kavitha (2011), Javaraiah (2011), Chen & Zhao (2012) and even AlZain et al. (2012) address security generally but with superficial mentions of data backup and recovery, or none at all. Among the relevant publications of standards bodies, NIST (2011) is vacuous. ENISA (2015) advises SMEs that "Customers should assess which backups are made by the provider and if they need to implement or request additional back-up mechanisms ... Customers should assess which data is stored server-side, and client-side" (p.9). However, ENISA fails to provide any guidance as to what information to gather, how to evaluate it, and what requirements to communicate to their suppliers. The modest commercial literature contains useful observations, but limited guidance (e.g. Menn 2011, Cringely 2011).

The research reported on in this article set out to fill what is a yawning gap in the literature, by defining the needs of the micro-organisation and prosumer market-segment, and evaluating a sample of SaaS providers against these requirements.


2. The Research Method Adopted

The purpose of the research reported in this paper was defined as:

To develop practical guidance on how micro-organisations and individuals can use backup techniques to address data risks arising in the context of remote, cloud-based (SaaS) services

The work adopted the design science approach to research (Hevner et al. 2004, Hevner 2007). In terms of the research method described by Peffers et al. (2007), the research's entry-point was `problem-centred'. The process commenced by applying risk assessment techniques in order to develop an articulated definition of the problem and of the objectives. An artefact was then designed - in this case a set of backup plans. In terms of Hevner (2007), the work's important contributions are to the requirements phase of the Relevance Cycle, and to the Design Cycle, drawing on existing theory in the areas of risk assessment, data management, and data security. The article contributes to the evaluation phase of the Relevance Cycle by applying the new artefact to a sample of SaaS services, and laying a firm foundation for application and field testing.

The analysis in the prior paper on backup of locally-stored data (Clarke 2016), proposed a customised process for performing risk assessment focussed specifically on matters for which backup and recovery are relevant safeguards. It applied the conventional security model, as summarised in Appendix 1 to that paper, and drew on the accumulated literature on risk assessment generally, in particular AS 4360-2004 (which is more specific than the successor ISO 27000 series) and NIST (2012, 2013). A straightforward process was proposed whereby risk assessment could be conducted by or for small organisations and prosumers. That process was presented in Table 1.

Table 1: The Risk Assessment and Management Process

Analyse

  1. Define the Objectives and Constraints
  2. Identify the relevant Stakeholders, Assets, Values and categories of Harm
  3. Analyse Threats and Vulnerabilities
  4. Identify existing Safeguards
  5. Identify and Prioritise the Residual Risks

Design

  1. Identify alternative Backup and Recovery Designs
  2. Evaluate the alternatives against the Objectives and Constraints
  3. Select a Design (or adapt / refine the alternatives to achieve an acceptable Design)

Do

  1. Plan the implementation
  2. Implement
  3. Review the implementation

____________________

It is not feasible to conduct risk assessment on a general case. So a particular profile was developed for use in the research. It is defined in Table 2. The criteria used in devising it were:

Table 2: The Test-Case

A person who:

The functions the person performs are primarily:

The person operates out of a home-office using equipment as follows: a desktop device

The person has limited and/or somewhat haphazard backup and recovery arrangements in place

The person is not likely to be a specific target for attackers (as distinct from being subject to random unguided attacks by malware), i.e. such categories are excluded as private detectives, IT security contractors, and social and political activists who face the risk of being directly targeted by opponents and by government agencies

___________________

The research reported applied risk assessment and risk management techniques, in order to design backup plans. The final step was an initial contribution towards evaluation of those plans. This was achieved by examining the feasibility of implementing the plans in relation to a small sample of SaaS services. The set needed to reflect the diversity of the market segments discussed earlier and embody sufficient differences in the nature of the services that they were likely to be somewhat independent studies rather than the same study performed several times. On the other hand, the set needed to be sufficiently small to enable performance of the analysis with available resources. The following were selected:

A comprehensive report on the study is provided in an accompanying Working Paper (Clarke 2017). This paper provides an overview of the process that was applied, summarises the requirements that were developed, and reports on the assessment of a sample of SaaS services.


3. The Process Applied

This section summarises the assessment of risks for which backup and recovery are relevant safeguards. It follows the sequence of steps specified under `Analyse' in Table 1.

A lengthy, formal statement of the objectives and constraints was defined. Expressed in terms more appropriate to small users, on the other hand, the aim was:

To achieve reasonable levels of security for reasonable cost

An analysis was undertaken of the interests of the particular test-case user defined in Table 2. This identified relevant data assets, values associated with those assets, and categories of harm to that the data could suffer. The user values that could be damaged are listed in Table 3.

Table 3: Damage to Stakeholder Values

The next phase of the process involved the identification of threats and vulnerabilities that could give rise to such harm. To facilitate communication with small users, a mnemonic approach was adopted to Threats, using FATE (Fire, Attack, Training and Equipment) to represent respectively Environmental Events (F), Attacks (A), Human-Caused Accidents (T) and Accidents within Infrastructure (E).

The ground had almost been laid for the assessment to proceed from the analysis to the design phase. It was first necessary, however, to consider a number of key aspects of SaaS service-provision.

One concern is the lack of clarity about what obligations a SaaS provider owes to its customers, how long they last, and whether and how they could be enforced. A contract may exist - provided that all of the conditions for the formation of a contract are satisfied, notably the provision of consideration by both parties. If so, the contract is governed by the Terms that the provider displays, together with any overriding conditions imposed by such jurisdiction(s) as may be relevant to the contractual relationship. Generally, the Terms published by SaaS providers offer very little in the way of undertakings to the user, and are malleable, and are in practice (and possibly even at law) unenforceable. Warranties in relation to the accessibility of the data are uncommon, even more so warranties in relation to ongoing accessibility, and especially long-term accessibility. In short, the backup features of SaaS services are whatever they are, and as a matter of practice, and even of law, there is generally very little that the user can do about them.

Secondly, it is unclear what degree of reliance a small organisation or individual can place on the continued existence of each particular SaaS service. Most SaaS providers offer services in order to make a profit. So lines of business that are not sufficiently profitable are routinely withdrawn. Some providers also close users' accounts if they consider that they have not been used sufficiently recently. In addition, it is in the interests of a commercial service-provider to make it difficult for users to extract their data, because that raises the switching costs and achieves 'loyal' (in the narrow sense of 'locked-in') clients. In practice, reliability of access has mostly been reasonably good, but many instances of service-interruption and data-loss were documented in Clarke (2012a), and little appears to have happened since then to reduce the concerns identified in that study. There are questions not only about the longevity of individual services, but also about the survival of each SaaS provider. For example, of the 25 CMS SaaS catalogued in Kaskade (2011), 7 (28%) appeared, a mere 4 years later, to no longer exist.

Withdrawals of services from the market, and failures of SaaS providers, have generally involved little or no notice to users. This includes multiple withdrawn services that had been offered by very large corporations such as Google, Apple, Facebook and Microsoft. In some cases, the service was deemed to be no longer of interest to the company. In other cases, however, it was a competitive service that the larger corporation had acquired in order to close it down. An example of a withdrawn service is the drop.io file-sharing service, which was closed at 6 weeks' notice following takeover by Facebook. Similar fates befell Pownce and FitFinder (micro-blogging), Yahoo! Geocities (web-hosting), Yahoo! Photos, Yahoo! Briefcase (file-hosting), Google Buss, Google Video, Google Knol, Google Health, Google Notebook and Google Orkut.

Given the considerable scope for SaaS services to fail, data escrow becomes an attractive idea. Data escrow involves a copy of the data being on deposit with a trusted third party, which is contractually bound to deliver it to the right people in the right circumstances. Circumstances relevant to the present context are failure of the provider, and withdrawal of the service. There are a number of patents in the area, but the slim formal literature is primarily concerned with personal privacy protections rather than the data values addressed in this paper. An example of a functioning data escrow service is that provided by the NCC Group in relation to DNS registry data; but it does not appear that services implementing data escrow principles are generally available, and particularly not in relation to SaaS services.

A third concern about SaaS services is that many of them store their customers' data in proprietary formats. The question therefore arises as to whether backed-up data is sufficiently portable to satisfy the accessibility value. Some data is of ephemeral value, and the functions that a prosumer or micro-organisation needs to have assured access to may be no more than:

In some areas of business, there is an presumption that immediacy and 'living for the now' is dominant and that long-term planning for data is out-of-step with the zeitgeist. On the other hand, a considerable amount of data retains value over an extended period of time. In some circumstances, that period may be definable (e.g. 5-7 years for tax law compliance); but in others the period may be indeterminate (e.g. family trees and photo-albums). For data with longer-term value, users are reliant on ongoing access to a broader range of functions:

A final step was then to identify pre-existing factors that intentionally or incidentally mitigate risks. Examples include conservative human behaviours, physical security safeguards, accounting controls. and insurance policies. On the basis of the above analysis, it was now possible to document the residual risks that need to be managed, together with an assessment of their likelihood and severity. The outcomes are presented in Table 4.

Table 4: Priority Threat-Vulnerability Combinations

 

 

Risk

Severity Rating
(E, H, M, L)
Probability Rating
(H, M, L)
1.
Unavailable Data or Unavailable Service to Access the Data
Long-Term
Extreme Medium
2.
Inaccessible Service – Wide Area Network Failure / Congestion
Long-Term
Extreme Medium
3.
Inaccessible Service – Local Area Network or Internet Connection Failure / Congestion – Long-Term Extreme Medium
4.
Inaccessible Data (Data-Format unable to be processed)
Long-Term
Extreme Medium
5.
Unavailable Data or Unavailable Service to Access the Data
Short-Term
High High
6.
Inaccessible Service – Wide Area Network Failure / Congestion
Short-Term
High High
7.
Inaccessible Service – Local Area Network or Internet Connection Failure / Congestion – Short-Term High High
8.
Mistaken Amendment, Deletion or Overwriting of a File High Medium
9.
Inaccessible Data (Data-Format unable to be processed)
Short-Term
High Medium

Item 2 in Table 4 may arise in a wide variety of circumstances, including:

The process then moved into the design phase, by considering alternative backup and recovery strategies and tactics, and selecting appropriate designs for various circumstances. Any particular user may have data of varying degrees of criticality. For example, a debtors' ledger may be critical to the survival of the user's business; whereas a set of images of previous work performed may be of archival interest and have latent rather than actual value.

Because of the uncertainties about supplier and service reliability and about accessibility during the lifetime of the data's value, one of the most critical design choices is whether the first-level backup is stored locally by the user, or remotely by some other party. Three approaches were distinguished, as shown in Table 5. In the first approach, the user relies entirely on the SaaS provider. In the second, the user draws backups down to their own site. In the third case, the user relies on the services of a further party, referred to here as a 'Backup as a Service' or BaaS provider. In these three cases, the user is respectively entirely dependent upon and trusting of the service provider; or is required to understand, design, implement and perform backup; or is dependent on two service-providers rather than just one.

Table 5: SaaS Backup Alternatives

Short
Description
Indicative
Timeframe
Location:
1st-Level Backup
Location:
2nd-Level Backup
User
Experience
Naive Cloud
2010-
SaaS Provider
SaaS Provider
Implicit Trust
DIY Backloads
2015-
SaaS Provider
Local
More Demanding
BaaS on SaaS
2015-
SaaS Provider
BaaS Provider
Less Demanding

The following sections consider in turn each of the three contexts identified in Table 5. In each case, a requirements statement is first derived from the literature and the preceding analysis, and then the offerings of a sample of SaaS service-providers are evaluated against the requirements.


4. Naive Cloud Usage

This section considers the most common, and generally default approach, particularly during the early years of SaaS services. This involves implicit trust placed by users in the provider.

A list of requirements was developed which addresses the high-priority threat-vulnerability combinations that confront a small organisation or individual that has the profile declared in Table 2 and that depends on a SaaS provider to perform backup and recovery on the user's behalf. The requirements were categorised into infrastructure features, file-precautions, backup runs and business processes.

Critical among the requirements are a high to very high level of service-availability, continual saves of changes made to files, an appropriate approach to file-versioning, malware management, backup to a geographically remote location and into off-line storage, and effective and efficient recovery procedures. Further details are available in the Working Paper.

Strategies were sought for dealing with the priority threat-vulnerability combinations identified in Table 4. Unfortunately, as indicated in Table 6, where full reliance is placed on the SaaS provider, almost all of them are incapable of being addressed.

Table 6: Risk Management Strategies - Naive Cloud Usage

 
RiskStrategy
1.
Unavailable Data or Unavailable Service to Access the Data
Long-Term
Nil, for the duration of the (long) Unavailability
2.
Inaccessible Service – Wide Area Network Failure / Congestion
Long-Term
Nil, for the duration of the (long) Inacessibility
3.
Inaccessible Service – Local Area Network or Internet Connection Failure / Congestion – Long-TermNil, for the duration of the (long) Inacessibility
4.
Inaccessible Data (Data-Format unable to be processed)
Long-Term
Nil
5.
Unavailable Data or Unavailable Service to Access the Data
Short-Term
Nil, for the duration of the (short) Unavailability
6.
Inaccessible Service – Wide Area Network Failure / Congestion
Short-Term
Nil, for the duration of the (short) Inacessibility
7.
Inaccessible Service – Local Area Network or Internet Connection Failure / Congestion – Short-TermNil, for the duration of the (short) Inacessibility
8.
Mistaken Amendment, Deletion or Overwriting of a FileContinuous or Continual Versioning
9.
Inaccessible Data (Data-Format unable to be processed)
Short-Term
Nil

The final step in the research reported in this paper was to conduct an assessment of the capabilities of a sample of SaaS providers in comparison with the requirements of small users. This was done by reviewing each supplier's product description, product commentaries, and such other sources as could be located, particularly organisations that offer backup products or services relevant to it. The reviews were complemented by searches for relevant published papers in both the academic and popular literatures - although few were found.

A number of features were common across most or all of the five providers:

The remainder of this section presents the outcomes of the evaluation that were specific to the individual services.

Instagram

Instagram offers a simple storage service for static files, primarily in order to make them accessible by other people, but of necessity also as a repository for them. It projects the feeling of social immediacy, and, in many circumstances, the images that users store there are of ephemeral interest. However, to the extent that images have ongoing value to users, it is abundantly clear that reliance on Instagram even as a medium-term repository, let alone as a long-term archive of visual memories (cf. a 'photo album'), is extremely unwise.

ancestry.com

This service enables the development and maintenance of one or more segments of structured family tree, supported by a substantial set of resources mostly drawn or captured from public sources. It appears that there is no notion of versioning, with only the current content available for display. The reliability of service, of service-availability, and of backup and recovery, is unclear. Given the great value that people generally place on the data that they accumulate about their families, it is remarkable that there appears to be no mention of the provider's backup policies or practices anywhere on the site.

Xero

Xero provides an online accounting service. Given that accounting for the tiniest micro-business involves periodic cycles, the need to capture data and generate reports for various periods at various times, and 5-7 year archival requirements, it would be reasonable to expect that the design and the advice to users would emphasise backup and recovery. Instead, "Xero adheres to its best practice policies and procedures to prevent data loss, including a daily system data back-up regime, but does not make any guarantees that there will be no loss of Data", and "Xero expressly excludes liability for any loss of Data no matter how caused". The sum total of the assistance it provides to users concerning the steps that they need to take is "You must maintain copies of all Data inputted into the Service" (emphases added).

Salesforce

Salesforce is quite blunt about its shortcomings. Its web-site declares that "Salesforce Support doesn't offer a comprehensive data restoration service", and warns the user not to rely on it for recovery purposes: "Although Salesforce does maintain back up data and can recover it, it's important to regularly back up your data locally so that you have the ability [to] restore it to avoid relying on Salesforce backups to recover your data. The recovery process is time consuming and resource intensive and typically involves an additional fee". It also explains that it is wildly expensive: "Data Recovery is a last resort process ... The price is a flat rate of $US 10,000" (emphases added). This would be very expensive for many micro-organisations and individuals, and prohibitive for some.

Google Docs

The core functions of Google Docs, as with any office suite, are the creation and modification of word processing documents and spreadsheets; but several further capabilities are included (Jeffries 2012). The storage of user files is managed by Google Drive. Google Drive has several modes of operation, which give rise to considerable complexity in relation to the ways in which backup and recovery needs to be performed. When documents are being edited, progressive saves are made, and a concept of file-versions exists; but the frequency with which a new version of the file is created is unclear. Despite searches being conducted on Google sites, and links being followed, no source was located that explained what backup and recovery processes exist within the Google Docs and related services.

The most compact conclusion that can be reached about the support for backup provided by these five mainstream SaaS services is that individuals and organisations that are reliant on being able to access data should not place implicit trust in any of them. At the current, clearly immature stage of the development of SaaS services, that cautionary statement may well be generally applicable.


5. DIY Backup

This section investigates how a user can take Do-It-Yourself (DIY) responsibility for their own backup and recovery, despite entrusting both the Primary copy and all processing functions to a service-provider. In comparison with the local storage approach addressed in the predecessor paper (Clarke 2016), the use of remote storage reverses the logic and requires a backup to be held locally. The service-provider needs to fulfil a number of requirements, but safeguards continue to be needed on the individual's own devices as well.

The key issues are whether it is feasible for a user to extract their data from the SaaS provider's site, and whether the data that is extracted is in a usable format. Strategies were sought for dealing with the priority threat-vulnerability combinations identified in Table 4. As indicated in Table 7, most can, at least in principle, be addressed through mirroring or periodic backload to the user's own site. In some circumstances, however, this may be infeasible.

Table 7: Risk Management Strategies - DIY Backup

 
RiskStrategy
1.
Unavailable Data or Unavailable Service to Access the Data
Long-Term
Mirroring or Periodic Backload to a local storage-device
2.
Inaccessible Service – Wide Area Network Failure / Congestion
Long-Term
Mirroring or Periodic Backload to a local storage-device
3.
Inaccessible Service – Local Area Network or Internet Connection Failure / Congestion – Long-TermMirroring or Periodic Backload to a local storage-device but only if directly-connected
4.
Inaccessible Data (Data-Format unable to be processed)
Long-Term
Mirroring or Periodic Backload to a local storage-device but only if reformatting is feasible
5.
Unavailable Data or Unavailable Service to Access the Data
Short-Term
Mirroring or Periodic Backload to a local storage-device
6.
Inaccessible Service – Wide Area Network Failure / Congestion
Short-Term
Mirroring or Periodic Backload to a local storage-device
7.
Inaccessible Service – Local Area Network or Internet Connection Failure / Congestion – Short-TermMirroring or Periodic Backload to a local storage-device but only if directly-connected
8.
Mistaken Amendment, Deletion or Overwriting of a FileMirroring or Periodic Backload to a local storage-device
9.
Inaccessible Data (Data-Format unable to be processed)
Short-Term
Mirroring or Periodic Backload to a local storage-device but only if reformatting is feasible

An assessment was undertaken of the extent to which the selected sample of SaaS providers enable small users' requirements to be fulfilled.

Instagram

It appears that Instagram does not support a download to the user's own working-device. On the other hand, Instagram does provide an API that facilitates extraction of files by third parties, and three services were found that appear to use that API to enable download files to the user's device: Instaport (which downloads all files), Grabinsta (for individual files only) and digi.me. Hence it would appear that an alert user can find a way to backup their images from Instagram; but nothing on the company's site suggests that this might be important, nor how it might be done. This is surprising, given that some users may want to upload photos from a handheld device, and later download them onto a desktop device.

Moreover, the Terms of Use of the API preclude its use "for any application that replicates or attempts to replace the essential user experience of Instagram.com or the Instagram apps". This has the appearance of an attempt to prevent users from switching their images to an alternative provider of image-hosting services; yet that is precisely what a user needs to do if Instagram under-performs, materially changes the service, withdraws it, or closes down.

ancestry.com

The family-tree data stored by ancestry.com is capable of being extracted by the user into a proprietary format, downloaded, and loaded into a copy of the company's own inexpensive software product, Family Tree Maker. It may also be possible to extract into another format, GEDCOM, that is used by a small number of alternative software products; but the information is not easy to find.

Xero

Xero provides users with capabilities to extract data. However, despite the five-decade history of electronic data interchange (EDI), the company does not appear to have applied an industry-standard format for expressing the chart of accounts, transaction data and report-format parameters. The primary format that data can be extracted into appears to be comma-separated values (CSV) files - which suffer from the serious problem that no reliable field-separation meta-character exists. Data can also be extracted into formats intended to be compatible with various other software products, but the site acknowledges a variety of incompatibilities. Further, it appears that additional files loaded onto the SaaS service, such as scans of inbound invoices, may not be extractable.

The effectiveness of backup to the user's site is accordingly in doubt, and both accounting and IT expertise would be necessary to ensure that the intended result is achieved.

Salesforce

Salesforce enables data to be extracted, but according to the company's site:

Further, the company acknowledges that recreating a Saleforce database from a backup may be very difficult, and it cannot provide assistance: "Overall planning, development and implementation of a strategy to manage record restoration falls outside the scope of Support's offerings" (emphasis added). In short, despite the company's previously-quoted exhortation "to regularly back up your data locally", it appears that Salesforce may not enable data to be backed up to the user's site.

Google Docs

Google Docs files are stored in a proprietary format, and as a result mirrored files are only readable using Google Drive Desktop App and/or the Google Chrome browser. In addition, only the current version is available, and versioning support is highly restricted. Considerable difficulty was encountered in assessing the feasibility of conducting DIY backup from Google Docs to users' own storage-devices. Reasons for this include the lack of straightforward documentation on Google's many sites, the existence of multiple documents with mutually inconsistent content scattered across different structures, and the frequent changes made to Google services, often without notice to their users. Indicative of the problems is that an auto-synch service advertised in Bradley (2011), called Memeo, was withdrawn within a year - presumably at least in part because ongoing changes to Google's storage arrangements make the maintenance of such third-party services untenable. A history of the techniques involved at various times is to be found in the successive, archived versions of Malunui et al. (2013). Some of the current pitfalls are described in Witzel (2016).

On the basis of the available sources, it appears that, until the end of 2014, there were considerable difficulties involved in extracting a usable backup of documents, and any particular user may or may not have been able to achieve it. Since the beginning of 2015, a backup-to-local-storage mechanism has been available, usefully described in Rowe (2015). Finding authoritative documentation on Google sites in the period September 2015 to March 2016 was challenging, and continually led to different source-pages. A snapshot of one page was taken in March 2016 (Google 2016). At least in the cases of word processing and spreadsheet files, the extraction may be achievable in mainstream formats; but there are qualifications and exceptions, such as music-files. It is not entirely clear what the default export formats are, what alternatives exist, and how the default export formats are over-ridden. At least one third-party product exists, Insync, but that product's functions and reliability are just as unclear as the backup and recovery features of Google Docs itself.

Of the five services in the sample, only one, ancestry.com, enables an individual or small organisation to perform an effective backup to their own site in a reasonably straightforward manner. In the other four cases, there are conceptual and technical challenges that are sufficiently substantial as to be insurmountable for many users. Only in the case of Google Docs does it appear that a reasonable degree of guidance is available - and that is confusing and rapidly-changing.

On the basis of the sample, it seems that very few SaaS providers enable straightforward implementation of the Backup Plan needed by any serious user. The problem may affect large and medium-sized organisations as well, but is particularly serious for individuals and small organisations that seek to, for example, maintain an image-library, ensure that they have access to an archive of their electronic tax records, not lose their data relating to customers and prospects, and not lose their correspondence files with government agencies, suppliers, employers, , financial institutions, insurers and pension funds.


6. Backup as a Service (BaaS)

In this section, the possibility is considered of using an additional cloud service - a 'Backup as a Service' (BaaS) provider - as a defence of last resort against malfunction or malperformance by a SaaS provider.

The BaaS provider's focus is on backup and recovery services. However, they of course share common features with all other SaaS providers:

Applying basic security principles, it is important to ensure that the SaaS and BaaS providers do not have common vulnerabilities, because that would reduce what appears to be the relative security of two points-of-failure to the relative insecurity of only one. Examples of situations to be avoided include physical co-location of the SaaS and BaaS, network co-location, common ownership, and storage of the two Backups within the same jurisdiction. At this stage, the BaaS market-segment appears to be under-developed. A background/wholesale option exists in the form of Amazon Web Services (AWS) Glacier, but micro-organisations and prosumers would need an intermediary provider to utilise that service.

Strategies were sought for dealing with the priority threat-vulnerability combinations identified in Table 4. The results are presented in Table 8.

Table 8: Risk Management Strategies - BaaS

 
RiskStrategy
1.
Unavailable Data or Unavailable Service to Access the Data
Long-Term
Mirroring or Periodic Crossload to another cloud-provider but only if BaaS Provider not affected
2.
Inaccessible Service – Wide Area Network Failure / Congestion
Long-Term
Mirroring or Periodic Crossload to another cloud-provider but only if BaaS Provider not affected
3.
Inaccessible Service – Local Area Network or Internet Connection Failure / Congestion – Long-TermNil, for the duration of the (long) inacessibility
4.
Inaccessible Data (Data-Format unable to be processed)
Long-Term
Mirroring or Periodic Backload to another cloud-provider but only if reformatting is feasible
5.
Unavailable Data or Unavailable Service to Access the Data
Short-Term
Mirroring or Periodic Crossload to another cloud-provider but only if BaaS Provider not affected
6.
Inaccessible Service – Wide Area Network Failure / Congestion
Short-Term
Mirroring or Periodic Crossload to another cloud-provider but only if BaaS Provider not affected
7.
Inaccessible Service – Local Area Network or Internet Connection Failure / Congestion – Short-TermNil, for the duration of the (short) inacessibility
8.
Mistaken Amendment, Deletion or Overwriting of a FileCrossload to another cloud-provider
9.
Inaccessible Data (Data-Format unable to be processed)
Short-Term
Mirroring or Periodic Backload to another cloud-provider but only if reformatting is feasible

The five sample SaaS were evaluated, to establish the extent to which the use of a BaaS is feasible.

Instagram

Instagram provides an API that facilitates extraction of files by third parties, such as Frostbox, iDrive and StreamNation. The nominal prohibition on use of the API "for any application that replicates or attempts to replace the essential user experience of Instagram.com or the Instagram apps" is presumably ignored by all parties. If a user searches for a BaaS provider, they may find one; but Instagram appears to do nothing to assist users' awareness of or knowledge about the available options.

ancestry.com

Although ancestry.com enables extraction of family-tree data into a proprietary format and possibly a second format, there do not appear to be any BaaS providers of backup services. It appears that ancestry.com may actively block this, in that it provides no API, and its Terms expressly prohibit "distribution of your password to others for access to Ancestry".

Xero

Xero makes an API available to BaaS providers. Services that utilise the API include LedgerBackup (which emails a CSV file for each of the tables in Xero), Boxkite (which mirrors Xero files to Dropbox) and Safeguard-My-Xero. However, it is unclear whether any of these BaaS providers offer any service other than making CSV files available to the user in the event that the Xero service ceases to perform its function. It is also unclear whether all of the files that are extracted are capable of even being re-imported into Xero, let alone into another package or service, in order to re-constitute the set of accounts.

It is accordingly far from clear that Xero is fit for use by any business that wants to be assured of its capacity to manage its accounts and comply with its obligations to tax agencies. There appears to be very little literature on this serious deficiency, but see Dorricott (2013).

Salesforce

Salesforce publishes APIs to BaaS providers, and a range of third parties claim to provide backup services. These include Backupify, Cloudally, Cloudfinder, Ownbackup, SesameSoftware, Skyvia and Spanning. All such products are oriented towards 'enterprises', i.e. large and medium-sized organisations, and none provide straightforward explanations of the kinds that would be comprehensible to micro-organisations and prosumers.

Google Docs

Google Docs is the subject of multiple third-party backup offerings, but they are oriented towards enterprises. The very few BaaS services for consumers and small business, such as CloudHQ and Backupify are clouded in uncertainty, particularly following the withdrawal of Backupify's Snapshot service. A new offering by Spanning.com was heralded by (Witzel 2016) as providing the kind of BaaS service needed. However, in mid-2016, although Spanning's site listed an offering for the enterprise-level Google Apps service, it had none for Google Docs.

The BaaS approach to backups appears to be in two cases feasible, but challenging and ill-fitted to the needs of small organisations and individuals (Instagram and Google Docs). In one case, it is fraught with difficulty because of the absence of services oriented towards small organisations and individuals (Salesforce). In one case it appears to be impractical (Xero), and in the other infeasible (ancestry.com).


7. Conclusions

This paper has reported on research into the backup needs of micro- and some other small organisations, and of individuals. It has focussed on a test-case, in order to not merely provide general guidance, but also to deliver a specification that fulfils the declared objective. A companion paper presented backup plans for contexts in which the user is self-sufficient, or uses a backup service, or uses a file-hosting service for the primary copy of their files. This paper has examined the contemporary context in which the user is dependent on a service-provider for hosting not only the data but also the application software. It has devised strategies for three alternative approaches, and reported on an analysis of their feasibility in respect of a sample of SaaS service-providers.

The approach adopted to the evaluation phase was to select a small but diverse sample of SaaS services, and assess the extent to which those services appear to enable each of the three alternative approaches to backup to be performed. It was evident that complete reliance on SaaS providers, at least at this stage in the maturation of such services, is unlikely to result in an outcome that addresses the backup and recovery needs of individuals and small organisations. It was also clear that a user who takes responsibility for their own First-Level Backups and Archives at least needs to reliably perform somewhat onerous and technically challenging tasks, and even then may not be able to achieve the intended result. The BaaS approach is currently at best problematical and at worst infeasible.

The analysis needs to be subjected to review by peers, and improvements made to reflect their feedback. Further, the analysis needs to be applied to additional and special test-cases, reflecting the needs of small organisations and individuals with particular profiles. The analysis is likely to require adaptation to the extent that the usage among the target market-segment of general-purpose computing devices (desktops and laptops) declines to the point that datafile creation and amendment are generally undertaken on limited-capability appliances (whose current forms are smartphones and tablets).

The specific Backup Plans proposed in this paper, and/or variants of and successors to them, are capable of being productised by providers. These include corporations that sell hardware, that sell operating systems, that sell pre-configured hardware and software, that sell value-added hardware and software installations, that sell storage-devices, that sell storage services, that sell SaaS services, and that sell BaaS services. In addition, current service-providers can use the risk assessment, or the specific Backup Plans, as a basis for evaluating their offerings and planning improvements to address deficiencies.

The analysis of five mainstream SaaS providers concluded that, in many cases, very substantial barriers prevent the implementation of effective backup strategies by small organisations and individuals using SaaS services. This is a very important conclusion, and one that does not appear to have been published in the literature to date. Given the vital economic, social and personal importance of assuring ongoing access to data, this is a fairly remarkable finding. The adoption of cloud solutions may have been enthusiastic, but is has been blind, and that blindness will have serious negative consequences for some users.

A further concern is the very limited attention paid to backup of SaaS-maintained data in the formal research literature, a full decade after it emerged. One reason for the lack of a literature may be that Computer Science is concerned with much more technically advanced matters than backup and recovery. Another may be that the emphasis of Information Systems research is so strongly on social science perspectives and the observation of technology in use that only a limited amount of constructive research is being undertaken. Alternatively, researchers may have such a strong commitment to the needs of corporations that the interests of small organisations and individuals are being largely ignored.

As individuals increasingly act as prosumers, they can be expected to become more demanding, and more interested in investing in effective but practical backup arrangements. Meanwhile, many large organisations will become concerned about importing subcontractors' security risks, and will bring pressure to bear on them to demonstrate the appropriateness of their backup arrangements, and to provide warranties and indemnities. The work reported here sounds the alarm. But it also lays a foundation for significant improvements in key aspects of the data security not only of prosumers and micro-organisations, but also of the larger organisations that depend on them.


References

AlZain M.A., Pardede E., Soh B. & Thom J.A. (2012) `Cloud Computing Security: From Single to Multi-Clouds' Proc. 45th Hawaii International Conference on System Sciences, at http://www.computer.org/csdl/proceedings/hicss/2012/4525/00/4525f490.pdf

Armbrust M., Fox A., Griffith R., Joseph A.D., Katz R., Konwinski A. & Zaharia M. (2010) 'A view of cloud computing' Communications of the ACM, 53, 4 (April 2010) 50-58

AS 4360 (2004) `Risk Management' Standards Australia, 2004

Austin R.P.B. (2013) 'Virus encrypted all google drive files - Cryptolocker virus' Google Drive Help Forum, October 2013, at https://productforums.google.com/forum/#!msg/drive/DmZKoIcAPzg/siCsN_lZDlQJ

Balachandra B.R., Paturi V.R. & Rakshit A. (2009) `Cloud Security Issues' Proc. IEEE International Conference on Services Computing, 2009, at https://xa.yimg.com/kq/groups/2584474/89013670/name/NDU-3.pdf

Bradley T. (2011) `30 Days With...Google Docs: Day 25: Don't Lose Your Google Docs Data' PCWorld, May 2011, at http://www.pcworld.com/article/228707/day_25_dont_lose_your_google_docs_data.html

Buffington J. (2012) 'How do you back up SaaS? I'd like to know' ESG, 21 December 2012, at http://www.esg-global.com/blogs/how-do-you-back-up-saas-id-like-to-know/

Buffington J. (2014) 'SaaS Backup ... Hunger Games style' ESG, 11 December 2014, at http://blog.esg-global.com/saas-backup-...-hunger-games-style

Buffington J. (2015) 'Your SaaS Application needs to be Backed Up!' ESG, 14 May 2015, at http://research.esg-global.com/reportaction/Blog0514201504/TOC?include=backup%20SaaS

Chen D. & Zhao H. (2012) `Data Security and Privacy Protection Issues in Cloud Computing' Proc. IEEE International Conference on Computer Science and Electronics Engineering, 2012, at http://xa.yimg.com/kq/groups/2584474/417972861/name/NDU-1.pdf

Cherdantseva Y. & Hilton J. (2012) 'A Reference Model of Information Assurance & Security'
Proc. IEEE ARES 2013 SecOnt workshop, 2-6 September, 2013, Regensburg, at http://users.cs.cf.ac.uk/Y.V.Cherdantseva/RMIAS.pdf

Chervenak A. L., Vellanki V. & Kurmas Z. (1998) 'Protecting file systems: A survey of backup techniques' Proc. Joint NASA and IEEE Mass Storage Conference, March 1998, at http://www.storageconference.us/1998/papers/a1-2-CHERVE.pdf

Clarke R. (2008) 'B2C Distrust Factors in the Prosumer Era' Invited Keynote, Proc. CollECTeR Iberoamerica, Madrid, 25-28 June 2008, pp. 1-12, at http://www.rogerclarke.com/EC/Collecter08.html

Clarke R. (2011) 'The Cloudy Future of Consumer Computing' Proc. 24th Bled eConference, June 2011, PrePrint at http://www.rogerclarke.com/EC/CCC.html

Clarke R. (2012a) 'How Reliable is Cloudsourcing? A Review of Articles in the Technical Media 2005-11' Computer Law & Security Review 28, 1 (February 2012) 90-95, PrePrint at http://www.rogerclarke.com/EC/CCEF-CO.html

Clarke R. (2012b) 'A Framework for the Evaluation of CloudSourcing Proposals' Proc. 25th Bled eConference, June 2012, PrePrint at http://www.rogerclarke.com/EC/CCEF.html

Clarke R. (2013) 'Data Risks in the Cloud' Journal of Theoretical and Applied Electronic Commerce Research (JTAER) 8, 3 (December 2013) 59-73, Preprint at http://www.rogerclarke.com/II/DRC.html

Clarke R. (2015a) 'The Prospects of Easier Security for SMEs and Consumers' Computer Law & Security Review 31, 4 (August 2015) 538-552, PrePrint at http://www.rogerclarke.com/EC/SSACS.html

Clarke R. (2015b) 'SaaS Backup Fails the Fitness for Purpose Test'
IEEE Cloud Computing 2, 6 (Nov-Dec 2015) 58-63, PrePrint at http://www.rogerclarke.com/EC/FPTB.html

Clarke R. (2016) 'Practicable Backup Arrangements for Micro-Organisations and Individuals ' Australasian Journal of Information Systems, 20 (September 2016), at http://dx.doi.org/10.3127/ajis.v20i0.1250, PrePrint at http://www.rogerclarke.com/EC/PBAR.html

Cole E. (2013) 'Personal Backup and Recovery' Sans Institute, September 2013, at http://www.securingthehuman.org/newsletters/ouch/issues/OUCH-201309_en.pdf

Cringely R. (2011) '2011 prediction #8: Cloudburst' I, Cringely, 6 January 2011, at http://www.cringely.com/2011/01/2011-prediction-8-cloudburst/

Dorricott B. (2013) 'Read Xero's Terms and Conditions and then weep!' Meteorical, 31 December 2013, at http://www.meteorical.com.au/2013/12/read-xeros-terms-and-conditions-and-then-weep/

ENISA (2015) `Cloud Security Guide for SMEs' European Union Agency for Network and Information Security, April 2015, at https://www.enisa.europa.eu/activities/Resilience-and-CIIP/cloud-computing/security-for-smes/cloud-security-guide-for-smes/at_download/fullReport

Gallagher M.J. (2002) 'Centralized Backups' SANS Institute, July 2001, at http://www.sans.org/reading-room/whitepapers/backup/centralized-backups-513

Google (2016) `Download your data' Google Inc., accessed 3 March 2016, at https://support.google.com/accounts/answer/3024190?hl=en, mirrored at http://www.rogerclarke.com/EC/Google-Dyd-160303.pdf

de Guise P. (2008) 'Enterprise Systems Backup and Recovery: A Corporate Insurance Policy' Auerbach, 2008

Gwava (2015) 'Top 10 Google Vault Archiving Drawbacks' Gwava, original of 18 June 2014, at http://www.gwava.com/blog/top-10-google-vault-archiving-drawbacks

Hevner A.R. (2007) 'A Three Cycle View of Design Science Research' Scandinavian Journal of Information Systems, 2007, 19(2):87-92

Hevner A.R., March S.T. & Park, J. (2004) 'Design research in information systems research' MIS Quarterly, 28, 1 (2004), 75-105

Höfer C.N. & Karagiannis G. (2011) `Cloud computing services: taxonomy and comparison' J Internet Serv Appl 2 (2011) 81-94, at http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.460.3939&rep=rep1&type=pdf

IASME (2013) 'Information Assurance For Small And Medium Sized Enterprises'
IASME Standard v. 2.3, March 2013, at https://www.iasme.co.uk/images/docs/IASME%20Standard%202.3.pdf

ISO 27005 (2012) 'Information Technology - Security Techniques - Information Security Risk Management' International Standards Organisation, 2012

ISO 31010 (2009) `Risk Management- Risk Assessment Techniques' International Standards Organisation, 2009

Javaraiah V. (2011) 'Backup for Cloud and Disaster Recovery for Consumers and SMBs' Proc. IEEE 5th Int'l Conf. on Advanced Networks and Telecommunication Systems (ANTS), December 2011

Jefferies C.P. (2012) 'Google Drive: The Differences Between the Web App and the Desktop App' Backupify, 15 August 2012, at http://blog.backupify.com/2012/08/15/google-drive-the-differences-between-the-web-app-and-the-desktop-app/

Kaskade J. (2011) 'The Reality Of Public Cloud' James Kaskade, June 2011, at http://jameskaskade.com/?p=1722

Krutz R.L. & Vines R.D. (2010) `Cloud Security: A Comprehensive Guide to Secure Cloud Computing' Wiley, 2010

Lennon S. (2001) 'Backup Rotations - A Final Defense' SANS Institute, August 2001, at http://www.sans.org/reading-room/whitepapers/sysadmin/backup-rotations-final-defense-305

Malunui et al. (2013) `How to Back Up Google Docs', many successive archived versions from 30 December 2013, at https://web.archive.org/web/20151024172831/http://www.wikihow.com/Back-Up-Google-Docs

Menn J. (2011) 'Cloud creates tension between accessibility and security' Financial Times, 14 November 2011, at, http://www.ft.com/intl/cms/s/0/6513a4d6-0a06-11e1-85ca-00144feabdc0.html;2011. com/EC/CCEF-ITMediaReports-1109.rtf

NIST (2011) 'Guidelines on Security and Privacy in Public Cloud Computing' Special Publication 800-144, National Institute of Standards and Technology, December 2011, at http://csrc.nist.gov/publications/nistpubs/800-144/SP800-144.pdf

NIST (2012) 'Guide for Conducting Risk Assessments' National Institute of Standards and Technology, Special Publication SP 800-30 Rev. 1, September 2012, at http://csrc.nist.gov/publications/nistpubs/800-30-rev1/sp800_30_r1.pdf

Parker D.B. (1998) 'Fighting Computer Crime' John Wiley & Sons, 1998

Peffers K., Tuunanen T., Rothenberger M.A. & Chatterjee S. (2007) 'A Design Science Research Methodology for Information Systems Research' Journal of Management Information Systems 24, 3 (Winter 2007-8) 45-77

Preston W.C. (2007) 'Backup & Recovery' O'Reilly Media, 2007

Repschlaeger J., Wind S., Zarnekow R. & Turowski K. (2012) `Selection Criteria for Software as a Service: An Explorative Analysis of Provider Requirements" AMCIS 2012 Proceedings, July 29, 2012, Paper 3, at http://aisel.aisnet.org/amcis2012/proceedings/EnterpriseSystems/3

Rowe W. (2015) `How to Back Up Google Docs' Tech-Recipes, 4 January 2015, at http://www.tech-recipes.com/rx/52333/backup-google-docs/

Saltzer J. & Schroeder M. (1975) 'The protection of information in computer systems' Proc. IEEE 63, 9 (1975), pp. 1278-1308

Strom S. (2010) 'Online Backup: Worth the Risk?' SANS Institute, May 2010, at http://www.sans.org/reading-room/whitepapers/backup/online-backup-worth-risk-33363

Subashini S. & Kavitha V. (2011) `A survey on security issues in service delivery models of cloud computing' Journal of Network and Computer Applications 34 (2011) 1-11, at http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.259.6975&rep=rep1&type=pdf

Tapscott D. & Williams A.D. (2006) 'Wikinomics: How Mass Collaboration Changes Everything' Portfolio, 2006Taylor C. (2014) 'Backup as a Service: To BaaS or Not to BaaS' Datamation, 10 November 2014, at http://www.datamation.com/cloud-computing/backup-as-a-service-to-baas-or-not-to-baas-1.html

TOB (2012) 'Types of Backup' typesofbackup.com, June 2012, at http://typesofbackup.com

Toffler A. (1970) 'Future Shock' Pan, 1970

Toffler A. (1980) 'The Third Wave' Pan, 1980

Witzel L. (2016) `Do I Need To Back Up Google Docs? Absolutely' Spanning, 25 January 2016, at http://spanning.com/blog/do-i-need-to-back-up-google-docs-absolutely/


Acknowledgements

The assistance of Russell Clarke is gratefully acknowledged, in relation to conception, detailed design and implementation of backup and recovery arrangements for the author's business and personal needs, and for review of a draft of this paper. An assignment on a sub-set of this topic was set for ANU Computer Science students. The analysis reported here benefited from the submissions by Rebecca Catanzariti and Julie Noh, and by Patrick McCawley and Simon Whittenbury.


Author Affiliations

Roger Clarke is Principal of Xamax Consultancy Pty Ltd, Canberra. He is also a Visiting Professor in the Cyberspace Law & Policy Centre at the University of N.S.W., and a Visiting Professor in the Research School of Computer Science at the Australian National University.



xamaxsmall.gif missing
The content and infrastructure for these community service pages are provided by Roger Clarke through his consultancy company, Xamax.

From the site's beginnings in August 1994 until February 2009, the infrastructure was provided by the Australian National University. During that time, the site accumulated close to 30 million hits. It passed 50 million in early 2015.

Sponsored by Bunhybee Grasslands, the extended Clarke Family, Knights of the Spatchcock and their drummer
Xamax Consultancy Pty Ltd
ACN: 002 360 456
78 Sidaway St, Chapman ACT 2611 AUSTRALIA
Tel: +61 2 6288 6916

Created: 28 August 2014 - Last Amended: 8 March 2017 by Roger Clarke - Site Last Verified: 15 February 2009
This document is at www.rogerclarke.com/EC/PBAR-SP.html
Mail to Webmaster   -    © Xamax Consultancy Pty Ltd, 1995-2017   -    Privacy Policy