TimeMachine-Backups im Netz und Ruhezustand (was: Re: Datensicherheit im Heimnetz - TimeCapsule oder was?)

[Thomas Kaiser]

Ich geb auch zu, bei meinem Notebook schau ich nicht bei jedem
Zuklappen drauf, ob Time Machine gerade sichert oder nicht, mir
scheint es jedenfalls nicht, dass Fehler deswegen häufiger auftreten.
IMHO ist es ja schon darauf designed dass es das abkann.

Das kann es prinzipiell auch. Wenn Du mittendrin den Rechner schlafen
schickst, dann versucht er nach dem Aufwachen per AFP einen sog.
Reconnect durchzuführen. Dummerweise unterstützen manche AFP-Server
(Netatalk z.B.) nach wie vor nur "Secondary Reconnects" und keinen
"Primary Reconnect" (der Unterschied ist der, daß der "Primary
Reconnect" wirklich den Zustand 1:1 wie vorher wiederherstellt, d.h.
inkl. aller geöffneten Dateien und Locks, etc. -- für Details siehe [1])

Heißt: Time Machine übers Netzwerk auf AFP-Server, die keinen Primary
Reconnect unterstützen: Der Ruhezustand kann zum Problem werden (da ja
bei einem solchen TM-Backup per AFP ein SparseBundle im Zugriff ist und
typischerweise parallel viele "Bänder" des SparseBundles geöffnet sind).

Und selbst bei AFP-Servern, die einen Primary Reconnect unterstützen,
kann man $irgendwann in ein Timeout-Problem laufen. Die Session-Infos
(geöffnete Dateien, Locks, etc.) werden nur eine gewisse Zeit in dem
Zustand gehalten (ist typischerweise konfigurierbar, bei Apple in der
/Library/Preferences/com.apple.AppleFileServer.plist:

recon1SrvrKeyTTLHrs = 168;
recon1TokenTTLMins = 10080;
reconnectFlag = "no_admin_kills";
reconnectTTLInMin = 1440;

(heißt: Nach 1440 Minuten bzw. 24 Stunden ist per default erstmal Schluß
und noch offene Dateien werden geschlossen und Locks verfallen)

In anderen Worten: Vor dem Schlafengehen des Rechners ein ggf. gerade
laufendes Backup im Zweifel abbrechen und kurz warten (das SparseBundle
muß schließlich auch noch ausgeworfen werden)

Gruss,

Thomas

[1] http://support.grouplogic.com/?p=1568

[Ralph Böhme]

Post by Thomas Kaiser

Ich geb auch zu, bei meinem Notebook schau ich nicht bei jedem
Zuklappen drauf, ob Time Machine gerade sichert oder nicht, mir
scheint es jedenfalls nicht, dass Fehler deswegen häufiger auftreten.
IMHO ist es ja schon darauf designed dass es das abkann.

Das kann es prinzipiell auch. Wenn Du mittendrin den Rechner schlafen
schickst, dann versucht er nach dem Aufwachen per AFP einen sog.
Reconnect durchzuführen. Dummerweise unterstützen manche AFP-Server
(Netatalk z.B.) nach wie vor nur "Secondary Reconnects" und keinen
"Primary Reconnect" (der Unterschied ist der, daß der "Primary
Reconnect" wirklich den Zustand 1:1 wie vorher wiederherstellt, d.h.
inkl. aller geöffneten Dateien und Locks, etc. -- für Details siehe [1])

Nope. Das ist ja der Witz am Netatalk 2.2 Update: "Primary Reconnect"
ist damit implementiert.

Gruß
-r

[Thomas Kaiser]

Post by Ralph Böhme

Post by Thomas Kaiser

Ich geb auch zu, bei meinem Notebook schau ich nicht bei jedem
Zuklappen drauf, ob Time Machine gerade sichert oder nicht, mir
scheint es jedenfalls nicht, dass Fehler deswegen häufiger
auftreten. IMHO ist es ja schon darauf designed dass es das abkann.

Das kann es prinzipiell auch. Wenn Du mittendrin den Rechner schlafen
schickst, dann versucht er nach dem Aufwachen per AFP einen sog.
Reconnect durchzuführen. Dummerweise unterstützen manche AFP-Server
(Netatalk z.B.) nach wie vor nur "Secondary Reconnects" und keinen
"Primary Reconnect" (der Unterschied ist der, daß der "Primary
Reconnect" wirklich den Zustand 1:1 wie vorher wiederherstellt, d.h.
inkl. aller geöffneten Dateien und Locks, etc. -- für Details siehe [1])

Nope. Das ist ja der Witz am Netatalk 2.2 Update: "Primary Reconnect"
ist damit implementiert.

Ui, Danke für die Korrektur. Wer lesen kann, ist klar im Vorteil. In den
Release Notes stand's ja sogar dick und fett:

"Robust network disconnect/reconnect, especially important for Time
Machine"

Kennst Du 'ne simple Möglichkeit, AFP-Server diesbzgl. zu befragen?
Reicht es, asip-status.pl bzgl. "SupportsReconnect" zu befragen?

Dank' und Gruss,

Thomas

[Ralph Böhme]

Post by Thomas Kaiser

Post by Ralph Böhme

Post by Thomas Kaiser

Ich geb auch zu, bei meinem Notebook schau ich nicht bei jedem
Zuklappen drauf, ob Time Machine gerade sichert oder nicht, mir
scheint es jedenfalls nicht, dass Fehler deswegen häufiger
auftreten. IMHO ist es ja schon darauf designed dass es das abkann.

Das kann es prinzipiell auch. Wenn Du mittendrin den Rechner schlafen
schickst, dann versucht er nach dem Aufwachen per AFP einen sog.
Reconnect durchzuführen. Dummerweise unterstützen manche AFP-Server
(Netatalk z.B.) nach wie vor nur "Secondary Reconnects" und keinen
"Primary Reconnect" (der Unterschied ist der, daß der "Primary
Reconnect" wirklich den Zustand 1:1 wie vorher wiederherstellt, d.h.
inkl. aller geöffneten Dateien und Locks, etc. -- für Details siehe [1])

Nope. Das ist ja der Witz am Netatalk 2.2 Update: "Primary Reconnect"
ist damit implementiert.

Ui, Danke für die Korrektur. Wer lesen kann, ist klar im Vorteil. In den
"Robust network disconnect/reconnect, especially important for Time
Machine"
Kennst Du 'ne simple Möglichkeit, AFP-Server diesbzgl. zu befragen?

Wireshark. ;)
Wer "Primary Reconnect" können will, muss "AFP Reply Cache" können.
Vorhandensein von letzterem ist also ein starkes _Indiz_ für ersteres.

If the server supports the replay cache, then in the DSIOpenSession
reply packet from the server, there is a new option type of
kServerReplayCacheSize.

Post by Thomas Kaiser
Reicht es, asip-status.pl bzgl. "SupportsReconnect" zu befragen?

Nein, das ist ne andere Baustelle die nur darüber entscheidet wie der
Client einen "Primary Reconnect" versucht:
<http://developer.apple.com/library/mac/#documentation/Networking/Conceptual/AFP/Concepts/Concepts.html#//apple_ref/doc/uid/TP40000854-CH3-CHBEBIAA>

IaW: auch AFP Server die weder "SupportsReconnect" Flag setzen, also
"Reconnect UAM" unterstützen, unterstützen ggfls. reconnects und darüber
hinaus ggfls. "Primary Reconnects".

"Primary Reconnect" Unterstützung ist notwendige Basis um das Feature
"AFP Replay Cache" [1] zu implementieren, und das ist mandatory für
AFP 3.3 [2]. Und das ist mandatory für TM in 10.7. Daher der Spaß... ;)

Gruß
-r

[1]
<http://developer.apple.com/library/mac/#documentation/Networking/Conceptual/AFP/AFPReplayCache/AFPReplayCache.html#//apple_ref/doc/uid/TP40000854-CH227-SW1>

[2]
<http://developer.apple.com/library/mac/#documentation/Networking/Conceptual/AFP/AFPVersionDifferences/AFPVersionDifferences.html#//apple_ref/doc/uid/TP40000854-CH230-SW1>

[Patrick Kormann]

Post by Thomas Kaiser
In anderen Worten: Vor dem Schlafengehen des Rechners ein ggf. gerade
laufendes Backup im Zweifel abbrechen und kurz warten (das SparseBundle
muß schließlich auch noch ausgeworfen werden)

Das 'kurz' warten kann manchmal durchaus dauern... Ja, wäre wohl 'good
airmanship' ;). Ich könnte mir das vielleicht noch beibringen, aber
meiner Frau hämmert man sowas nicht ein, der kann ich nicht mal
beibringen das Notebook nicht bei laufender Festplatte auf 50 cm höhe
auf's Sofa knallen zu lassen.

Wie funktioniert das mit den Reconnects denn, wenn in der zwischenzeit
ein anderes WLAN genommen wird? und wenn man wieder nach Hause käme und
dort ne andere IP kriegen würde (bei mir nicht der Fall, aber...)

[Hannes Gnad]

Patrick Kormann <***@hotmail.com> wrote:

Hallo.

Post by Patrick Kormann
Das 'kurz' warten kann manchmal durchaus dauern... Ja, wäre wohl 'good
airmanship' ;). Ich könnte mir das vielleicht noch beibringen, aber
meiner Frau hämmert man sowas nicht ein, der kann ich nicht mal
beibringen das Notebook nicht bei laufender Festplatte auf 50 cm höhe
auf's Sofa knallen zu lassen.

Dafür gibt es SSDs... =;*)

[Patrick Kormann]

Post by Hannes Gnad
Hallo.

Post by Patrick Kormann
Das 'kurz' warten kann manchmal durchaus dauern... Ja, wäre wohl 'good
airmanship' ;). Ich könnte mir das vielleicht noch beibringen, aber
meiner Frau hämmert man sowas nicht ein, der kann ich nicht mal
beibringen das Notebook nicht bei laufender Festplatte auf 50 cm höhe
auf's Sofa knallen zu lassen.

Dafür gibt es SSDs... =;*)

Hab ich meiner Frau gekauft. Dann wurden uns die Notebooks geklaut und
weil sie damals sowieso fand die SSD sei ihr zu klein hab ich mir das
Geld für eine neue dann gespart. ;)

[Patrick Kormann]

Gar nicht. In dem Fall ist das Volume futsch und evtl. die Konsistenz
des SparseBundles gleich mit.

Huh, dasselbe passiert also auch, wenn man Macbook Pro mal wieder meint,
es müsse sich mit dem hier noch laufenden FON-Hotspot verbinden, statt
mit meinem Heimnetz?

In der Praxis hab ich aber schon davon gehört, daß es genau dann klemmt,
wenn sich die IP-Adresse des Clients geändert hat. Weiß aber keine
Details mehr, weil war alles Hörensagen und die Admins vor Ort wahre
Kommunikations-"Spezialisten"...

OK, das war auch nur so eine Idee. Ich hab hier eh ne fixe Zuordnung und
so handhaben das ja auch die allermeisten DHCP Server sowieso.

[Thomas Kaiser]

Post by Patrick Kormann

Gar nicht. In dem Fall ist das Volume futsch und evtl. die Konsistenz
des SparseBundles gleich mit.

Huh, dasselbe passiert also auch, wenn man Macbook Pro mal wieder meint,
es müsse sich mit dem hier noch laufenden FON-Hotspot verbinden, statt
mit meinem Heimnetz?

Das kommt drauf an. Wenn das Dein FON-Hotspot ist, aus dem heraus Du
eine Verbindung (darf dann auch ruhig geNATet sein) zum fraglichen AFP-
Server aufbauen kannst, dann könnte es klappen (außer eine wechselnde
IP-Adresse des Clients verhindert einen "primary reconnect" -- evtl.
kann Ralph hier ja noch in kurzen Worten was Erhellendes beitragen. Ich
bin heute zu faul, Developer-Kram bei Apple zu lesen bzw. muß ich mich
auf das Niveau des heute anstehenden Arbeitstags beim Kunden einstellen)

Wenn das FON-WLAN keine Verbindung zu Deinem Heimnetz bereitstellt, dann
ist natürlich in jedem Fall Endstation bzgl. Reconnect.

Post by Patrick Kormann

In der Praxis hab ich aber schon davon gehört, daß es genau dann
klemmt, wenn sich die IP-Adresse des Clients geändert hat. Weiß aber
keine Details mehr, weil war alles Hörensagen und die Admins vor Ort
wahre Kommunikations-"Spezialisten"...

OK, das war auch nur so eine Idee. Ich hab hier eh ne fixe Zuordnung
und so handhaben das ja auch die allermeisten DHCP Server sowieso.

Klar, das ist ja mit ein Design-Ziel von DHCP, das eigentlich immer nur
initial zufällige IP-Adressen für anfragende Clients ausgewürfelt
werden, die ab dann aber pseudo-fix sind (ein DHCP-Client fragt ja auch
erstmal brav nach der letzten ihm vergebenen Adresse an. Nur wenn der
Admin des DHCP-Servers nix rafft -- zu wenige freie Adressen im Pool
und/oder zu kurze Leases eingestellt -- wird's auch im Dauerbetrieb
zufällig bzgl. Adreßvergabe).

Gruss,

Thomas

[Ralph Böhme]

Post by Thomas Kaiser

Post by Patrick Kormann

Gar nicht. In dem Fall ist das Volume futsch und evtl. die Konsistenz
des SparseBundles gleich mit.

Huh, dasselbe passiert also auch, wenn man Macbook Pro mal wieder meint,
es müsse sich mit dem hier noch laufenden FON-Hotspot verbinden, statt
mit meinem Heimnetz?

Das kommt drauf an. Wenn das Dein FON-Hotspot ist, aus dem heraus Du
eine Verbindung (darf dann auch ruhig geNATet sein) zum fraglichen AFP-
Server aufbauen kannst, dann könnte es klappen (außer eine wechselnde
IP-Adresse des Clients verhindert einen "primary reconnect" -- evtl.
kann Ralph hier ja noch in kurzen Worten was Erhellendes beitragen. Ich
bin heute zu faul, Developer-Kram bei Apple zu lesen bzw. muß ich mich
auf das Niveau des heute anstehenden Arbeitstags beim Kunden einstellen)

Wird der reconnect über die "Reconnect UAM" gemacht (AppleFileServer) und
nicht über DHCAST128 oder DHX2, spielt eine vom Client gewählte ID eine
Rolle. Ob diese ID von der IP Adresse abhängt ist nicht bekannt.
Fazit: mit Netatalk Wurscht, mit AppleFileServer evtl. nicht.

Gruß
-r

[Patrick Kormann]

Post by Thomas Kaiser
Das kommt drauf an. Wenn das Dein FON-Hotspot ist, aus dem heraus Du
eine Verbindung (darf dann auch ruhig geNATet sein) zum fraglichen AFP-
Server aufbauen kannst, dann könnte es klappen (außer eine wechselnde
IP-Adresse des Clients verhindert einen "primary reconnect" -- evtl.
kann Ralph hier ja noch in kurzen Worten was Erhellendes beitragen. Ich
bin heute zu faul, Developer-Kram bei Apple zu lesen bzw. muß ich mich
auf das Niveau des heute anstehenden Arbeitstags beim Kunden einstellen)

Naja, bei (unverschlüsselten) öffentlichen Teil landen meine Devices ab
und an, obwohl es in der Liste wenn überhaupt ganz weit unten ist. An
dem Netz musst du dich mit User/PW anmelden, ausserdem ist es gegen das
private Netz abgeschottet, also nix mit Server.
Irgendwie steckt da eh noch ein Bug in Lion. Gerade wieder bin ich mit
dem 2.4 GHz Netz der Airport verbudnen, obwohl ich das 5 GHz Netz (das
einen anderen Namen hat) als oberste Priorität habe. An der
Verbindugnsqualität liegt's nicht und ich sichtz auch nur ca 3m mit
direkter Sichtverbindung von der Station. Ab und an sieht der Mac
einfach nur gewisse Netze und schnappt sich dann eben das Falsche.

Post by Thomas Kaiser
Wenn das FON-WLAN keine Verbindung zu Deinem Heimnetz bereitstellt, dann
ist natürlich in jedem Fall Endstation bzgl. Reconnect.

Eben.

Post by Thomas Kaiser
Klar, das ist ja mit ein Design-Ziel von DHCP, das eigentlich immer nur
initial zufällige IP-Adressen für anfragende Clients ausgewürfelt
werden, die ab dann aber pseudo-fix sind (ein DHCP-Client fragt ja auch
erstmal brav nach der letzten ihm vergebenen Adresse an. Nur wenn der
Admin des DHCP-Servers nix rafft -- zu wenige freie Adressen im Pool
und/oder zu kurze Leases eingestellt -- wird's auch im Dauerbetrieb
zufällig bzgl. Adreßvergabe).

Naja, ich habe da schon allerlei erlebt...