[gelöst] mit NFS große Dateien kopieren sehr langsam

Einrichten des lokalen Netzes, Verbindung zu anderen Computern und Diensten.
scientific
Beiträge: 3020
Registriert: 03.11.2009 13:45:23
Lizenz eigener Beiträge: Artistic Lizenz
Kontaktdaten:

Re: [gelöst] mit NFS große Dateien kopieren sehr langsam

Beitrag von scientific » 25.05.2017 11:37:42

Übrigens danke für diesen Thread. Ich liebäugle schon länger mit ein PI als Backupserver... Jetzt nicht mehr. [emoji4]

Welche Alternativen in dieser Preisklasse gäbs da?

(Asche auf mein Haupt -> neuer eigener Thread...)

Lg scientific
dann putze ich hier mal nur...

Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie

auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main

DeletedUserReAsG

Re: [gelöst] mit NFS große Dateien kopieren sehr langsam

Beitrag von DeletedUserReAsG » 25.05.2017 11:51:28

In dieser Preisklasse? Nix. Zwei oder drei Zehner mehr, und man könnte ’nen Cubitruck nehmen. Hat SATA und GBit/s-Ethernet onboard und ist diesbezüglich recht brauchbar.

TomL

Re: [gelöst] mit NFS große Dateien kopieren sehr langsam

Beitrag von TomL » 25.05.2017 14:54:08

scientific hat geschrieben:Übrigens danke für diesen Thread. Ich liebäugle schon länger mit ein PI als Backupserver... Jetzt nicht mehr.
Nur mal so aus Neugier... hast Du mal die Datenmengen ermittelt, die effektiv automatisch durch Backups im Jahresdurchschnitt täglich bewegt werden müssen? Eigentlich ist das doch die einzige Größe, die festlegt, welche Leistungsklasse ein reiner Backup-Server haben muss. Bei uns sind das von der 3 TB-Arbeitsplatte zur zweiten HD nur ein paar MB tatsächliche Änderungen, machmal etwas mehr, meistens aber nicht. Und der tägliche Sync von der Server-SSD ebenfalls zur zweiten HD ist auch kaum nennenswert. Das gesamte Backupgeschäft beschäftigt unseren PI jeden Monat (bei ca. 240 Nachtstunden ungenutzter Zeit, also außerhalb des User-Fensters) allerhöchstens 4-6 Stunden im gesamten Monat. Welche sinnvolle Verbesserung ist da mit mehr Power zu erwarten?

Die Angaben aus diesem Thread finde ich persönlich jetzt ein wenig ungeeignet zur Bewertung als privater Backupserver. Gerade auch vor dem Aspekt des Stromverbrauchs und der angekündigten Preis-Entwicklung bei einem 7/24 Betrieb aufs Jahr hochgerechnet. Anders wäre es, wenn es einen geschäftlichen Background mit vertraglich zugesagten Verfügbarkeits-Garantien und festen Reaktionszeiten hätte. Dann würde ich den PI auch nicht als allererste Wahl betrachten.

j.m.2.c.

Benutzeravatar
Lord_Carlos
Beiträge: 5578
Registriert: 30.04.2006 17:58:52
Lizenz eigener Beiträge: GNU Free Documentation License
Wohnort: Dänemark

Re: [gelöst] mit NFS große Dateien kopieren sehr langsam

Beitrag von Lord_Carlos » 25.05.2017 15:34:09

scientific hat geschrieben: Welche Alternativen in dieser Preisklasse gäbs da?
Etwas teurer, aber vielleicht ein BananaPi?
Ich meine die gibt es auch mit hardware AES Beschleunigung.

Code: Alles auswählen

╔═╗┬ ┬┌─┐┌┬┐┌─┐┌┬┐╔╦╗
╚═╗└┬┘└─┐ │ ├┤ │││ ║║
╚═╝ ┴ └─┘ ┴ └─┘┴ ┴═╩╝ rockt das Forum!

scientific
Beiträge: 3020
Registriert: 03.11.2009 13:45:23
Lizenz eigener Beiträge: Artistic Lizenz
Kontaktdaten:

Re: [gelöst] mit NFS große Dateien kopieren sehr langsam

Beitrag von scientific » 25.05.2017 18:22:15

Nun ja... Ich hörte/las schon so einiges über den Flaschenhals beim RPi...

Es sind natürlich über das Jahr gerechnet geringe Mengen. Aber bei mir kommen doch alle paar Tage viele MB an Videomaterial hinzu, da ich viel filme.
Wenn ich dann übers Netz sichere, soll der Vorgang dann nicht ewig blockieren, sondern zügig durchlaufen.
Derzeit mach ich es per USB-Platte, später dann auf den Server, wovon eine Strecke per WLAN läuft.

Und nichts ist lästiger als man will den Rechner ausschalten und das hängt, weil der Netzwermount das Filesystem blockiert...

Lg scientific
dann putze ich hier mal nur...

Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie

auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main

Benutzeravatar
Lord_Carlos
Beiträge: 5578
Registriert: 30.04.2006 17:58:52
Lizenz eigener Beiträge: GNU Free Documentation License
Wohnort: Dänemark

Re: [gelöst] mit NFS große Dateien kopieren sehr langsam

Beitrag von Lord_Carlos » 25.05.2017 18:43:11

Ich wollte ueber die naechsten Wochen auch ein rPi als offsite backup benutzten.
Ich meine gelesen zu haben das er doch so 8 - 10MB/s schaffen sollte. Wenn jetzt nichts mit verschluesselung hinzukommt. Naja, werde ich dann mal sehen.

Code: Alles auswählen

╔═╗┬ ┬┌─┐┌┬┐┌─┐┌┬┐╔╦╗
╚═╗└┬┘└─┐ │ ├┤ │││ ║║
╚═╝ ┴ └─┘ ┴ └─┘┴ ┴═╩╝ rockt das Forum!

Benutzeravatar
jph
Beiträge: 1049
Registriert: 06.12.2015 15:06:07
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: Greven/Westf.

[gelöst] mit NFS große Dateien kopieren sehr langsam

Beitrag von jph » 25.05.2017 20:23:01

TomL hat geschrieben:Das gesamte Backupgeschäft beschäftigt unseren PI jeden Monat (bei ca. 240 Nachtstunden ungenutzter Zeit, also außerhalb des User-Fensters) allerhöchstens 4-6 Stunden im gesamten Monat. Welche sinnvolle Verbesserung ist da mit mehr Power zu erwarten?
Wenn die Backup-Quelle 24x7 aktiv ist und sozusagen alle Zeit der Welt für ihr Backup zur Verfügung hat, mag deine Argumentation zutreffen. Bei einem Laptop oder einem Desktop-Rechner, der abends mal ein, zwei Stündchen läuft, sieht das schon anders aus. Da muss das Backup innerhalb dieses Zeitfensters abgeschlossen werden. Was dann zu oft nicht klappt und das Backup unsicher macht. BTDT.

TomL

Re: [gelöst] mit NFS große Dateien kopieren sehr langsam

Beitrag von TomL » 25.05.2017 20:53:00

Lord_Carlos hat geschrieben:Ich wollte ueber die naechsten Wochen auch ein rPi als offsite backup benutzten.
Ich meine gelesen zu haben das er doch so 8 - 10MB/s schaffen sollte. Wenn jetzt nichts mit verschluesselung hinzukommt. Naja, werde ich dann mal sehen.
Beim gerade durchgeführten Test mit einer 5-GB-Datei (5127 MB) vom Server (RPI) runter auf meinen Rechner ist die effektive Übertragung 11,22 MB/s. Die gleiche Datei umbenannt von meinen Rechner zurück auf den Server wird mit 10,4 MB/s übertragen. Da solche Dateien aber nur seltene ungewöhnliche Spitzen im normalen Tagesgeschäft darstellen, ist diese Zeit für mich absolut sekundär in ihrer Bedeutung. Wenn ich weiss, dass so eine Datei 7-8 Minuten oder vielleicht sogar länger dauert, dann starte ich das nicht, wenn ich gleich was anderes vorhabe, sondern lass es laufen, wenn ich TV gucke und eh nix anderes zu tun habe. Und mal ehrlich, normale Multimedia-Dateien verschlüsseln... ?... das halte ich wahrlich für unnötig. Mein PI ist ein einfacher Samba-Server.

TomL

Re: [gelöst] mit NFS große Dateien kopieren sehr langsam

Beitrag von TomL » 25.05.2017 21:21:22

jph hat geschrieben:Bei einem Laptop oder einem Desktop-Rechner, der abends mal ein, zwei Stündchen läuft, sieht das schon anders aus. Da muss das Backup innerhalb dieses Zeitfensters abgeschlossen werden. Was dann zu oft nicht klappt und das Backup unsicher macht. BTDT.
Genau das war das Problem... eines, mit dem ich bei 10-15 Clients schlichtweg überfordert war. Aus dem Grund werden die Geräte heute gar nicht mehr gesichert, sondern verwenden entweder direkt den Server oder syncen sich kontinuierlich dorthin. Ist also alles eine Frage der Organisation.

scientific
Beiträge: 3020
Registriert: 03.11.2009 13:45:23
Lizenz eigener Beiträge: Artistic Lizenz
Kontaktdaten:

Re: [gelöst] mit NFS große Dateien kopieren sehr langsam

Beitrag von scientific » 26.05.2017 12:44:59

Nun...
In meinem Setup werden mit btrfs auch nur die Teile gesynced, die sich geändert haben. Und das stündlich.

Kommt jetzt ein Film mit 2 GB daher, ist die Datenmenge 2 GB+irgendwelche Metainfos, die dann sofort gesichert werden (müssen).
Ob ich jetzt mit rsync, mit btrfs send/receive odee smb oder nfs mit dem Server die Daten austausche, bleibt wohl ziemlich einerlei, wenn der Server einen Flaschenhals wie der Raspi hat. 2GB sind 2 GB, die jetzt im Moment übers Netz an den Server geschickt und dort verarbeitet werden müssen.

Bei einem Backup mit rsync oder btrfs kann ich immer noch entscheiden, wann genau ich es schicken will (wenn es nicht automatisch gemacht wird). Bei smb oder nfs-mount von HOME passiert es in der Sekunde des Speicherns.

Oder hab ich da was falsch verstanden?
dann putze ich hier mal nur...

Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie

auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main

DeletedUserReAsG

Re: [gelöst] mit NFS große Dateien kopieren sehr langsam

Beitrag von DeletedUserReAsG » 26.05.2017 13:04:48

Bei smb oder nfs-mount von HOME passiert es in der Sekunde des Speicherns.
Dass ~ übers Netz gemountet werden sollte, ist für mich aus dem bisherigen Threadverlauf nicht ersichtlich. Das wäre zudem so ziemlich das Gegenteil eines Backups. Was habe ich übersehen?

TomL

Re: [gelöst] mit NFS große Dateien kopieren sehr langsam

Beitrag von TomL » 26.05.2017 15:03:34

Ich kapier das im Moment auch nicht. Mein Pi hat eine zweite Platte angeschlossenen, aber die ist nicht gemountet. Mein Backupscript mountet die Platte, macht ein partielles Backup der Arbeitsplatte und rsync't die SSD unselektiert, also vollständig. Dann wird die platte wieder getrennt. Das passiert morgens zwischen 5 und 6 Uhr, wenn alle noch pennen

scientific
Beiträge: 3020
Registriert: 03.11.2009 13:45:23
Lizenz eigener Beiträge: Artistic Lizenz
Kontaktdaten:

Re: [gelöst] mit NFS große Dateien kopieren sehr langsam

Beitrag von scientific » 27.05.2017 11:44:55

Also TomL, so wie ich dein Setup verstanden habe, Mounten die Rechner im Netz ihre Homes per nfs. Oder hab ich das falsch verstanden?

Wenn ich als User auf meinem Laptop mit per nfs gemounteten Home einen Film mit 2 GB downloade, in mein Download-Verzeichnis in Home, so geht das in dem Moment über das Netz auf den Server, der das Home zur Verfügung stellt.
Wenn das ein Raspi ist, dann hat der den Flaschenhals, dass Ethernet und USB für die Platte am selben USB-Port hängen. Also hab ich da offenbar massive Verzögerungen.

Wenn ich jetzt meine Daten lokal speichere und mit einem Backupskript zu bestimmten Zeiten das Backup übers Netz zum Backupserver schiebe, ist halt in dem Moment der Flaschenhals des Raspi ein Problem.

Egal wie, ein Raspi der größere Datenmengen übers Netz empfangen und auf eine angesteckte USB-Platte schieben soll, dürfte ein Kapazitätsproblem haben. So hab ich das verstanden.

Aber ich klinke mich aus dem Thread wieder aus. Meine Kommunikation verläuft offenbar ein wenig anders, als eure (TomL und niemand). Und die führt oft zu Missverständnissen.

lg scientific
dann putze ich hier mal nur...

Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie

auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main

DeletedUserReAsG

Re: [gelöst] mit NFS große Dateien kopieren sehr langsam

Beitrag von DeletedUserReAsG » 27.05.2017 13:05:00

Wenn ich jetzt meine Daten lokal speichere und mit einem Backupskript zu bestimmten Zeiten das Backup übers Netz zum Backupserver schiebe, ist halt in dem Moment der Flaschenhals des Raspi ein Problem.
Wenn die bestimmten Zeiten so gelegt werden, dass man zu diesen nicht weiter auf den Pi zugreifen muss und das Ganze zudem so gestaltet wird, dass der Prozess nicht alles andere blockiert, ist das einzige Problem, dass es halt etwas länger dauert, wenn größere Veränderungen gesichert werden müssen. Wenn man sein ~ auf den Pi legt und via NFS mountet, dauert’s u.U. häufiger mal länger, und das beim normalen Arbeiten. Das würden erheblich mehr Leute als Problem wahrnehmen, und deswegen wird’s wohl eher keiner so machen.

TomL

Re: [gelöst] mit NFS große Dateien kopieren sehr langsam

Beitrag von TomL » 27.05.2017 15:27:53

scientific hat geschrieben:Also TomL, so wie ich dein Setup verstanden habe, Mounten die Rechner im Netz ihre Homes per nfs.
Nicht NFS, sondern Samba. Und nein, auch keine servergespeicherten homedirs, sondern lokale homedirs.

Bei uns gibts nur die Ansage, dass alle user ihre persönlichen Daten in den Ordner "Daten" ihres lokalen client- homedirs speichern. Dieser lokale Ordner ist jeweils ein usereigener mountpoint in sein entsprechendes homedir-verzeichnis "Daten" des Servers, welcher wiederum nur ein 'bind' für einen zentralen Ordner ist, in dem jeder User unter seinem Namen sein eigenes Verzeichnis hat. Dieses zentrale Serververzeichnis heißt /media/SSD/Home und in einer rutsche sind täglich alle geänderten Dateien auf die HD gespiegelt. Wie gesagt, das ist nie viel.
In libreoffice auf den clients zum Beispiel ist dieser lokale Ordner ~/Daten als standard-arbeitsverzeichnis hinterlegt. Firefox und Thunderbird werden via Scripts gestartet und bei Programmende werden prefs.js und places.sqlite zum Server kopiert. Der Rest an lokalen Einstellungen ist standard und interessiert mich nicht. Wenn jemand einen Film gucken will, guckt er den einfach mit dem smplayer via samba vom Server ohne vorher zu kopieren.

Ich sichere nur was notwendig ist und wirklich nur das, dessen Wiederherstellung bei Verlust unmöglich ist oder nur mit unvertretbarem Aufwand. Alles andere schert mich nicht. Manchmal schaue ich noch mal nach, aber wirklich auf keinem client finde ich wichtige oder schützenswerte Daten in lokalen Ordnern. Die Verwendung des Ordners "Daten" im eigenen homedir ist bei uns zur absoluten Selbstverständlichkeit geworden.

Und weil ich auf all unseren Clients meinen standard-custom-desktop installiert habe, ohne Gui-Dialogs für diverse settings, mit denen die Anwender das System strubbelig machen können, kann ich diese Sicherung auch abhaken. Lokale settings interessieren mich also auch nicht weiter.

Wie gesagt, alles ein Sache von Anpassungsreaktionen, und zwar an die Anforderungen , organisatorisch an die Prozesse und letztendlich an die technisch limitierten Möglichkeiten. Man kann das alles wunderbar und tatsächlich konfliktfrei zusammen bringen.... und am Ende minimiert das meinen Arbeitsaufwand.

Antworten