Hi,
Ich hab einen Raspberry Pi 3 über WLAN und LAN im lokalen Netzwerk
hängen.
Zum Backup verwende ich folgendes dd - Kommando, um das Image auf einem
Netzlaufwerk abzulegen.
1
sudo dd if=/dev/mmcblk0 of=/home/"Gemountetes NETZLAUFWERK im Homeverzeichnis"/.Name.20200102.img bs=1M status=progress
Das Funktioniert alles Prima, und im Regelfall auch über WLAN.
Wenn ich jetzt aber zufällig noch LAN amgesteckt habe (z.B. auf dem
Labortisch bei ner Weiterentwicklung), würde ich den Kopiervorgang gerne
übers LAN zwingen, da hier mindestens 16GB übers Netzwerk geklingelt
werden müssen.
Hat jemand eine Idee, wie ich den Befehl ans LAN binden kann, ohne die
Netzwerkkonfiguration zu ändern (z.b. die WLAN - Karte zu deaktivieren)?
P.S.: Macht das überhaupt einen Unterschied, ob ich WLAN oder LAN
verwende? Stichwort Anbindung der Schnittstellen intern an das RPI SOC.
Grüße,
Andreas
Stichworte: Loadbalancing, Traffic Shaping. Leider schreibst du auch nix
zum verwendeten Protokoll, so dass man nicht sagen kann, ob die
betreffende Software nicht von sich aus Möglichkeiten bietet.
Allerdings: ein dd des laufenden Systems aus demselben heraus führt mit
einiger Wahrscheinlichkeit zu inkonsistenten Images und damit unter
Umständen zu kaputten Daten. Von der vielen unnötig verbratenen Zeit gar
nicht zu reden.
Bessere Optionen: wenn es unbedingt ein Image sein muss, System
runterfahren, Karte in einen USB3-Kartenleser stecken und in erheblich
kürzerer Zeit immerhin ein sauberes Image haben. Wenn es um Backupzwecke
geht, und das System dazu nicht runtergefahren werden kann, mal gucken,
ob die einschlägigen Lösungen (inkrementelles Backup via rsync oder
darauf aufgebauten Lösungen) nicht die bessere Option wäre: erheblich
weniger Traffic und konsistente Daten im Backup.
Andreas G. schrieb:> Hat jemand eine Idee, wie ich den Befehl ans LAN binden kann, ohne die> Netzwerkkonfiguration zu ändern
Das ist genau der Grund, warum man einem Rechner keine zwei IP-Adressen
aus dem gleichen Netz über zwei Schnittstellen gibt wenn es nicht nötig
ist.
Es kann funktionieren, muß aber nicht und macht immer genau das, was man
nicht will.
Andreas G. schrieb:> P.S.: Macht das überhaupt einen Unterschied, ob ich WLAN oder LAN> verwende? Stichwort Anbindung der Schnittstellen intern an das RPI SOC.
Bis zum PI4 hingen die alle am gleichen USB.
Das ifmetric-Paket ermöglicht es uns, die Metrik von Routen sogar für DHCP zu manipulieren.
3
Mit folgendem Vorgehen setzen Sie die eth0-Schnittstelle als bevorzugt gegenüber der wlan0-Schnittstelle:
4
Installieren Sie das Paket ifmetric.
5
Fügen Sie eine Zeile mit "metric 0" direkt unterhalb von "iface eth0 inet dhcp" in "/etc/network/interfaces" ein.
6
7
Fügen Sie eine Zeile mit "metric 1" direkt unterhalb von "iface wlan0 inet dhcp" in "/etc/network/interfaces" ein.
8
9
Das "metric 0" steht für die Route mit der höchsten Priorität und ist der Standardwert. Der größere metric-Wert steht für Routen mit niedrigeren Prioritäten. Die IP-Adresse der aktivierten Schnittstelle mit dem niedrigsten metric-Wert wird die bevorzugte Adresse. Details finden Sie unter ifmetric(8).
Marc D. schrieb:> Früher™ haben hatte das "Draht" Netz einfach eine bessere "metric"> und wurde bevorzugt.>> https://www.debian.org/doc/manuals/debian-reference/
Ja, früher war alles viel, nicht unbedingt besser, aber einfacher. Da
gab es auch keine fragwürdigen "Anleitungen" im Internet. Z.B. das
Gerücht, dass man dd zum Backup benutzen kann.
rsync ist genau dafür gemacht und speziell hier mindestens 1000mal
schneller.
Nebenbei: gehört die Null hinter das input device? Das wäre doch nur
eine Partition? So ein Image wäre doch doppelt unbrauchbar, ohne
Partitionstabelle und kaputt weil gemountet? Man macht von SD-Karten
gerne ein Image, auch durchaus mit dd, aber doch von der gesamten Karte.
Und nur einmal, kurz nach der Installation.
Oder wie kommt sudo auf RPi? Da ist doch bestimmt Raspbian installiert?
Hallo zusammen,
Danke für die vielen Antworten. Dass ich beide Interfaces habe, ist der
Ausnahmefall. i.d.R. hab ich lediglich WLAN aktiv.
Warum verwende ich dd? Ich brauche eine Möglichkeit, im laufendem
Betrieb ein Backup der gesamten Installation auf eine Netzwerkfreigabe
zu sichern, um im Bedarfsfall die SD - Karte (i.d.R. wegen Defekt)
ersetzten zu können.
Wie Bauform richtigerweise schrieb:
Bauform B. schrieb:> Ja, früher war alles viel, nicht unbedingt besser, aber einfacher. Da> gab es auch keine fragwürdigen "Anleitungen" im Internet. Z.B. das
Gabs da so ne "Anleitung"
(http://www.linux-ratgeber.de/backup-des-raspberry-pi-im-laufenden-betrieb/).
Diese hat mit dd genau das gemacht, eine IMAGE - Datei erzeugt, die ich
erfolgreich wiederherstellen konnte. Damit heiligt für mich der Zweck
die Mittel.
Warum 16gb? Naja die Raspberry installation hat eben genau diese Größe.
Wenn ich eine 1:1 Kopie mache, wird dieses eben genau so groß.
Am liebsten hätte ich folgendes:
Wöchentlich ein Backup des kompletten RPI - Filesystems als Image -
Datei auf eine Netzwerkfreigabe, das ich im Bedarfsfall auf eine neue SD
- Karte mit Etcher (von Windows) flashen kann. Direkt, ohne es zu
konvertieren, oder Tools nochmal umzuschreiben, oder mit Linux nochmal
zu überarbeiten, im gerestorten Backup nochmal nacharbeiten zu müssen.
Wenn Rsync das kann, dann wärs schön wenn mir einer ein Beispiel nennen
könnte.
Jack V. schrieb:> Bessere Optionen: wenn es unbedingt ein Image sein muss, System> runterfahren, Karte in einen USB3-Kartenleser stecken und in erheblich> kürzerer Zeit immerhin ein sauberes Image haben. Wenn es um Backupzwecke> geht, und das System dazu nicht runtergefahren werden kann, mal gucken,> ob die einschlägigen Lösungen (inkrementelles Backup via rsync oder> darauf aufgebauten Lösungen) nicht die bessere Option wäre: erheblich> weniger Traffic und konsistente Daten im Backup.
Keine Option. Die Karten einzusammeln einzeln zu Sicheren und wieder zu
verteilen ist zuviel Aufwand.
Paul schrieb:> Andreas G. schrieb:>> P.S.: Macht das überhaupt einen Unterschied, ob ich WLAN oder LAN>> verwende? Stichwort Anbindung der Schnittstellen intern an das RPI SOC.>> Bis zum PI4 hingen die alle am gleichen USB.
Ich hab mir das mal noch rausgesucht. LAN ist im vergleich zum WLAN
Faktor 3 schneller, aber in Summe auf die 400Mbit des USB Links
beschränkt.
Grüße
Andreas
Andreas G. schrieb:> Diese hat mit dd genau das gemacht, eine IMAGE - Datei erzeugt, die ich> erfolgreich wiederherstellen konnte. Damit heiligt für mich der Zweck> die Mittel.
Wenn ich einen Vergleich anbringen dürfte: du bist einmal erfolgreich
bei roter Ampel über eine Straße gelaufen und gehst nun davon aus, dass
es der Regelfall wäre, dass dabei nichts kaputtgeht.
Bessere Option: einmal ein Image des Systems mit z.B. ›dd‹ anlegen,
allerdings nicht aus dem laufenden System heraus, sondern mittels
Kartenleser. Dieses auf eine andere Karte schreiben und testen.
Anschließend nur noch die geänderten Daten mit den dafür vorgesehenen
Mitteln sichern (also insbesondere keine laufenden Datenbanken auf
Dateiebene kopieren, sondern zunächst einen Dump erstellen und den
wegsichern). Dann gerne auch übers Netz – das lässt sich dann auch prima
scripten.
Vorteile: konsistente Daten, schnelle, robuste Sicherung, erheblich
weniger Traffic und Platzbedarf, einfaches Testen, schnelle
Rücksicherung, etc..
> Keine Option. Die Karten einzusammeln einzeln zu Sicheren und wieder zu> verteilen ist zuviel Aufwand.
… immer noch weniger, als wegen kaputter Sicherung alles neu aufsetzen
zu müssen, oder?
Andreas G. schrieb:> Am liebsten hätte ich folgendes:> Wöchentlich ein Backup des kompletten RPI - Filesystems als Image -> Datei auf eine Netzwerkfreigabe, das ich im Bedarfsfall auf eine neue SD> - Karte mit Etcher (von Windows) flashen kann. Direkt, ohne es zu> konvertieren, oder Tools nochmal umzuschreiben, oder mit Linux nochmal> zu überarbeiten, im gerestorten Backup nochmal nacharbeiten zu müssen.> Wenn Rsync das kann, dann wärs schön wenn mir einer ein Beispiel nennen> könnte.
Auch das Erstellen eines direkt rückschreibbaren Images wäre mit dem
o.g. Ansatz möglich: man mountet das eingangs erstellte Image (besser:
eine Kopie davon) auf der Zielmaschine und gibt das Verzeichnis als Ziel
für rsync an. Allerdings schreibst du nun auf einmal noch was von
Windows und Dritt-Tools – ob und wie’s damit machbar ist, weiß ich
nicht. Unter Linux wär’s halt recht einfach, siehe oben.
Thread beobachten
Seitenaufteilung abschalten