Page tree
Skip to end of metadata
Go to start of metadata
Your Rating: Results: 1 Star2 Star3 Star4 Star5 Star 91 rates

GREYProposal for partial backup and restore solution.GREY
While we have implemented a full backup & restore tool (EE only) we have not yet a solution for partial backups and partial recovery of instances
Use cases:

  • export/import content without versions (export content without version / import into a new fresh database)
  • repairing an instance (lets say the filters were removed) and one needs to bootstrap a configuration file

Problems to consider:

  • bootstrapping configuration on a running instance leads to ugly log entries and needs a restart
  • out of memory: even with workspace imports big file imports can lead to memory out issues due to caching of some data in JR
  • exports of root nodes don't work as the jcr:system (including all versions) are exported then

Foundation

  • back und restore JSP scripts
  • normal export import

Ideas

1) Support bootstrapping of big files in installation
The webapp module installation should be changed so that big files can be imported on startup

  • use workspace imports (not importing into the session and only saving once all is done)
  • use all other mechanism like executing the splitter, ...

2) Big file should be splitted

  • if a bootstrap file is to big (lets day > 20MB) it gets split by using the xml splitter (exists in current backup module)

3) Use GC Thread

  • similar to the restore.jsp script we could start a thread which monitors the free memory and runs gc emediately

4) Compound Export (taken from backup.jsp)

  • export several atom locations (one can't export from the root)
  • export several workspaces at the same time
  • add order files (for restoring the files in the same order)
  • apply file splitting?
  • add .order files
  • zip it to a single file

5) introduce .order files (taken from the restore.jsp)

  • support *.order files which can define the import order

6) Recovery listener / filter

  • a minimal listener and filter which guaranties few things (context, recovery security manager, activation , ..)

7) Introduce run levels

  • level 1: before repository is started
  • level 2: the repository is started but no magnolia component
  • level 3: modules started
  • level 4: filter
  • allow registration of a scripts at the various points

A property could be used to define the level to which magnolia starts up. This allows to execute installation tasks / condition / shell scripts on various levels of execution.