Changes

* Currently, the general design include options at the volumes toolbar. This is kind of problematic since not all back-ends can be exposed as volumes.

* Currently, the general design include options at the volumes toolbar. This is kind of problematic since not all back-ends can be exposed as volumes.

* Other idea proposes centralizing all backup and restore options, by moving it to the Journal toolbar but that one is already full with options, and this is not something it should be seen at the time.

* Other idea proposes centralizing all backup and restore options, by moving it to the Journal toolbar but that one is already full with options, and this is not something it should be seen at the time.

* Another idea is to move this options to the Home view or Frame icon or to a control-panel widget.

* Another idea is to move this options to the Home view or Frame icon or to a control-panel widget.

* Currently, the dialog is a modal window that covers the whole screen. The reason behind this is that, the current scripts must be shutdown the datastore for being able to compress and copy the current state of the datastore and its necessary to restart after the process is finished.  

* Currently, the dialog is a modal window that covers the whole screen. The reason behind this is that, the current scripts must be shutdown the datastore for being able to compress and copy the current state of the datastore and its necessary to restart after the process is finished.  

* No suggestions yet, but the necessity of this aggressive modal depends on how we implement the back-ends.

* No suggestions yet, but the necessity of this aggressive modal depends on how we implement the back-ends.

== Back-ends ==

== Back-ends ==

* One of the enhancements ideas is to move this code to Sugar by defining an abstract class or template for implementing backup and restore back-ends. This template should handle the interactions defined by the triggering methods and progress dialog.

* One of the enhancements ideas is to move this code to Sugar by defining an abstract class or template for implementing backup and restore back-ends. This template should handle the interactions defined by the triggering methods and progress dialog.

* We should start by something simple like backup-to-memory-stick, but we could already have something in mind, based on web services and see if its makes sense under that scenario.

* We should start by something simple like backup-to-memory-stick, but we could already have something in mind, based on web services and see if its makes sense under that scenario.

== Format ==

== Format ==

* P2: best-effort, meanng that it will copy as much as it can, but the user has no decision over what data is going to be left behind.

* P2: best-effort, meanng that it will copy as much as it can, but the user has no decision over what data is going to be left behind.

* We need to define the policies for our backup and restore processes. We could keep one of these policies, but we should at least give it some thought. It is obvious that some back-ends could support different policies but that could be a problem from user POV, because it could be confusing.

* We need to define the policies for our backup and restore processes. We could keep one of these policies, but we should at least give it some thought. It is obvious that some back-ends could support different policies but that could be a problem from user POV, because it could be confusing.