These are some ideas for implementing an offsite backup facility for Gnosis. See (p3,back-do) for backing up discreet objects. See (new-ideas,03) concerning tape checkpoints.

An offsite backup facility will consist of a method of taking tape dumps of Gnosis files and making incremental change tapes of the changes that occur as Gnosis runs. These, combined with a program to use the tapes to place a set of Gnosis packs in a consistent state will allow a Gnosis system to be brought up from tape backup.

An unimplemented idea along these lines:

Dumps
A "major system checkpoint" could be taken during some time of low system activity to allow the entire contents of the system to be backed up. When such an event was declared, all of the home ranges would become {temporarily} inaccessible for write. The modified pages would remain "in limbo" in the system swap areas until such time as their home addresses had been safely dumped, and were thus available again for write.

A particular program would have the responsibility for causing the pages to be read into core, approximately at the rate of one cylinder at a time, and then to write the pages onto a tape. The program would need the ability to read disk pages containing nodes as if they were data pages. There are a few loose ends here involving how to write the allocation counts (etc) on tape.

Incremental Dumps
Gnosis "home" ranges can be dumped, in a consistent state in the space of time between the end of a migration and the beginning of the next checkpoint. A collection of these dumps could be synchronized by completing the needed migrations to older dumps from the log tapes (see below).

If the migration process {(migrate)} wrote the pages and nodepots being migrated to the "home" locations to tape at the same time it was writing then to the "home" position then there would be a nearly complete log facility. The only essential information that would not be recorded by this process would be the list of nodes that had processes in them. This could also be written to the tapes when the checkpoint is taken.

A complete system backup set would consist of the dump tapes and all the log tapes created while the dumps were being taken.

Problems with this approach.
This would seem to require that tape write error recovery logic be included in the Gnosis Kernel.

A "stand alone" utility to build packs from a dump and log tape set would be needed.

Like all backup schemes, this one has significant security implications.

More somewhat complex code in the Kernel (how can we reduce the amount??)

Additional opportunities.
If log tapes are produced continuously, then it would be possible to recover a single bad pack by:
Restoring the pack from the last dump of the pack.
Remigrating all the migrations stored on the log tapes since the dump. Then the pack could be treated the same as a pack that had been removed from the system. (Will this work for a pack that has swap ranges?).

I speculate here about a scheme for selective recovery from these backups.

These backups provide page and node images, by CDA, for an entire pack set. Several important objects consist of node trees with pages at the leaves. I imagine a service wherein there is a key TB with limited authority to a tape backup. Presenting a segmode key to TB would produce a new segment much like the corresponding segment represented on the tape.

It is feasible to read all the node images into a segment. With the CDA of a node it is possible to build a node tree that matches the original at the time of the backup and thence to layout a strategy of mounting tape reels so as to avoid unnecessary tape mounts. It would seem that all of the trailing "rewritten pages" would have to be scaned as part of this process. Simultaneous retrieval of several such segments would be possible.