lukechilds
/
duplicati.github.io
mirror of https://github.com/lukechilds/duplicati.github.io.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity
Browse Source

Update 2016-03-19-Storage-Engine.md

master
Kenneth Skovhede 8 years ago
committed by GitHub
parent
23f71b308e
commit
f2f1e24aeb
1 changed files with 4 additions and 2 deletions
Whitespace
Show all changes Ignore whitespace when comparing lines Ignore changes in amount of whitespace Ignore changes in whitespace at EOL
Unified View
Diff Options
Show Stats Download Patch File Download Diff File
  1. 6
      _posts/articles/2016-03-19-Storage-Engine.md

6
_posts/articles/2016-03-19-Storage-Engine.md
View File

@ -12,15 +12,17 @@ excerpt: Duplicati 2.0 comes with an innovative block-based storage engine. Find
## Background ## Background
In Duplicati 1.3 backups were done and stored the following way: In Duplicati 1.3 backups were done and stored the following way:
* There was always a full backup followed by incremental backups. * There was always a full backup followed by incremental backups.
* The latest incremental backup was based on all previous backups. To restore latest files, all backup files were required. * The latest incremental backup was based on all previous backups. To restore latest files, all backup files were required.
* Files were written into compressed archives which were encrypted afterwards. * Files were written into compressed archives which were encrypted afterwards.
* The archives of incremental backups only contained the changes to the previous files. * The archives of incremental backups only contained the changes to the previous files.
This approach had some issues: This approach had some issues:
1. The chains of full and incremental backups could get very long. As a result of that the likeliness increased that the backup could be lost due to data corruption. 1. The chains of full and incremental backups could get very long. As a result of that the likeliness increased that the backup could be lost due to data corruption.
1. After a loss of data, users usually restore the latest version. This required to download the entire history of all changes and restoring went through the same history again making restoring slow. 2. After a loss of data, users usually restore the latest version. This required to download the entire history of all changes and restoring went through the same history again making restoring slow.
1. The recommended, regular full backups were a <insert bad word here>. 3. The recommended, regular full backups were a &lt;insert bad word here&gt;.
## New Storage Format ## New Storage Format

Write Preview
Loading…
Cancel
Save