rewrite parts of the automatic backup section

projektdokumentation/projektdokumentation.org

@@ -2164,61 +2164,66 @@ Repository Statistik aktualisiert, um den neuen Zustand wiederzugeben.
 
 ** Automatische Backups
 
-Damit der Benutzer die Backups von Hand machen muss, ist es sinnvoll eine
+Damit der Benutzer die Backups nicht von Hand machen muss, ist es sinnvoll eine
 Funktion bereitzustellen, welche die Backups automatisch im Hintergrund
 erledigt. Dadurch ist sichergestellt das die Backups im allgemeinen Trubel des
 Lebens nicht vergessen gehen.
 
-Damit automatische Backups überhaupt möglich sind muss die Applikation zuerst
+Voraussetzung für automatisierte Backups ist das die Datensicherung ohne
-Backups im Hintergrund erstellen können, also ohne das die ganze grafische
+gls:gui gestartet werden kann. Bei Borg-Qt wird dies über einen Kommandozeilen
-Oberfläche angezeigt wird. Bei Borg-Qt wird dies über einen Kommandozeilen
 Parameter realisiert. Hierfür wurde das Python Standard Paket ~argparser~
-verwendet. Konkret bedeutet dies, dass wenn man die Applikation auf
+verwendet. Konkret bedeutet dies, dass wenn die Applikation auf der
-der Kommandozeile wie folgt ausführt: ~borg_qt -B~. Wird die grafische Oberfläche
+Kommandozeile mit folgendem Befehl ausgeführt wird: ~borg_qt -B~. Wird die
-nicht angezeigt und es wird direkt die Methode ~background_backup~ der Klasse
+grafische Oberfläche nicht angezeigt und es wird direkt die Methode
-~MainWindow~ ausgeführt. Dabei werden alle Ordner, welche in den Einstellungen
+~background_backup~ der Klasse ~MainWindow~ ausgeführt. Dabei werden alle
-unter "Include" sowie "Exclude" gespeichert wurden, im Archiv gesichert,
+Ordner, welche in den Einstellungen unter "Include" sowie "Exclude" gespeichert
-respektive davon ausgeschlossen. Damit sind die Voraussetzungen für
+wurden, im Archiv gesichert, respektive davon ausgeschlossen. Damit sind die
-automatische Backups gegeben.
+Voraussetzungen für automatische Backups gegeben.
 
 Um die Backups in regelmässigen Intervallen auszuführen, gibt es zwei
-Möglichkeiten, wie man dies implementieren könnte. Zum einen könnte man die
+Möglichkeiten, wie man dies implementieren könnte.
-Applikation permanent im Hintergrund laufen lassen, etwa als Trayicon wie man
+
-das von anderen Applikationen wie etwas Dropbox kennt zum anderen kann man es
+Variante a), die Applikation permanent im Hintergrund laufen lassen, etwa als
-über Werkzeuge des Betriebssystems bewerkstelligen. Die drei
+Trayicon wie man das von anderen Applikationen wie etwas Dropbox kennt.
-Desktop Betriebsysteme, Windows, OS X und Linux, bringen alle drei Werkzeuge
+
-mit, um periodisch ein Programm auszuführen. Unter Linux wurde dies früher mit
+Variante b) über Werkzeuge des Betriebssystems. Die drei Desktop
-sogenannten Cron Jobs gemacht. Die moderne Lösung sind heutzutage jedoch
+Betriebsysteme, Windows, OS X und Linux, bringen alle drei Werkzeuge mit, um
-Systemd Timer. Für Borg-Qt wurde beschlossen es mit den Werkzeugen des
+periodisch ein Programm auszuführen.
-Betriebssystems zu machen. Also konkret Systemd. Dies aus dem Grund das Systemd
+
-genau für das Managen von Applikationen programmiert wurde. Ein Grossteil der
+Für Borg-Qt wurde beschlossen Variante b) zu realisieren. Die Anwendung soll
-Funktion ist bereits in Systemd enthalten, somit kann man Zeit sparen. Zudem
+dem Benutzer soweit als möglich aus dem Weg gehen. Eine Anwendung welche
-soll die Anwendung dem Benutzer auch soweit als möglich aus dem Weg gehen. Eine
+permanent in der Taskleiste lebt erfüllt das Kriterum nicht.
-Applikation, welche permanent in der Taskleiste lebt scheint hier nicht wirklich
+
-das Kriterium zu erfüllen.
+Unter Linux wurden sich wiederholende Aufgaben, früher mit sogenannten Cron
+Jobs umgesetzt. Die moderne Lösung sind heutzutage jedoch Systemd Timer. Also
+konkret Systemd. Dies aus dem Grund das Systemd genau für das Managen von
+Systemdiensten programmiert wurde. Ein Grossteil der benötigten Funktion ist
+bereits in Systemd enthalten, somit kann bei der Entwicklung zusätzlich Zeit
+gespart werden.
 
 Systemd ist ein init System, welches dazu dient dazu die Benutzerumgebung und
 die dazugehörigen Prozesse zu starten und zu verwalten footcite:systemd. Die
 Prozesse werden über sogenannte "Services" gestartet. Die Services werden dabei
 einfach in Klartextdateien mit der Dateiendung ~.service~ definiert. Der Inhalt
 orientiert sich dabei praktischerweise am "INI" Stil. In Borg-Qt wurde das INI
-Format bereits bei den Konfigurationsdateien verwendet. Somit können dort
+Format bereits bei den Konfigurationsdateien verwendet. Somit können die dort
-gesammelte Erfahrungen wiederverwendet werden. Soll ein Service in einem
+gesammelte Erfahrungen zur Implementation von ~configparser~ wiederverwendet
-gewissen Zeitintervall ausgeführt werden benötigt Systemd eine weitere Datei mit
+werden. Soll ein Service in einem gewissen Zeitintervall ausgeführt werden
-dem gleichen Namen jedoch mit der Dateiendung ~.timer~ . Der Inhalt ist auch
+benötigt Systemd eine weitere Datei mit dem gleichen Namen jedoch mit der
-wieder im INI Stil gehalten. Systemd versteht eine Vielzahl an Datumsformaten
+Dateiendung ~.timer~ . Der Inhalt ist auch wieder im INI Stil gehalten. Systemd
-footcite:systemddate. In Borg-Qt wurden zwei Varianten in den Einstellungen
+versteht eine Vielzahl an Datumsformaten footcite:systemddate. In Borg-Qt
-umgesetzt. Eine, welche "Predefined Schedule" genannt wurde und eine mit dem
+wurden zwei Varianten in den Einstellungen umgesetzt. Eine, welche "Predefined
-Namen "Custom Schedule", zu sehen in, Abbildung:([[fig:schedule]]). Die Predefined
+Schedule" genannt wurde und eine mit dem Namen "Custom Schedule", zu sehen in,
-Option wird dabei in die von Systemd unterstützten Formate "hourly", "daily",
+Abbildung:([[fig:schedule]]). Die Predefined Option wird dabei in die von Systemd
-"weekly" und "monthly" übersetzt. Wie der Name schon sagt, wird dann stündlich,
+unterstützten Formate "hourly, daily, weekly und monthly" übersetzt.
-täglich, wöchentlich oder monatlich ein Archiv erstellt. Mit der Custom Option
+Entsprechend der gewählten Wiederholung wird automatisch ein Archiv erstellt.
-kann der Benutzer sich den Zeitplan individueller gestalten. Etwa "jeden
+Mit der Custom Option kann der Benutzer sich den Zeitplan individueller
-Mittwoch um 12:00 Uhr" für Systemd übersetzt würde dieser Zeitplan dann so
+gestalten. Etwa "jeden Mittwoch um 12:00 Uhr" für Systemd übersetzt würde
-aussehen: ~Wednesday *-*-* 12:00:00~. Für spätere Versionen von Borg-Qt wäre es
+dieser Zeitplan dann so aussehen: ~Wednesday *-*-* 12:00:00~. Für spätere
-allenfalls auch möglich die Auswahl von mehreren Wochentagen zu ermöglichen
+Versionen von Borg-Qt wäre es allenfalls auch möglich die Auswahl von mehreren
-damit der Benutzer etwa folgenden Zeitplan erstellen könnte "Montag, Mittwoch,
+Wochentagen zu ermöglichen damit der Benutzer etwa folgenden Zeitplan erstellen
-Freitag stündliche Backups." (~Monday, Wednesday, Friday *-*-* *:00:00~).
+könnte "Montag, Mittwoch, Freitag stündliche Backups." (~Monday, Wednesday,
+Friday *-*-* *:00:00~).
 
 #+caption: Screenshot der "Schedule" Einstellungen
 #+name: fig:schedule
@@ -2227,7 +2232,7 @@ Freitag stündliche Backups." (~Monday, Wednesday, Friday *-*-* *:00:00~).
 
 Das Erstellen der eigentlichen Systemd Konfiguration passiert in Borg-Qt in der
 ~Config~ Klasse zum gleichen Zeitpunkt, wie die eigentliche Konfigurationsdatei
-geschrieben wird. Zum Schreiben und he-/aktivieren des Systemd Services,
+geschrieben wird. Zum Schreiben und de-/aktivieren des Systemd Services,
 respektive Timers wurde eine Klasse ~SystemdFile~ erstellt. Somit könnte
 die Funktion auch einfach in einem anderen Projekt verwendet werden.