{"id":11,"date":"2020-02-18T22:05:43","date_gmt":"2020-02-18T21:05:43","guid":{"rendered":"https:\/\/i4archive.com\/?p=11"},"modified":"2020-02-18T22:05:43","modified_gmt":"2020-02-18T21:05:43","slug":"wie-die-sicherung-funktionierthow-it-works","status":"publish","type":"post","link":"https:\/\/i4archive.com\/?p=11","title":{"rendered":"Wie die Sicherung funktioniert<\/app-de>How it works<\/app-en>"},"content":{"rendered":"

Die Sicherung mit mystore<\/em> erfolgt nach dem Prinzip des Zyklischen-Hashes (cyclic hash). Vereinfacht gesprochen werden die zu sichernden Dateien mittels des Zyklischen Hashwerts in Fragmente geteilt und gespeichert. \u00dcber Indexdaten k\u00f6nnen die Originaldateien wieder hergestellt werden. Die Aufteilung in Fragmente hat den Vorteil, dass gleiche Fragmente nicht zweimal gespeichert werden m\u00fcssen. Dieser Vorteil tritt bei vollst\u00e4ndig gleichen Dateien von selbst auf. Wenn aber in einer gr\u00f6\u00dferen Datei nur wenig ver\u00e4ndert wurde, dann ist die Chance vorhanden, dass \u00fcber den Zyklischen Hash Fragmente so gebildet werden, dass einige Fragmente gleich und nur wenige Fragmente unterschiedlich sind. Tats\u00e4chlich ist dieser Effekt f\u00fcr eine ’normale‘ Sicherung nur gering, da die Fragmentgr\u00f6\u00dfe per default mit 20 bit recht hoch ist. F\u00fcr eigene Experimente und zur Justierung bei Sonderf\u00e4llen gibt es bei mystore<\/em> den Schalter --break-bits N<\/code>. Die ungef\u00e4hre Gr\u00f6\u00dfe der Fragmente wird als Bitwert angegeben.<\/app-de>Storing with mystore<\/em> is based on the principle of the cyclic hash. Put simply, the files to be stored are divided into fragments and saved. The original file data is restored using index data. The division into fragments has the advantage that same fragments do not have to be saved twice. This advantage occurs automatically with completely identical files. If, however, in a larger file little has been changed, then there is a chance that fragments will be formed over the cyclic hash in such a way that some fragments are the same and only a few fragments are different. In fact, this effect is only slight for a ’normal‘ store, since the fragment size is quite high by default with 20 bits. The --break-bits N<\/code> switch is available for your own experiments and for adjustment in special cases. The approximate size of the fragments is given as a bit value.<\/app-en><\/p>\n

Jedes Fragment wird mit dem Algorithmus SHA-1 gehasht und mittels des Deflate-Algorithmus komprimiert und mit dem SHA-1 Hashwert als Namen im Dateisystem gespeichert. Der Algorithmus SHA-1 ist f\u00fcr diese Anwendung geeignet, da er nur zur Unterscheidung zweier Fragmente genutzt wird. Einen Angriff gegen gef\u00e4lschte Duplikate muss der Hashwert nicht widerstehen. Damit die anwachsende Zahl von Fragmenten \u00fcbersichtlich bleibt, erfolgt die Speicherung in Verzeichnissen, die mit dem ersten Byte des Hashwertes benannt sind. Zur absoluten Begrenzung der Anzahl verwendeter Dateien werden alle Fragemente mit Hashwerten, die mit zwei gleichen Bytes beginnen, in eine Datei gepackt. Durch diese Ma\u00dfnahme wird die Anzahl der Dateien f\u00fcr Fragmente bei einer Speichertiefe von 1 absolut auf 2^16 = 64 *1024 Dateien begrenzt. Zum Experimentieren und f\u00fcr Sonderf\u00e4lle gibt es bei mystore<\/em> den Schalter --store-depth N<\/code> zur Angabe der Speichertiefe. Per Default ist dieser Wert auf den kleinst m\u00f6glichen Wert 1 gesetzt. Ebenfalls f\u00fcr Experimente und f\u00fcr Sonderf\u00e4lle gibt es den Schalter --no-pack<\/code>. Dieser Schalter bewirkt, dass die Fragmente nicht gepackt, sondern separat als Dateien gespeichert werden. Wenn der Schalter --no-pack<\/code> angegeben wird, gibt es keine Beschr\u00e4nkung in der Anzahl der Dateien, die in der Sicherung erzeugt werden. Mit diesem Schalter ist vorsichtig umzugehen, da ein normales Dateisystem wie NTFS auf einem PC bei z. B. mehr als 100.000 Dateien in einem Verzeichnisbaum durchaus l\u00e4ngere Zeit alleine zum L\u00f6schen der Dateien ben\u00f6tigt. Das Dateisystem selber oder Programme, die mit dem Dateisystem arbeiten, k\u00f6nnen an der gro\u00dfen Menge an Dateien Schaden nehmen oder verursachen. Also bitte Achtung! Mit dem Default-Wert von 1 f\u00fcr --store-depth<\/code> kann das Sicherungsverzeichnis von mystore<\/em> bis ca. 1 Terabyte an Daten verwalten.<\/app-de>Each fragment is hashed using the SHA-1 algorithm and compressed using the deflate algorithm and saved with the hash value as it’s name in the file system. The SHA-1 algorithm is suitable for this application because it is only used to distinguish two fragments. The hash value does not have to withstand an attack against fake duplicates. To be the growing number of fragments remains clear, they are stored in directories named with the first byte of the hash value. To absolutely limit the number of files used, all fragments with hash values that begin with two identical bytes are packed into one file. With a storage depth of 1 the absolute number of files is limited to 2 ^ 16 = 64 * 1024. For experiments and special cases there is the switch --store-depth N<\/code> specifying the memory depth. By default, this value is set to the smallest possible value 1. The switch --no-pack<\/code> is available for experiments and special cases. It’s meaning is that fragments are not packed, but instead saved in separate files. In case of the switch --no-pack<\/code>, there is no limit to the number of files created by a store. This switch must be handled with care, since a normal file system such as NTFS on a PC with e.g. more than 100,000 files in a directory tree may take a long time to delete the files alone. The file system itself or programs that work on the file system can make a damage on the huge amount of file. Take care! With the default value of 1 for --store-depth<\/code> the backup directory of mystore<\/em> is able to manage up to approx. 1 terabyte of data.<\/app-en><\/p>\n

Weitergehende Sicherungsm\u00f6glichkeiten<\/app-de>More Storing Alternatives<\/app-en><\/h3>\n

Sicherungen mittels mystore<\/em> sind flexibel einstellbar, aber wirklich sinnvoll oder gar notwendig sind nur wenige Einstellungen und auch dann nur in wenigen Sonderf\u00e4llen. Fast immer sind die Default-Einstellungen nicht nur ausreichend, sondern auch am besten.<\/app-de>Storings using mystore<\/em> can be flexibly set, but only a few settings are really useful or even necessary, and then only in a few special cases. The default settings are almost always not only sufficient, but also the best.<\/app-en><\/p>\n

Eine n\u00fctzliche und weitergehende Sicherungsm\u00f6glichkeit bietet der Im- und Export von tar<\/em>-Archiven. Beim Import eines tar<\/em>-Archives wird von mystore<\/em> die tar<\/em>-Struktur interpretiert. In die Sicherung gelangen die enthaltenen Dateien und Verzeichnisse des tar<\/em>-Archivs, so als ob mystore<\/em> die Daten selbst aus dem Dateisystem gelesen h\u00e4tte. Der Import eines tar<\/em>-Archiv macht dort Sinn, wenn z. B. von einem entfernten Dateisystem eine Sicherung erfolgen soll. \u00dcber den Schalter --storage <Sicherungsverzeichnis><\/code> kann das Sicherungsverzeichnis von mystore<\/em> m\u00f6glicherweise nicht erreichbar sein, aber \u00fcber eine Weiterleitung als tar<\/em>-Archiv kann die Sicherung trotzdem erfolgen. Mit dem Schalter --tar<\/code> statt --store <Datei-oder-Verzeichnis><\/code> erwartet die Anwendung mystore<\/em> \u00fcber stdin<\/em> ein tar<\/em>-Archiv, dessen Struktur interpretiert wird und die Inhalte des tar<\/em>-Archivs werden als Bestandteile in die Sicherung \u00fcbernommen.<\/app-de>A useful option for storing is the import and export of tar<\/em> archives. When importing a tar<\/em> archive, mystore<\/em> interprets the tar<\/em> structure. The files and directories contained in the tar<\/em> archive are saved as if mystore<\/em> had read the data itself from the file system. Importing a tar<\/em> archive makes sense in case of, for example, reading from a remote file system. The mystore<\/em> storage directory may not be accessible via the --storage <folder><\/code> switch, but storing can still be done by forwarding the data as a tar<\/em> archive. Using the switch --tar<\/code> instead of --store <file-or-folder><\/code> the application mystore<\/em> expects a tar<\/em> archive via stdin<\/em>.<\/app-en><\/p>\n

cat my.tar | mystore --tar\ncat my.tgz | gzip -d | mystore --tar\n<\/pre>\n
F\u00fcr den Export eines tar<\/em>-Archivs gibt es keinen eigenen Schalter. Stattdessen wird implizit ein tar<\/em>-Archive gepackt, wenn als Restaurierungsverzeichnis – (dash<\/em>) als Parameter zum Schalter --restore-folder <Restaurierungsverzeichnis><\/code> angegeben wird. Das tar<\/em>-Archiv wird dann \u00fcber stdout<\/em> ausgegeben und kann entweder als Datei gespeichert oder \u00fcber eine Pipe (‚|‘) weitergeleitet werden.<\/app-de>There is no separate switch for exporting a tar<\/em> archive. Instead, a tar<\/em> archive is implicitly packed if the restoration directory – (dash<\/em>) is specified as <restore-folder><\/code> for the switch --restore-folder <restore-folder><\/code>. The tar<\/em> archive is then output via stdout<\/em> and can either be saved as a file or forwarded via pipe (‚|‘).<\/app-en><\/p>\n
mystore --restore-folder - --restore myfolder > my.tar\nmystore --restore-folder - --restore myfolder | gzip > my.tgz\n<\/pre>\n
F\u00fcr den Sonderfall, dass \u00fcber stdin<\/em> kein tar<\/em>-Archiv interpretiert werden soll, sondern die Daten als eigenst\u00e4ndige Datei gespeichert werden sollen, hat mystore<\/em> den Schalter --name <Name><\/code>. F\u00fcr die Ausgabe gibt es diese Besonderheit nicht. D. h. bei einer Ausgabe \u00fcber stdout<\/em> wird immer ein tar<\/em>-Archiv erzeugt.<\/app-de>For the special case that stdin<\/em> should not be interpreted as a tar<\/em> archive, but the data should be saved as an independent file, mystore<\/em> has the switch --name <name><\/code>. This peculiarity does not exist for output. Instead, an output via stdout<\/em> always creates a tar<\/em> archive.<\/app-en><\/p>\n","protected":false},"excerpt":{"rendered":"
Die Sicherung mit mystore erfolgt nach dem Prinzip des Zyklischen-Hashes (cyclic hash). Vereinfacht gesprochen werden die zu sichernden Dateien mittels des Zyklischen Hashwerts in Fragmente geteilt und gespeichert. \u00dcber Indexdaten k\u00f6nnen die Originaldateien wieder hergestellt werden. Die Aufteilung in Fragmente hat den Vorteil, dass gleiche Fragmente nicht zweimal gespeichert werden m\u00fcssen. Dieser Vorteil tritt bei […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":[],"categories":[1],"tags":[],"_links":{"self":[{"href":"https:\/\/i4archive.com\/index.php?rest_route=\/wp\/v2\/posts\/11"}],"collection":[{"href":"https:\/\/i4archive.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/i4archive.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/i4archive.com\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/i4archive.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=11"}],"version-history":[{"count":1,"href":"https:\/\/i4archive.com\/index.php?rest_route=\/wp\/v2\/posts\/11\/revisions"}],"predecessor-version":[{"id":12,"href":"https:\/\/i4archive.com\/index.php?rest_route=\/wp\/v2\/posts\/11\/revisions\/12"}],"wp:attachment":[{"href":"https:\/\/i4archive.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=11"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/i4archive.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=11"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/i4archive.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=11"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}