OneNote-Backup, nun in effizient

Vor einer ganzen Weile habe ich mich schon einmal darüber ausgelassen, dass das so mit den Backups unter OneNote nicht schön ist. Eine Art Versionierung wollte ich haben, damit ich cloud-unabhängig auch bei versehentlichen Löschungen nichts verliere. Bisher gab es also eine Liste mit Abschnitten, die aus dem Notizbuch auf OneDrive geglaubt wurden, heruntergeladen und anschließend archiviert. Das wurde spätestens beim zweiten Notizbuch unübersichtlich, und ein neuer Ansatz musste her; skalierbar bitte:

Ein neues Microsoftkonto, mit dem die zu sichernden Notizbücher geteilt werden, wird über die API benutzt. Sinn dahinter: alle Notizbücher, die mit diesem Konto geteilt sind, werden heruntergeladen. Und weil ich mich nun einmal aufraffen konnte, das ganze neu zu entwickeln, ist jetzt auch die Liste mit den Abschnitten hinfällig, sondern es werden einfach alle Abschnitte gesichert, die nicht in einer Unterkategorie gelandet sind. Letzteres nicht mit zu sichern ist dann primär meine Faulheit, hier noch eine Iteration einzubauen.

Jede Nacht wird das Backup ausgeführt, anschließend auf einen entfernten Webspace per rsync über SSH hochgeladen und in Folge dessen noch aufgeräumt, was sich angestaut hat. Das meint: Backups älter als drei Wochen werden auf dem entfernten Webspace gelöscht, Backups älter als drei Tage auf dem Server selbst. Wie das Ganze nun funktioniert, versuche ich, schrittweise aufzuzeigen:

Server vorbereiten

Wir brauchen einen Linux-Server, auf dem ein paar Tools installiert sind. Im folgenden Schritt hilft selbiger auch bei der API-Key-Erstellung. Ich gehe von Debian Jessie aus; andere Systeme benötigen hier vermutlich andere Befehlsketten, die aber ähnlich sein dürften.

benötigte Pakete installieren

(rsync und sshpass können entfallen, wenn nach dem Download kein erneuter Upload auf ein SSH-rsync-Ziel geplant ist)

sudo apt-get install jq curl rsync sshpass

wget kompilieren

Selbst wenn wget vorhanden ist, benötigen wir ein Feature, das sich bei meinen Tests als sinnvoll herausgestellt hat und erst ab wget 1.19 vorhanden ist: Retry on specific http error codes. Das ermöglicht, bei einem Error 503, der mir ein paar Mal begegnete, wget anzuweisen, es einfach nochmal zu versuchen und die Datei nicht zu übergehen. Debian hat Stand 05/17 in keiner Version wget 1.19.1 enthalten, nicht einmal in testing.

Somit haben wir unter ~/onedrive/wget/wget eine verwendbare Binary von wget 1.19.1. Die werden wir später verwenden.

Microsoft-Konto erstellen und API-Token anfordern

  1. Zu Beginn ist ein normales Microsoft-Konto vonnöten, wie es bei „Winzigweich“ an allen Ecken und Enden angelegt werden kann. Dies darf aber nicht das gleiche Konto sein, in welchem die zu sichernden Notizbücher liegen, da meine Skripte erwarten, dass die zu sichernden Notizbücher mit dem neuen Konto geteilt wurden, und nicht im kontoeigenen OneDrive-Speicher des neuen Kontos liegen.
  2. Um einen API-Zugang zu bekommen, muss eine „App“ erstellt werden. Das geht in den Microsoft Developer Resources, hinter dem Button „Registrieren Sie Ihre App“. Anschließend klicken wir auf ein unscheinbares „Skip quickstart“ rechts oben in der Ecke, anschließend können wir über einer leeren App-Liste auf „App hinzufügen“ klicken und einen x-beliebigen Namen („OneNoteBackup“, „Hundekuchen“, „MuttisLiebling“) für unsere neue „App“ vergeben. Der Name spielt keine tiefere Rolle.
    1. Wichtig: Die Anwendungs-ID irgendwo notieren. Die wird später noch relevant.
    2. Auf der Seite der App-Eigenschaften nun den Button „Plattform hinzufügen“ suchen und finden, dann klicken. Anschließend „Web“ wählen und als Umleitungs-URL https://login.live.com/oauth20_desktop.srf hinterlegen. Alles Weitere spielt keine Rolle, wir brauchen keine Anwendungsgeheimnisse, keine lustigen Logos oder Homepage-URLs für den Betrieb. Ganz unten „Speichern“.
  3. Nun wirds ein bisschen speziell: in irgendeinem Browser muss die URL https://login.live.com/oauth20_authorize.srf?client_id=<ANWENDUNGS-ID>&scope=onedrive.readonly offline_access&response_type=code&redirect_uri=https://login.live.com/oauth20_desktop.srf aufgerufen werden, wobei <ANWENDUNGS-ID> gegen die in Schritt 2.1 notierte Anwendungs-ID ersetzt werden muss. Im Browser wird man nun nach der Berechtigung für die eigene App gefragt, auf OneDrive zugreifen zu dürfen. Diese muss natürlich gewährt werden.
  4. Theoretisch dürfte nun nur eine weiße Seite erscheinen. Das ist soweit normal, aber die URL hat sich geändert. Die aktuelle Adresse in der Adresszeile muss nun rauskopiert werden, oder genauer der Teil nach ?code= bis zum nächsten & .
  5. Nun müssen wir den Code relativ zeitnah an Microsoft schicken, und zwar nicht etwa per Einschreiben, sondern per POST-Request. Hier bietet sich CURL an: curl -X POST -d „client_id=<ANWENDUNGS-ID>&redirect_uri=https://login.live.com/oauth20_desktop.srf&code=<CODE_VON_EBEN>&grant_type=authorization_code“ https://login.live.com/oauth20_token.srf  – Bitte <ANWENDUNGS-ID>  durch die Anwendungs-ID und <CODE_VON_EBEN>  durch den gerade in Schritt 4 erhaltenen Code ersetzen.
  6. Als Antwort bekommen wir JSON, worin irgendein Feld „refresh_token“ heißt. Diesen Token brauchen wir. Microsoft selbst gibt da für die Antwort auf den POST folgendes Beispiel:

    Uns interessiert also nur der Inhalt des letzten Feldes.
  7. Jetzt sollten wir zwei Informationen haben, die wir notieren, falls noch nicht geschehen:
    1. die Anwendungs-ID
    2. den refresh_token.

Geskripte auf dem Server

Es ist jetzt an der Zeit, alles zusammenzuführen – den Server, die Notizbücher, die IDs. Dazu gibt’s von mir folgendes kleines Skript:

(in der dritten Zeile <ANWENDUNGS-ID> und <REFRESH-TOKEN> entsprechend ersetzen)

Das ganze als backup.sh im zukünftigen Backup-Verzeichnis speichern und mit chmod +x backup.sh ausführbar machen. Jetzt können wir immerhin die Dateien schon herunterladen, aber noch nicht wieder hochladen. Diese Funktion habe ich in ein zweites Skript ausgegliedert, um die Backups zu komprimieren und per rsync wieder hochzuladen:

Gleiches Spiel: als post-dl.sh im zukünftigen Backup-Verzeichnis speichern und mit chmod +x post-dl.sh ausführbar machen. Während der ersten Durchführungen wird natürlich ein Fehler angezeigt werden, da noch kein Backup von vor 3 Wochen existiert. Der kann getrost ignoriert werden.

Eine Lösung, um die lokalen Backups nach drei Tagen zu löschen, habe ich hier jetzt nicht aufgezeigt – das kann analog zur post-dl.sh  als Cronjob geschehen, indem einfach die LASTDATE -Variable modifiziert wird und entsprechend dem die alten Backups gelöscht.

Bei Fragen, Kritik und Anregungen einfach kurz unten drunter oder per Kontaktformular melden – vielleicht hats ja jemandem geholfen.

1 thought on “OneNote-Backup, nun in effizient

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.