Automatisiertes Trucrypt Backup auf LAN Server

[le0m]

Hallo zusammen,

ich suche nach einer automatisierten Lösung, um Dateien von meinem Laptop (Win 7 Pro) auf meinem LAN Server (auch Win 7 Pro) zu sichern. Das Problem bei der Sache:

1. Das Backup soll mit TrueCrypt verschlüsselt sein.
2. Das Backup soll per Mirror Verfahren entstehen. D.h. nur neuere Files werden gespeichert. Gelöschte Dateien werden auch im Backup gelöscht. Bedeutet: Source und Target müssen miteinander verglichen werden. Bedeutet: Das Backup auf dem Server muss erst entschlüsselt werden, damit verglichen werden kann.
3. Das ganze soll automatisiert ablaufen. Am besten per Batch Script und so, dass ich nur das TrueCrypt PW eingeben muss und der Rest geschieht von selbst.

Momentan ist der Ablauf nicht automatisiert und damit sehr aufwendig. Hier mal die einzelnen Schirtte, um das Ganze zu verdeutlichen:

1. Ich starte den Server vom Laptop aus per Wake On Lan.
2. Ich erstelle eine Remote Desktop Verbindung mit dem Server.
3. Ich entschlüssele die Backup Festplatte auf dem Server mit TrueCrypt.
4. Ich gebe die Festplatte im Heimnetzwerk frei. Das dauert jedes mal..
5. Ich starte das Backup vom Laptop aus. Momentan verwende ich SyncBack als Client.
6. Wenn das Backup fertig ist fahre ich den Server runter.

Das ganze ca. 2x die Woche.

Eins der größten Probleme ist momentan, dass ich die entschlüsselten Laufwerke immer wieder neu im LAN freigeben muss. Wenn man die TrueCrpy Entschlüsselung aufhebt ist die Laufwerkfreigabe hin und muss mit der nächsten Entschlüsselung neu durchgeführt werden..

Als erstes müsste ich einen Script erstellen, der die TrueCrypt Laufwerke so mountet, dass sie im Netzwerk erkannt werden. Vielleicht kann ich sie auch so mounten, dass sie auf meinem Laptop als lokales Laufwerk erscheinen?

 

[wupi]

Er liefert das richtige Zitat gleich mit.

„Zwei Dinge sind unendlich, das Universum und die menschliche Dummheit, aber bei dem Universum bin ich mir noch nicht ganz sicher.“
Albert Einstein

Einfacher wäre es einen Container zu erstellen und den per Netzlaufwerk zu mounten. Dann fällt 2-4 weg.

 

[le0m]

nicknackman1.. *the trolling is strong in this one*


Hier mal ein Auszug aus der TrueCrypt Anleitung:

Sharing over Network

If there is a need to access a single TrueCrypt volume simultaneously from multiple operating systems, there are two options:

1. A TrueCrypt volume is mounted only on a single computer (for example, on a server) and only the content of the mounted TrueCrypt volume (i.e., the file system within the TrueCrypt volume) is shared over a network. Users on other computers or systems will not mount the volume (it is already mounted on the server).
   
   Advantages: All users can write data to the TrueCrypt volume. The shared volume may be both file-hosted and partition/device-hosted.
   
   Disadvantage: Data sent over the network will not be encrypted. However, it is still possible to encrypt them using e.g. SSL, TLS, VPN, or other technologies.
   
   Remarks: Note that, when you restart the system, the network share will be automatically restored only if the volume is a system favorite volume or an encrypted system partition/drive (for information on how to configure a volume as a system favorite volume, see the chapter System Favorite Volumes).
   
   
2. A dismounted TrueCrypt file container is stored on a single computer (for example, on a server). This encrypted file is shared over a network. Users on other computers or systems will locally mount the shared file. Thus, the volume will be mounted simultaneously under multiple operating systems.
   
   Advantage: Data sent over the network will be encrypted (however, it is still recommended to encrypt them using e.g. SSL, TLS, VPN, or other appropriate technologies to make traffic analysis more difficult and to preserve the integrity of the data).
   
   Disadvantages: The shared volume may be only file-hosted (not partition/device-hosted). The volume must be mounted in read-only mode under each of the systems (see the section Mount Options for information on how to mount a volume in read-only mode). Note that this requirement applies to unencrypted volumes too. One of the reasons is, for example, the fact that data read from a conventional file system under one OS while the file system is being modified by another OS might be inconsistent (which could result in data corruption).

Seitens TrueCrypt gibt es wohl nur zwei Möglichkeiten Ordner zu sharen:

1) Man mountet den Ordner auf dem Server und gibt die entschlüsselten Files dann frei, so wie ich es bisher gemacht habe. Leider mit dem Nachteil, dass die Freigaben jedes mal verloren gehen und neu erstellt werden müssen. Die einzige Möglichkeit die Freigaben zu erhalten wäre das TrueCrypt Volume als "system favorite volume" oder als "encrypted system partition" zu erstellen. Da ich die Systemplatte aber nicht verschlüsseln möchte, kommt beides nicht in frage.

2) Man wählt den verschlüsselten Container/Laufwerk vom Server und mountet ihn lokal als Laufwerk. Das hat den Nachteil, dass man auf das gemountete Volume nicht schreiben kann. Diese Methode ist für mich also unbrauchbar..

Es bleibt also nur Methode 1)...

Wahrscheinlich muss ich einen Batch Script erstellen, welcher vom Laptop aus die Platte auf dem Server mountet und das gemountete Volume dann frei gibt. Letzendlich würde der Script dann das was ich momentan manuell mache eins zu eins imitieren.

Einfacher wäre es einen Container zu erstellen und den per Netzlaufwerk zu mounten.

Meinst du so wie ich es bisher gemacht habe?

1. Ich starte den Server vom Laptop aus per Wake On Lan.
2. Ich erstelle eine Remote Desktop Verbindung mit dem Server.
3. Ich entschlüssele die Backup Festplatte auf dem Server mit TrueCrypt.
4. Ich gebe die Festplatte im Heimnetzwerk frei. Das dauert jedes mal..
5. Ich starte das Backup vom Laptop aus. Momentan verwende ich SyncBack als Client.
6. Wenn das Backup fertig ist fahre ich den Server runter.

Oder wie?

Update:

Oder meinst du, dass man den verschlüsselten Container freigibt und diesen dann lokal auf dem Laptop als Laufwerk mountet? Das wäre auch keine Option, weil man dann auf das gemountete Laufwerk nur lesen und nicht schreiben kann.

 

[wupi]

Oder meinst du, dass man den verschlüsselten Container freigibt und diesen dann lokal auf dem Laptop als Laufwerk mountet?

Gerade getestet, kann lesen und schreiben.
Kannst du ja selber mal ausprobieren.
Hab hier einen Linux Server mit Samba Freigabe.

 

[le0m]

Gerade getestet, kann lesen und schreiben.
Kannst du ja selber mal ausprobieren.
Hab hier einen Linux Server mit Samba Freigabe.

Du hast recht. Ich hab's auch gerade getestet.

Dann finde ich diesen Abschnitt etwas irreführend oder ich habe ihn falsch verstanden:

Disadvantages: The shared volume may be only file-hosted (not partition/device-hosted). The volume must be mounted in read-only mode under each of the systems (see the section Mount Options for information on how to mount a volume in read-only mode). Note that this requirement applies to unencrypted volumes too. One of the reasons is, for example, the fact that data read from a conventional file system under one OS while the file system is being modified by another OS might be inconsistent (which could result in data corruption).

Mal gucken wie ich den Script zusammenbaue. Der Script müsste also das Volume vom Server lokal mounten und danach nur noch die Backups ausführen.

 

[tiash]

Ich verstehe das so, dass man read-only mounten soll, wenn da mehrere Rechner gleichzeitig drauf zugreifen. Damit nicht zufällig gleichzeitig geschrieben und so der Container unbrauchbar gemacht wird.
Für deinen Anwendungsfall ist die read only Beschränkung damit überflüssig.

 

[le0m]

Ich verstehe das so, dass man read-only mounten soll, wenn da mehrere Rechner gleichzeitig drauf zugreifen. Damit nicht zufällig gleichzeitig geschrieben und so der Container unbrauchbar gemacht wird.
Für deinen Anwendungsfall ist die read only Beschränkung damit überflüssig.

Eigentlich sehe ich auch kein Problem, solange der Container nur von einem OS zur Zeit gemountet wird. Das der Server was am Filesytsem des Containers ändert ohne ihn selbst zu mounten, halte ich für unwahrscheinlich. Aber so richtig deutlich wird das in dem Text irgendwie nicht..

 

[wupi]

So wie du den Container benutzen willst, passt das schon.