Emby Server Backup auf Remote Server speichern (ohne das Plugin Backup & Restore)

Ich nutze Debian 9.3 worauf Emby läuft. Nun möchte ich gerne daß das Plugin Backup&Restore dieses Backup auf einem anderen Server speichert als Debian, denn nur so macht ja ein Backup nur wirklich Sinn. Denn was nützt mir das Backup von dem Plugin, wenn das komplette Debian abraucht.

Nun verlangt das Plugin, dass der Eigentümer des Verzeichnisses "emby(999)" ist.
Mein Problem ist jetzt, dass wenn ich über die fstab das Remote-Verzeichnis mounte, Dieses standardmäßig "root" gehört.
So funzt zwar der Mount, Eigentümer ist aber root

//192.168.99.99/srv-kodi/emby	/home/emby-backup	cifs	username=emby,password=emby	rw	0	0

Und so bleibt es aber auch bei root:

//192.168.99.99/srv-kodi/emby	/home/emby-backup	cifs	username=emby,password=emby	rw,uid=emby	0	0

Klar ist, dass ich als root vorher das Verzeichnis /home/emby-backup angelegt und dieses auch mit chown dem user emby zugewiesen habe.
Auch klar ist, dass auf //192.168.99.99/srv-kodi/emby user emby Schreibrechte hat.

Ich hab schon alles mögliche versucht, es will aber einfach nicht klappen.
Ich find aber auch nichts in den man-Pages, was mich weiterbringt:
https://manpages.debian.org/stretch/mount/fstab.5.en.html
https://manpages.debian.org/stretch/mount/mount.8.en.html

Das Paket cifs-utils hab ich jetzt noch nicht installiert, da ich glaube das hat nichts mit dem cifs-Protokoll zu tun, sondern rein mit Debian.
https://manpages.debian.org/stretch/cifs-u….cifs.8.en.html

Wo hab ich hier einen Fehler drinne?
Hinweis und Lösung im Lux-Forum gefunden.

Es müssen in der fstab in Sektor4 die Verzeichnis und Dateirechte mit übergeben werden; Paket cifs.mount nicht notwendig.

//192.168.99.99/srv-kodi/emby	/home/emby-backup	cifs	username=emby,password=emby,vers=2.0,uid=999,gid=999,file_mode=0644,dir_mode=0755	0	0

vers=2.0 <-- SMB-Version
ohne Angabe von uid und gid bleibt root Eigentümer / hier-> id=999=emby
volle Lese und Schreibrechte: file_mode=0644,dir_mode=0755
nur Leserechte: file_mode=0444,dir_mode=0555

Im Ubuntu-wiki gut beschrieben.

Das Backup-Script und HowTo ist in Post 12 zu finden.
Das Restore-Script und HowTo ist in Post 13 zu finden.

Zitat von mad-max

Was backuped der denn? Wenns ne reine Verzeichnisstruktur ist kannst du als Workaround rsync nehmen...das ist meiner Meinung nach das non plus ultra für Backups von Verzeichnissen auf remote Laufwerke unter Linux

Ja, das Plugin legt in /emby/backup ein Verzeichnis mit Namen "Emby Backup - Datum Uhrzeit" an und kopiert dort offensichtlich den kompletten Inhalt von /var/lib/emby rein - nicht mal gezippt.

Nun mit dem Würg-around müsste ich erstmal klar kommen mit Debian, rsync usw. - was nicht der Fall ist. Von Debian hab ich keine Ahnung. Ferner wüßte ich nicht, wie ich das in Emby reinbekommen soll, dass er nach dem Backup ein rsynch nach remote machen soll.

Zitat von McStarfighter

Hast du "emby" denn in "deine" Gruppe genommen?

Mein Account bei Kubuntu heißt "embytower" und die Gruppe logischerweise genauso. Und "emby" sollte man für ein geschmeidigeres Arbeiten in "seine" Gruppe aufnehmen!

Was meinst du mit "deine" Gruppe?
Der User emby auf dem Emby-Server hab nicht ich angelegt, sondern Emby bei der Installation. Es gibt jetzt den User emby und die Gruppe emby auf der Debian-VM.
Bei
# cat /etc/passwd | cut -d: -f1
wird mir User emby mit aufgelistet
und auch in der group mit less /etc/group ist er drinne

Zitat von McStarfighter

Klar, aber du hast doch auch deinen eigenen "Standard-Account", den du beim Setup erstellt hast. Und der hat seine eigene Gruppe, die immer die User-ID 1000 hat (und auch mehr Berechtigungen).

Und nun "hievst" du den Emby-Account mittels chmod zusätzlich in deine Gruppe vom Standard-Account! Damit hat dann Emby die gleichen Gruppenrechte wie du!

Ah OK jetzt verstanden was du meinst.
Dann gehört aber der mount in fstab immer noch root und nicht mir mit ID 1000 - da seh ich den Knackpunkt darin oder hab ich hier schon wieder einen Deckfehler.

Den Vorschlag von @mad-max find ich aber auch nicht schlecht, denn eigentlich braucht man so das Plugin Backup überhaupt nicht, sondern wenn es mir gelingt ein Script anzulegen, worin auf remote ein Tages/Zeitverzeichnis angelegt wird, darin dann per rsync /var/lib/emby rüber geschaufelt wird, wäre das super. Dann per cron z.B. täglich laufen lassen - super alles gut.

Zitat von SLiX

Ich würde mir den zu backupenden Kram in eine zip ziehen, diese dann mit dem heutigen Datum versehen.Wenn du ma nach "linux zip date" suchst, findest du sicher einige Beispiele dazu

e: ich meine, ich hab sowas mal gebastelt, also ein emby backup Script. Auf die schnelle, finde ich das aber sicher nicht

Das ist ja mal ein geiler Vorschlag.
Aber dann nicht zip, sondern als tar-gz dann werden auh eventl. Symlinks mitgesichert.

Mach langsam - aber bitte suche weiter, dann wirst du schon finden.

Zitat von McStarfighter

Nun, du kannst doch mit deinem Standard-Account voll und ganz auf die Remote Shares zugreifen, oder?! Und deine Gruppenrechte sind doch mit deinen Userrechten gleich, oder?!

Du meinst jetzt die Filme?
Die stehen so in der fstab drinne:

//192.168.9.98/filme	/home/server-filme	cifs	username=xbmc,password=xbmc	ro	0	0

Da kann ich als User und auch Emby darauf zugreifen - aber eh nur lesend.
Eigentümer und Gruppe ist aber root.

Für das Backup-Script scheint aber zwingend der User emby zu sein, ansonsten läuft das Script nicht.

Zitat von McStarfighter

Du ermöglichst mit dieser Änderung einfach nur dass Emby das Gleiche darf wie du als Standard User, also auch auf die Shares schreiben!

Hebe aber den User emby auf das gleiche Niveau wie den user nepomuk.
Von der Sicherheit scheint es mir nicht das Optimale zu sein, denn User emby ist ja von außen erreichbar.

So ich hab es nicht geschafft, über fstab das remote-Verzeichnis schreibend für User emby zu mounten - somit funzt das Plugin Backup & Restore nicht so wie ich will.
Es macht aus meiner Sicht ja keinen Sinn ein Backup auf der gleichen Kiste zu speichern, denn wenn Die abraucht sind auch alle Backups weg.
Mount immer nur als root.

Den User emby auf das Niveau meines eigenen User-Accounts zu heben, hab ich gemacht und ja @McStarfighter du hast recht, es flutscht dann sofort, aber mir scheint es aus Sicherheitssicht zu riskant.

Dann hab ich mich eingelesen in den Vorschlag von @mad-max mit rsync bis ich geschnallt hatte, dass in meiner Minimal-Installation dieses Paket nicht installiert ist.
Gut ich hätte es jetzt installieren können, das wollte ich aber momentan auch nicht.
Also hab ich mich an den Vorschlag von @SLiX gewagt, aber nicht mit zip (ist auch nicht installiert), sondern mit tar.

Ist und war ganz schön heftig, für einen Linux-Debian Neuling, wie ich einer bin.
Und das ist dabei raus gekommen:

Verzeichnis anlegen, damit ich auf Dieses überhaupt mounten kann:
# mkdir home/emby-files

in /etc/fstab folgendes einfügen:
//Remote-IP/Verzeichnis-Pfad /home/emby-files cifs username=nepomuk,password=nepomukPW rw 0 0

anschließend Datei unter dem Verzeichnis /root eine Datei anlegen # nano backup-emby.sh Dies einfügen:

#!/bin/bash


#----------------------------------------------------------------------
# Author: Nepomuk - kodinerds.net
# Version: 0.3 
# erstellt: 2018/01/16
# geändert: 2018/01/22 Leerstelle im Archivnamen durch "_" eliminiert und anstatt -a, -z gesetzt für zusätzlich mit gzip komprimieren
# geändert: 2018/04/12 --exclude "var/lib/emby/transcoding-temp" eingefügt
#
#       PFAD noch anpassen
#----------------------------------------------------------------------


# Prüfen, ob /home/emby-files überhaupt gemountet ist, wenn ja dann Backup ausführen
if cd /home/emby-files ; then
	/bin/tar --exclude "var/lib/emby/transcoding-temp" -cvf "/home/emby-files/archive-$(date +"%Y-%m-%d_%H-%M-%S").tar.gz" -z /var/lib/emby
fi

Offensichtlich unterschlägt die Forensoftware meine Anmerkungen in dem Script - deshalb hier nur die Anmerkungen extra:
--------------------------
#----------------------------------------------------------------------
# Author: Nepomuk - kodinerds.net
# Version: 0.4
# erstellt: 2018/01/16
# geändert: 2018/01/22 Leerstelle im Archivnamen durch "_" eliminiert und anstatt -a, -z gesetzt für zusätzlich mit gzip komprimieren
# geändert: 2018/04/12 --exclude "var/lib/emby/transcoding-temp" eingefügt
#
# PFAD noch anpassen
#----------------------------------------------------------------------

# Prüfen, ob /home/emby-files überhaupt gemountet ist, wenn ja dann Backup ausführen
if cd /home/emby-files ; then
/bin/tar --exclude "var/lib/emby/transcoding-temp" -cvf "/home/emby-files/archive-$(date +"%Y-%m-%d_%H-%M-%S").tar.gz" -z /var/lib/emby
fi
-----------------

Diese Datei ausführbar machen mit:
# chmod +x backup_emby.sh

zuletzt in /etc/crontab Eintrag anlegen, wann Script immer ausgeführt werden soll:
z.B. je nach Gusto:
# einmal täglich Mitternacht
@daily root /root/backup_emby.sh
# alle 10 Minuten
*/10 * * * * root /root/backup_emby.sh
mehr Beispiele gibts hier: https://manpages.debian.org/stretch/system…ontab.5.en.html

dann noch zum Abschluß den cron-Service neu starten mit
/etc/init.d/cron restart
und es flutscht.

Änderungsvorschläge und Verbesserungen erwünscht.
So damit können auch all die Emby User, die keine Emby Premiere haben, sich selbst ein Backup basteln.

Detailierte Erklärung hier nachzulesen:
Datenbank-Backup

Ein guter Tipp ist immer, grundsätzlich ein Backup VORHER anzulegen, bevor Änderungen am Emby-Server gemacht werden. So kann absolut schmerzfrei experimentiert werden, ohne sich das Embysystem zu verbiegen bzw. das Verbogene wieder gerade biegen.

Also zuerst ab auf die Console:
# cd ~ egal von wo, geht es so ins Home-Verzeichnis von root

Startet das Backup
# ./backup_emby.sh

Der Restore-Vorgang:

Nicht den Inhalt des Backup drüber kopieren, denn sonst bleiben die neu angelegten Dateien vom Experimentieren erhalten. Also wird das komplette emby-Bewegungsdaten-Verzeichnis gelöscht mit
# rm -r /var/lib/emby

Jetzt das Backup direkt mit tar zurückholen.
Das tar-Archiv nicht auf einem Windowssystem entpacken und per upload ins Verzeichnis schaufeln, denn so sind die Rechte (chmod und chown) falsch gesetzt und Emby läuft nicht mehr, weil es keinen Zugriff mehr hat. Eigentümer wäre dann nämlich "root".
tar -xzf /home/emby-files/archive-2018-01-18_18-20-08.tar.gz -C /

zu guterletzt einen Debian-Server-Restart mit
init 6

und Alles ist wieder wie vorher.
Sollte der Browser jetzt die Poster nicht oder unvollständig anzeigen, hilft ein leeren des Browser-Cache.

So ein Backup ist nur so gut, wie die Wiederherstellung funktioniert. Deshalb immer vorher einen Worst-Case Test machen.

Nachdem ich festgestellt hatte, dass meine BackupDateien oftmals massiv aufgeblasen sind, hab ich mich auf die Suche gemacht.
Emby transcodiert z.B. eine BD beim Streamen übers WAN und legt hierzu eine temporäre Datei im Verzeichnis "var/lib/emby/transcoding-temp" an. Diese Dateien sind nicht relevant bei einem Restore und dieses Verzeichnis legt Emby bei Bedarf selbst wieder an.
Also raus damit aus dem Backup.
--exclude "var/lib/emby/transcoding-temp"

@DerRuhige du hast Recht - hier liegt ein Fehler meinerseits vor.
Der hat sich am 12.04. eingeschlichen, als ich das "--exclude ..." eingefügt hatte. Also natürlich muss da ein Leerzeichen rein.

Habs jetzt oben korrigiert. Danke für den Hinweis.

Zitat von DerRuhige

Nachdem der Server fertig war, kopierte ich /var/lib/emby zurück und siehe da Voila... alles läuft wieder wie gehabt...
Filme da, Bilder da, Pfade da usw. Klasse !!!

So etwas freut mich doch zu lesen. Danke für die Blumen.

Ich denke/hoffe du hast die Daten nicht stumpf zurückkopiert, so wie du geschrieben hast, sondern den restore so gemacht hattest, wie ich in Post 13 beschrieben hatte.
Nur so werden die Datei/Eigentümer- rechte und sym-Links wieder richtig hergestellt.

Sollte dein Emby in OMV4 nicht in Docker laufen, kann dir ein anderes Tutorial von mir weiterhelfen Emby sauber aktuell zu halten:
Emby Server auf Debian installieren/updaten/deinstallieren

Zitat von DerRuhige

Du meinst, vorher /var/lib/emby löschen? Ja das habe ich gemacht...

Nicht nur. Das Archiv so entpacken:
tar -xzf /home/emby-files/archive-2018-01-18_18-20-08.tar.gz -C /

Zitat von DerRuhige

Jepp Danke Dir... Ein wirklich sauber geschriebenes HowTo. Es hilft ne menge Zeit zu sparen...

Wenn's weiterhilft freut es mich.