TimeMachine Backup im Netzwerk mit 1 Gbit/s?

[lisanet]

Allerdings nervt es mich, wenn ständig Timemachine läuft, da ich den Rechner häufiger auf- und zuklappe und so ein Backup fast nie durchgelaufen ist - mein Vertrauen, dass das alles immer so sauber durchläuft hält sich auch in Grenzen (ohne begründeten Beweis - halt nur Bauchgefühl)

da trügt dich dann dein Bauchgefühl. Das ist auch in technischen Dingen meistens fehl am Platz. Know-How ist da eindeutig sinnvoller.

Außerdem ist es doch auch so, dass Timemachine sowieso auch ohne SSD stündlich läuft - zumindest für 24h (oder so wenn ich richtig informiert bin) - dann zwar "nur" lokal, aber am nächsten Tag hängt ja wieder die SSD dran und alles wird in wenigen Sekunden/Minuten abgeglichen

Und daran erkennst du ja, dass es keinerlei Probleme macht, wenn TimeMachine läuft und man das Notebook zu klappt.

Ach ja, noch was:

Und wichtig: ich verwende mein MBP nur privat aus Spaß an der Freud - da gibt es nur private Daten und bei denen reicht es, wenn ich einmal am Tag eine Sicherung mache.

Ich habe die Erfahrung machen müssen, dass gerade private Daten diejenigen sind, die am einem am emotional wichtigsten sind. Der physische Wert ist gering, aber der Schmerz des Verlustes ist hart. Das Foto das gerade rein gekommen ist, deiner Liebsten / Kinder / Eltern und das noch nicht ins Backup gewandert ist...

Und wenn du es tatsächlich durchhälst jahrelang und immer jeden Tag ein Backup zu machen... toll. Ich dachte das auch mal. 2003 als ich noch Linux hatte und eh alles manuell machen musste... tja, da war das Backup halt doch 3 Monate alt. Da war ein 3 wöchiger Urlaub dazwischen und danach habe ich einfach nicht wieder angefangen konsequent was zu tun.

Ganz allgemein frage ich mich aber bei deinem Vorgehen: warum habe ich einen Computer dem ich Arbeiten geben kann und tue es nicht, sondern bürde mir das selber auf? Das versteh ich nicht. Irgendeinen Vorteil muss man sich doch versprechen, wenn man etwas selbst tut, als dass man es automatisert tun lässt und sich entlastet?

Sollte es wie du schreibst, mangelndes Vertrauen in deinen Rechner und dessen Software sein, dann hilft zum einen nur Know-How und zum anderen die Frage, warum du ausgerechnet einer Backup-Lösung misstraust aber anderen Routinen auf dem Rechner nicht.

 

[Boogaboo]

Worauf machst Du Dein Netzwerk-TM-Backup?

 

[jteschner]

Ich habe die Erfahrung machen müssen, dass gerade private Daten diejenigen sind, die am einem am emotional wichtigsten sind. Der physische Wert ist gering, aber der Schmerz des Verlustes ist hart. Das Foto das gerade rein gekommen ist, deiner Liebsten / Kinder / Eltern und das noch nicht ins Backup gewandert ist...

Und wenn du es tatsächlich durchhälst jahrelang und immer jeden Tag ein Backup zu machen... toll. Ich dachte das auch mal. 2003 als ich noch Linux hatte und eh alles manuell machen musste... tja, da war das Backup halt doch 3 Monate alt. Da war ein 3 wöchiger Urlaub dazwischen und danach habe ich einfach nicht wieder angefangen konsequent was zu tun.

Ganz allgemein frage ich mich aber bei deinem Vorgehen: warum habe ich einen Computer dem ich Arbeiten geben kann und tue es nicht, sondern bürde mir das selber auf? Das versteh ich nicht. Irgendeinen Vorteil muss man sich doch versprechen, wenn man etwas selbst tut, als dass man es automatisert tun lässt und sich entlastet?

Sollte es wie du schreibst, mangelndes Vertrauen in deinen Rechner und dessen Software sein, dann hilft zum einen nur Know-How und zum anderen die Frage, warum du ausgerechnet einer Backup-Lösung misstraust aber anderen Routinen auf dem Rechner nicht.

Tja, ich mache das halt so - und mal ehrlich: was gibt es da zu vergessen? Morgens geht automatisch die T7 mit einem Handgriff an das MBP.
Wenn ich neue Fotos habe: einmal direkt den Sync-Knopf in Forklift gedrückt (ist sowieso mein Basistool) und schon ist es noch eher auf dem NAS als auf der T7 über Timemachine. Dasselbe mit Dokumenten jeglicher Art.

Ich verstehe ja, dass man alles automatisieren kann - aber manchmal ist es ja vielleicht auch gut, sich auf seine Hände verlassen zu müssen/können.
Zumindest weiß ich sofort, dass meine Fotos gesichert sind wenn ich den Knopf gedrückt habe.

Ich versuche ja auch schon vieles zu automatisieren - manches klappt allerdings noch nicht so - hauptsächlich weil ich noch recht eingeschränktes Wissen habe - zB habe ich es immer noch nicht geschafft aus einem fsarchiver Backup meiner Raspi-OMV Installation eine bootbare SD-Karte zu erzeugen. Manuell: in 8mins gemacht. Oder ich blicke es ums verrecken noch nicht warum ein rsync von meinem Homebridge-Raspi auf den OMV-Raspi nicht läuft, wenn ich nicht über ACLs mir selbst rw-Rechte auf die Freigabe gebe - es geht einfach nicht wenn ich nur Standard-Rechte vergebe - selbst bei 777 nicht.
Und ich traue mich schon gar nicht mehr dich zu fragen

 

[FelixMacintosh]

Eine Apple TimeCapsule braucht im Betrieb > als 30 Watt.
Eine AirPort Extreme ca. 23 Watt ohne USB Platte dran.
Beim Nas ist das natürlich abhängig von der Anzahl der Festplatten. Aber weniger wirds nicht sein.
Eine externe SSD via USB-x braucht nur dann Strom wenn sie auch genutzt wird.

 

[jteschner]

Eine Apple TimeCapsule braucht im Betrieb > als 30 Watt.
Eine AirPort Extreme ca. 23 Watt ohne USB Platte dran.
Beim Nas ist das natürlich abhängig von der Anzahl der Festplatten. Aber weniger wirds nicht sein.
Eine externe SSD via USB-x braucht nur dann Strom wenn sie auch genutzt wird.

Mein Raspi-NAS <5W + 2x SSD am USB-Hub = ca. insgesamt 10W?
Die Synology (gemessen) mit 2 Seagate 4TB in der Spitze 23W wenn beide Disks laufen (die habe ich aber nur 1h am Tag an wenn das Backup läuft)

Ansonsten ist es natürlich richtig was du sagst mit der externen SSD

 

[lisanet]

zB habe ich es immer noch nicht geschafft aus einem fsarchiver Backup meiner Raspi-OMV Installation eine bootbare SD-Karte zu erzeugen. Manuell: in 8mins gemacht. Oder ich blicke es ums verrecken noch nicht warum ein rsync von meinem Homebridge-Raspi auf den OMV-Raspi nicht läuft, wenn ich nicht über ACLs mir selbst rw-Rechte auf die Freigabe gebe - es geht einfach nicht wenn ich nur Standard-Rechte vergebe - selbst bei 777 nicht.

fsarciver:
du brauchst dafür ein lauffähiges Linux. Anders geht es nicht. Ein Linux in einer VM auf dem Mac reicht aus.

rsync:
mach rsync nie auf eine smb-Freigabe, sondern immer entweder per ssh (das sit standard bei rsync) oder auf einem laufenden rsync-Server. Beides hat den Vrteil dass du mit den Rechten des Filesystems arbeitest und nicht mit denen des SMB-Servers.

Rechte:
du musst unterscheiden zwischen den Rechten des Filesystems und denen des SMB-Servers.

Bei smb kommt hinzu, ob du fruit_nfs_aces auf yes oder no hast. Bei yes gibt der Mac-client vor, welche Rechte gesetzt werden. Das hat den großen Vorteil, dass es exakt so ist, wie von Mac zu Mac. Die "create mask" und "force create mode" werden dabei _nicht_ beachtet.

Bei nfs_aces=no ist "create mask" nur das Maximum an Rechten, "force create mode" das Minimum _nachdem_ das Maximum eingehalten wurde.

Zusätzlich kommt hinzu: "inherit acl" und "inherit permissions" Beides zusammen macht das System extrem schwer zu durchschauen.

"inherit acl" vererbt die ACL des Verzeichnisses auf Dateien. Die effektiven Rechte ergeben sich dann für andere User als den Dateieigentümer aus denen der "create mask"/"force create mode" in Verbindung mit nfs_aces=yes/no und den ACL. ACL reduzieren dabei die Rechte, sie erweitern nicht.

"inherit mask" stellt sicher, dass mindestens die Rechte des Verzeichnisses gelten. Erst dann erfolgt das vorgenannte mit "create/force/acl/nfs_aces"

Meine Empfehlung:

Wenn du rsync via ssh machst (Standard) dann kommts du mit alledem nicht in Berührung und es gelten nur die Rechte des Filesystems für den ssh-login-User.

Wenn du rsync via rsync-Server machst, bestimmst du die erlaubten User und damit die Rechte imrsync-Server, ist also faktisch identiscf mit dem ssh login. Vorteil des rsync-Servers: du kannst das Zielverzeichnis vorgeben und beschränken.

Fazit:

rsync nur per ssh oder rsync-Server

smb nicht mit "inherit acl" "inherit permissions" sondern nur mit nfs_aces=yes, da sich dann eine Freigabe wie eine externe Platte verhält.

Wenn du viele, also wirklich sehr viele User für smb hättest (100+) oder du basteln willst, dann nimm inherit acl / permissions, sonst nicht.

Willst du mehr über smb Rechte wissen -> http://mirror.apps.cam.ac.uk/pub/doc/suse/sles9/adminguide-sles9/ch27s03.html

und https://wiki.omv-extras.org/doku.php?id=misc_docs:nas_permissions

 

[lisanet]

.

 

[jteschner]

Ich glaube, das führt an dieser Stelle alles zu weit - ich mache mal dazu ein neues Thema auf. Wir hatten das ja bereits alles schon mal an anderer Stelle ausgiebig besprochen.
Aber nur so viel:

fsarciver:
du brauchst dafür ein lauffähiges Linux. Anders geht es nicht. Ein Linux in einer VM auf dem Mac reicht aus.

Habe ich: einen weiteren Raspi zum spielen (damit ich mir die Hombridge / OMV nicht kaputt mache). Auch alles in diversen HowTos im OMV-Forum zusammengesucht - ich bekomme es nicht hin - mache mal neuen Thread die Tage auf (ist allerdings Prio Low, da ich mit offline-cloning eigentlich gut leben kann - allerdings will ich es doch hinbekommen.

rsync:
mach rsync nie auf eine smb-Freigabe, sondern immer entweder per ssh (das sit standard bei rsync) oder auf einem laufenden rsync-Server. Beides hat den Vrteil dass du mit den Rechten des Filesystems arbeitest und nicht mit denen des SMB-Servers.

Natürlich bei rsync kein SMB! Ich mache rsync Homebridge-raspi nach OMV-raspi - und dort auf jt@omv.local:/srv/mergerfs/pool/backup
"backup" ist der Freigabeordner mit allen Standard-OMV-Rechten (owner: root rwx, group users rwx, other rw)
rsync im dry-run geht.
rsync -av ...... geht dann nicht mit Fehler "mkdir: cannot create directory ... not enough permissions" obwohl "jt" in der users-gruppe ist
erst wenn ich in OMV in der Freigabe unter ACLs dem user "jt" r/w Rechte gebe, läuft der rsync
Mit "rsync per ssh", meinst du damit die option -e ssh? Die habe ich nämlich nicht versucht-

Rechte:
du musst unterscheiden zwischen den Rechten des Filesystems und denen des SMB-Servers.

Bei smb kommt hinzu, ob du fruit_nfs_aces auf yes oder no hast. Bei yes gibt der Mac-client vor, welche Rechte gesetzt werden. Das hat den großen Vorteil, dass es exakt so ist, wie von Mac zu Mac. Die "create mask" und "force create mode" werden dabei _nicht_ beachtet.

Bei nfs_aces=no ist "create mask" nur das Maximum an Rechten, "force create mode" das Minimum _nachdem_ das Maximum eingehalten wurde.

Der Mac ist ja hier raus. Das weiß ich bereits alles - na ja "wissen"

Zusätzlich kommt hinzu: "inherit acl" und "inherit permissions" Beides zusammen macht das System extrem schwer zu durchschauen.

"inherit acl" vererbt die ACL des Verzeichnisses auf Dateien. Die effektiven Rechte ergeben sich dann für andere User als den Dateieigentümer aus denen der "create mask"/"force create mode" in Verbindung mit nfs_aces=yes/no und den ACL. ACL reduzieren dabei die Rechte, sie erweitern nicht.

"inherit mask" stellt sicher, dass mindestens die Rechte des Verzeichnisses gelten. Erst dann erfolgt das vorgenannte mit "create/force/acl/nfs_aces"

Ist ja nur für smb von belang. Dort habe ich wegen macOS inherit acl und permissions gesetzt - hatten wir so besprochen wenn du dich erinnerst.

Meine Empfehlung:

smb nicht mit "inherit acl" "inherit permissions" sondern nur mit nfs_aces=yes, da sich dann eine Freigabe wie eine externe Platte verhält.

DAS hatten wir mal anders besprochen. Kann/sollte ich das (sinnvoll) noch nachträglich ändern?

Wenn du viele, also wirklich sehr viele User für smb hättest (100+) oder du basteln willst, dann nimm inherit acl / permissions, sonst nicht.

Willst du mehr über smb Rechte wissen -> http://mirror.apps.cam.ac.uk/pub/doc/suse/sles9/adminguide-sles9/ch27s03.html

und https://wiki.omv-extras.org/doku.php?id=misc_docs:nas_permissions

Das letztere habe ich gelesen.

 

[lisanet]

Natürlich bei rsync kein SMB! Ich mache rsync Homebridge-raspi nach OMV-raspi - und dort auf jt@omv.local:/srv/mergerfs/pool/backup
"backup" ist der Freigabeordner mit allen Standard-OMV-Rechten (owner: root rwx, group users rwx, other rw)
rsync im dry-run geht.
rsync -av ...... geht dann nicht mit Fehler "mkdir: cannot create directory ... not enough permissions" obwohl "jt" in der users-gruppe ist
erst wenn ich in OMV in der Freigabe unter ACLs dem user "jt" r/w Rechte gebe, läuft der rsync

mit den Angaben kann ich das nicht beantworten. Es fehlt, genaue Befehlszeile, welcher User ruft rsync auf.

Die ACL von smb sind im Filesystem hinterlegt. Dadurch werden "inherict acl" interessant, insbesondere die mask. Per default ist die dann für benannte User, das ist jt, nur auf r--. Der Owner ist ja root.

Denn: ACL schränken ein, erweitern nicht, für andere als den Eigentümer (=root) -> keine ACL -> keine Rechte (stark vereinfacht)

Daher sage ich: nicht auf eine smb-Freigabe, auch nicht "indirekt" über das Filesystem, da dann eben keine ACL (falls verwendet) zum Tragen kommen. Oder halt per rsync-Server (mit allen erforderlichen Dingen sh. omv-GUI)

Genaues aber erfordert die Kenntnis aller Beteilitgen: s.o.

Mit "rsync per ssh", meinst du damit die option -e ssh?

ich vermute, du machst das bereits per ssh, da das Standard ist. aber... genaue Befehlszeile fehlt.

 

[lisanet]

DAS hatten wir mal anders besprochen. Kann/sollte ich das (sinnvoll) noch nachträglich ändern?

Das musst du entscheiden, wie du besser zurecht kommst. Ohne "inherit" ist es einfacher aber weniger flexibel. ACL sind zudem auf dem Mac bei Freigaben extrem hilfreich. Extrem. Und da hilft es, wenn man sich eben damit beschäftigt. Warum sind sie auf dem Mac hilfreich -> https://lisanet.de/zugriffsrechte-bei-geteilten-ordnern-vererben/

Bevor du fragst: das geht so mit Linux+samba+ext4 vom Mac aus nicht.

Wie gesagt: deine Entscheidung. Wenn du aber durcheinander kommst oder es undurchsichtig wird (wie oben mit rsync) -> mach es ohne ACL

 

[jteschner]

mit den Angaben kann ich das nicht beantworten. Es fehlt, genaue Befehlszeile, welcher User ruft rsync auf.

Von homebridge-Raspi, aufrufender user: JT
rsync -av --delete /var/lib/homebridge/backups/ jt@192.168.178.100:/srv/mergerfs/pool/backup/

Wobei wegen ssh der public key von homebridge auf dem omv-Raspi (oben die IP) kopiert ist

Die ACL von smb sind im Filesystem hinterlegt. Dadurch werden "inherict acl" interessant, insbesondere die mask. Per default ist die dann für benannte User, das ist jt, nur auf r--. Der Owner ist ja root.

Denn: ACL schränken ein, erweitern nicht, für andere als den Eigentümer (=root) -> keine ACL -> keine Rechte (stark vereinfacht)

Daher sage ich: nicht auf eine smb-Freigabe, auch nicht "indirekt" über das Filesystem, da dann eben keine ACL (falls verwendet) zum Tragen kommen.

DAS habe ich nicht gewusst.. Natürlich hängt an "backup" eine smb-Freigabe, da ich vom Mac darauf zugreifen will

Oder halt per rsync-Server (mit allen erforderlichen Dingen sh. omv-GUI)

DAS habe ich noch nicht probiert. Mache ich mal morgen. Dann aber ggf. neuer Thread!

 

[jteschner]

Das musst du entscheiden, wie du besser zurecht kommst. Ohne "inherit" ist es einfacher aber weniger flexibel. ACL sind zudem auf dem Mac bei Freigaben extrem hilfreich. Extrem. Und da hilft es, wenn man sich eben damit beschäftigt. Warum sind sie auf dem Mac hilfreich -> https://lisanet.de/zugriffsrechte-bei-geteilten-ordnern-vererben/

Bevor du fragst: das geht so mit Linux+samba+ext4 vom Mac aus nicht.

Wie gesagt: deine Entscheidung. Wenn du aber durcheinander kommst oder es undurchsichtig wird (wie oben mit rsync) -> mach es ohne ACL

Heisst für mich im Umkehrschluss: am besten eigene Freigaben für den Mac inkl. ACL usw. und für andere Rechner wie mein Homebridge Raspi eben andere. Hmmm ...
Oder rsync-server - muss ich mir anschauen.

 

[lisanet]

Heisst für mich im Umkehrschluss: am besten eigene Freigaben für den Mac inkl. ACL usw. und für andere Rechner wie mein Homebridge Raspi eben andere. Hmmm ...
Oder rsync-server - muss ich mir anschauen.

Umkehrschlüsse sind selten richtig. Tu das nicht.

Mein Blog bezieht sich auf Mac client - Mac Freigabe. Er hat nichts mit smb zu tun.

Linux ext4 kann die vom Mac verwendeten ACL nicht.

Samba bildet eine Eigenschaft der Mac ACL ab, die der Mac bei smb verwendet: die Änderung der Unix-Perms -> nfs_aces=yes

Ergo: ob du ACL nutzt mit Macs oder mit Linux ist vollkommen egal. Du musst dich immer auskennen und die Wege der Rechtebildung kennen. Es gibt kein "am besten". Es kommt immer drauf an, was du tust.

Ich habe dir meinen Weg genannt, da er am ehesten bei smb dem entspricht was bei "Mac zu Mac" passiert.

Wenn du nun wiederholt sagst "...das hast aber du gesagt/geschrieben" dann habe ich einen Fehler gemacht, Hilfe anzubieten. Ich bin nicht dafür verantwortlich, dass du das Konw-How hast. Ich kann dir nur den Weg zeigen. Ob du ihn gehst musst du entscheiden. Ich bin dafür nicht verantwortlich.

Und letzmals als Tipp: unterscheide Rechte des Filesystems (unix pers, ACL) von denen die Samba (create/force/unix/acl/inherit/nfs_Aces) hat. ACL sind auf dem Mac anders als auf Windows, anders als auf Linux. Samba orientiert sich an Windows, nicht an Macs.

Mehr kann ich nicht sagen und deutlicher kriege ich es nicht hin ohne ellenlange Romane zu schreiben (und habe auch keine Lust dazu)