Archive, Delete and Restore Requirements

This page is detailing requirements for the "Archive/Delete" aspect of what some have called Archive/Delete/Import/Export. While Archive/Delete on the one hand and Import/Export on the other are related technically, the requirements and uses cases are fairly distinct. This page is looking at Archive/Delete.

There is a page designed to document specific, short, use cases at: Archive, Delete and Restore Use Cases

Site Archive/Delete/Restore

Organizations running Sakai over the years have stuff piling up in their databases and file systems. They need a way to remove this information from the current system, preserving the information for future use. This should be performed on a site-by-site basis with option for archiving all sites that meet a certain set of criteria (e.g. all course sites more than 4 years old). A common requirement is that sites should be available to students throughout their "normal" time at the university, which means something like 5 or 6 years.

There are different meanings to "preserving this information for future use." Two of the variables here are:

Restore to which version? The ability to restore the site to the same version of Sakai from which it was archived, vs. to later versions of Sakai.
The ability to restore "read only" access vs. the ability to restore it in a fully operational mode. The former is useful for record-keeping purposes, the latter for reuse.

Another distinction is "Soft" delete vs. "Hard" delete. It is desirable to have the ability to "softly" delete a site (essentially hide it) so that it can't be access but can be easily restored (in the "fully operational" sense) easily and quickly. A "hard" delete would remove the site data from the database, requiring a restore operation to have access to the information.

Although most tools should support this, the most important tools are:

Content Hosting (and anything that uses it, especially Resources).
Forums
Assignments
Announcements
Gradebook
Email archive
Chat
Tests & Quizzes (a.k.a. Samigo)
Test Center (a.k.a. Mneme)
Wiki

Handling content appears in multiple sites is something to watch out for. Portfolios are an obvious example of this.

Requirements

The following table is intended to be the general set of requirements applying to the overall process. Each of these tools will have their own specialized requirements.

Priority 1: Must have. Blocker for releasing the feature
Priority 2: Highly desirable. May be worth delaying the release
Priority 3: Nice to have

Requirement	Description	Priority
Static archive & view	Archive the site/tool information to a format that can be viewed at a later date. Provide a view of that information that is human readable for historical/investigative purposes.	1
Archive viewer	There should be the ability to view an archived Sakai site without using Sakai.	3
Same version live archive & import	Archive the site/tool data to a format that can be imported by the same version of Sakai and used as if the site had not been deleted.	2
Import past archive	Take an archive from the previous version of Sakai and import it into the current version. (This is really a potential requirement for the next release.)	3 (N/A)
Hard Delete	Remove as much data as possible from the database and remove accessibility of the site. By default, a hard delete should create an archive.	1
Soft Delete	Support a "soft delete" that simply makes a site inaccessible from all but defined administrative roles. The side can easily be restored by the person who deleted it (or others with appropriate permissions).	2
Multiple Site Delete	Soft or Hard delete of sites selected based on criteria such as: Age of site Amount of time in "soft delete" state (obviously for hard delete only) Size of site data (possible to calculate?) Number of participants (as proxy for size) Type of site Position in site hierarchy	3
Authorization	The permission to archive, delete and restore sites should be configurable. The "hard delete" function is generally going to be performed by a senior administrative resource. At certain organizations, "soft delete" may be available to site owners.	1
Operation Scope	The process of archiving/deleting/restoring a site should be configurable; allowing a user to specify which data should be operated on. For example, archive everything and delete everything but the announcements.	3
Archive format	The archive file(s) should be independent from other Sakai sites. The archive should contain the content needed to restore it.	2
Performance	The archive/delete process should be able to be performed without requiring system downtime. The amount of computing resources allocated to the process should be configurable by an administrator.	1
Cross-site content	The delete process should preserve content that appears in multiple sites.	1

Work Estimates

Note: General concerns that not all data is "site" data when you are talking about site archive/deletion in general.

Section Info - stores its data as part of site service, so covered through work on it
Roster - ?

Requirement	Samigo	Announcements	Assignments	Resources
Static archive & view	1 week or more	2 days	1 week	1 week
Archive viewer	?	?	?	?
Same version live archive & import	1 week	1 week	1 week	1 week
Import past archive	?	?	?	?
Hard Delete	1 week	1 week	2 weeks	2 weeks
Soft Delete		2-4 weeks	2-4 weeks	2-4 weeks
Multiple Site Delete	?	?	?	?
Authorization		?	?	?
Operation Scope		?	?	?
Archive format	part of static archive & view above	?	?	?
Performance	?	?	?	?
Cross-site content	note that Assessment Types and Question Pools in Samigo belong to the person, not the site, so they will not be archived/deleted	2-4 days	2-4 days	2-4 days

Have not heard from: Chat, Email Archive, Forums, Gradebook, Test Center (Mneme), Wiki

Alternatives

It is possible to conceive of providing much of this capability by simply implementing hard delete and having institutions run a second copy of Sakai that provides access to past sites.