UC-2 Offline Backup/Mirroring

ref#	UC-2
use case	Offline backup and mirroring
type	primary, essential
actors	archive manager, system
purpose	To provide a backup of the network hub for output to member stations' local storage
overview	An LS Network hub should be able to create an entire or incremental mirror of its library complete with scheduled playlists, component files and scheduled dates/times. Such a backup, written to a medium such as DVD or portable hard disk, could then be physically sent to member stations, who would then import the material with one step (or very easy set of steps). The above steps could be repeated regularly, with only incremental changes sent in each additional step.
references	UC-3 UC-4 UC-5 UC-6 #1579* ArchiveFormat

Typical course of events

Backup / export

pre-conditions	The archive manager is logged in, and has suffucient privileges to complete the tasks below.
post-conditions	An off-line archive is created as a file.

	Actor Action		System response
1.	Network backup	2.	Menu prompts user to set parameters of backup. Parameters will include 1. - a (possibly complex) search criteria for what to back up 2. - a selection of time frame to make the backup from: 2.1 - select from the list of past backup events in time, and back up everything since then 2.2 - select a specific time point and backup everything since then 3. - select if the schedule should be included for the specified time frame
3.	User specifies the backup criteria by the parameters offered in 2.	4.	System processes the parameters and calculates the estimated storage space needed for the backup
5.1	User refines parameters (back to 3.)
5.2	User selects location to save backup file	6.	System creates backup file at specified location. The backup file includes all changes to the entries specified in the search criteria at 3., since the time point specified at 3.

Import

pre-conditions	The archive manager is logged in, and has suffucient privileges to complete the tasks below. A backup file is available as described in the Backup / export step
post-conditions	The contents of the backup file are merged into the system.

	Actor Action		System response
1.	User accesses the system with the intention of importing a backup file	2.	System offers to select a backup file
3.	User select a backup file from a filesystem location	4.	System reads the backup file, and merges its contents with the current state of the archive and the scheduler

exceptions

• 4.1 conflicting scheduler entries are found within the backup and the current state of the scheduler
• 4.2 entries are found both in the imported backup and the archive that have the same ID, but are different in content. should the backup automatically override?

Typical incremental usage

pre-conditions	The archive manager is logged in, and has suffucient privileges to complete the tasks below. There's a central and a remote system that needs to be syncronized.
post-conditions	The central and remote systems are syncronized on a regular basis.

	Actor Action		System response
1.	The archive manager creates an initial backup from on the central system	2.	The central system generates the backup file.
3.1	The file is written to a storage media (DVD, external hard drive, flash drive, etc.), and is physically transferred to the remote systems location
3.2	The file is sent by arbitrary network methods (e-mail, FTP, etc.) to the remote systems location
4.	The archive manager imports the backup into the remote system	5.	The remote system is in sync with the central system at the time of backup
6.	The archive manager creates a new backup, specifying the last backup point as the start of the timeframe for the backup	7.	The central system creates a backup with all the changes since the last backup was made
8.	The backup file is transffered, similarly to 3.1 or 3.2
9.	The archive manager imports the incremental backup at the remote system	10.	The remote system updates its contents, so it is in sync with the central system at the time of backup
11.	repeat steps 6. - 10. to maintain sync between the central and the archive system

XML-RPC interface

The XML-RPC interface for this is similar to searchMetadata.

locstor.createBackupOpen

• input:
  • sessid
  • criteria
• output:
  • token

locstor.createBackupCheckStatus

• input:
  • token
• output:
  • status: string - one of "success", "working" or "fault"
  • (if "success") url
  • (if "success", maybe) metadata: string - a copy of the metafile in the archive (see ArchiveFormat)
  • (if "fault") faultString

locstor.createBackupClose

• input:
  • token

Where criteria is the same kind of struct as for search, with two extra features:

• a modifiedSince: date-time field, needed for incremental use
• an extra pseudo-metadata category uniqueId.

If we want an archive made of a list of audio clips or playlists, we can set the criteria parameter to something like

{ filetype: all,
  operator: or,
  conditions: ( { cat: uniqueId, op: =, val: 12345 },
                { cat: uniqueId, op: =, val: 12346 },
                ...
                { cat: uniqueId, op: =, val: 12350 } )
}

Question: do we want to return a copy of the metafile in the XML-RPC response? This could be very wasteful for large archives, but it could simplify things at the other end. Possibly make it optional?