572
edits
Changes
Jump to navigation
Jump to search
Line 20:
Line 20: +
Features/Backup and Restore/Enhancements (view source)
Revision as of 20:13, 12 November 2013
, 20:13, 12 November 2013→Difficulties
== Difficulties ==
== Difficulties ==
* Currently, the actual backup-to-memory-stick makes big assumptions about storage while doing backups. It assumes that the target memory stick is going to have sufficient available space, not much information is gathered from the copying process. The other way around, when doing restores it also assumes that the XO has sufficient space, and is kind of dangerous because: (a) starts by deleting the current journal content and (b) it probably has one of two restoring policies.
* Currently, the actual backup-to-memory-stick makes big assumptions about storage while doing backups. It assumes that the target memory stick is going to have sufficient available space, not much information is gathered from the copying process. The other way around, when doing restores it also assumes that the XO has sufficient space, and is kind of dangerous because: (a) starts by deleting the current journal content and (b) it probably has one of two restoring policies.
=== Policies ===
* P1: all or nothing, meaning that if the XO has not sufficient space it would abort the whole process.
* P1: all or nothing, meaning that if the XO has not sufficient space it would abort the whole process.
* 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.