Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > ger.ct > #248188 > unrolled thread
| Started by | Rico Heil <news-spam@silmaril.de> |
|---|---|
| First post | 2016-03-25 22:02 +0100 |
| Last post | 2016-03-29 16:57 +0200 |
| Articles | 20 on this page of 53 — 18 participants |
Back to article view | Back to ger.ct
Backupkonzept für Crypto-Trojaner Rico Heil <news-spam@silmaril.de> - 2016-03-25 22:02 +0100
Re: Backupkonzept f??r Crypto-Trojaner v_borchert@despammed.com (Volker Borchert) - 2016-03-26 08:49 +0000
Re: Backupkonzept f??r Crypto-Trojaner Peter Mc Donough <mcd-mail-lists@gmx.net> - 2016-03-26 10:31 +0100
Re: Backupkonzept f??r Crypto-Trojaner Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2016-03-27 10:20 +0200
Re: Backupkonzept f??r Crypto-Trojaner Peter Mc Donough <mcd-mail-lists@gmx.net> - 2016-03-27 12:14 +0200
Re: Backupkonzept f??r Crypto-Trojaner Rico Heil <news-spam@silmaril.de> - 2016-03-26 21:11 +0100
Re: Backupkonzept für Crypto-Trojaner Fidel-Sebastian Hunrichse-Lara <Fidel-Sebastian_Hunrichse-Lara@b.maus.de> - 2016-03-26 16:41 +0100
Re: Backupkonzept für Crypto-Trojaner Rico Heil <news-spam@silmaril.de> - 2016-03-26 21:19 +0100
Re: Backupkonzept für Crypto-Trojaner Bernd Ullrich <ullrich_bernd@hotmail.com> - 2016-03-26 22:13 +0100
Re: Backupkonzept für Crypto-Trojaner Ruediger Lahl <ruediger.lahl@gmx.de> - 2016-03-26 21:29 +0000
Re: Backupkonzept für Crypto-Trojaner Fidel-Sebastian Hunrichse-Lara <Fidel-Sebastian_Hunrichse-Lara@b.maus.de> - 2016-03-26 23:57 +0100
Re: Backupkonzept für Crypto-Trojaner Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2016-03-27 10:22 +0200
Re: Backupkonzept für Crypto-Trojaner Fidel-Sebastian Hunrichse-Lara <Fidel-Sebastian_Hunrichse-Lara@b.maus.de> - 2016-03-27 12:27 +0200
Re: Backupkonzept für Crypto-Trojaner Thomas Paulsen <kr51-2@gmx.de> - 2016-03-27 16:10 +0200
Re: Backupkonzept für Crypto-Trojaner Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2016-03-27 16:36 +0200
Re: Backupkonzept für Crypto-Trojaner Rico Heil <news-spam@silmaril.de> - 2016-03-27 21:01 +0200
Re: Backupkonzept für Crypto-Trojaner Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2016-03-27 21:10 +0200
Re: Backupkonzept für Crypto-Trojaner spamfalle2@arcor.de (Marc Stibane) - 2016-03-28 12:22 +0200
Re: Backupkonzept für Crypto-Trojaner Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2016-03-29 11:18 +0200
Re: Backupkonzept für Crypto-Trojaner Michael Bode <m.g.bode@web.de> - 2016-03-29 21:27 +0200
Re: Backupkonzept für Crypto-Trojaner Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2016-03-29 22:07 +0200
Re: Backupkonzept für Crypto-Trojaner Michael Bode <m.g.bode@web.de> - 2016-03-29 22:20 +0200
Re: Backupkonzept für Crypto-Trojaner Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2016-03-29 22:43 +0200
Re: Backupkonzept für Crypto-Trojaner Michael Bode <m.g.bode@web.de> - 2016-03-29 22:52 +0200
Re: Backupkonzept für Crypto-Trojaner Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2016-03-29 23:16 +0200
Re: Backupkonzept für Crypto-Trojaner Dr. Joachim Neudert <neudert@5sl.org> - 2016-03-29 21:19 +0000
Re: Backupkonzept für Crypto-Trojaner Michael Bode <m.g.bode@web.de> - 2016-03-29 23:25 +0200
Re: Backupkonzept für Crypto-Trojaner Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2016-03-29 23:28 +0200
Re: Backupkonzept für Crypto-Trojaner Martin Gerdes <martin.gerdes@gmx.de> - 2016-04-02 12:00 +0200
Re: Backupkonzept für Crypto-Trojaner Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2016-04-02 19:17 +0200
Re: Backupkonzept für Crypto-Trojaner Dr. Joachim Neudert <neudert@5sl.org> - 2016-03-29 20:54 +0000
Re: Backupkonzept für Crypto-Trojaner Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2016-03-29 23:25 +0200
Re: Backupkonzept für Crypto-Trojaner "Ralph A. Schmid, dk5ras" <ralph@schmid.xxx> - 2016-03-30 10:30 +0200
Re: Backupkonzept für Crypto-Trojaner Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2016-03-30 12:12 +0200
Re: Backupkonzept für Crypto-Trojaner spamfalle2@arcor.de (Marc Stibane) - 2016-03-30 20:20 +0200
Re: Backupkonzept für Crypto-Trojaner Ingo Paschke <ipaschke@lpclabs.de> - 2016-03-31 10:54 +0200
Re: Backupkonzept für Crypto-Trojaner "Ralph A. Schmid, dk5ras" <ralph@schmid.xxx> - 2016-03-30 10:29 +0200
Re: Backupkonzept für Crypto-Trojaner Hanno Foest <hurga-news2@tigress.com> - 2016-03-30 10:30 +0200
Re: Backupkonzept für Crypto-Trojaner "Ralph A. Schmid, dk5ras" <ralph@schmid.xxx> - 2016-03-30 11:02 +0200
Re: Backupkonzept für Crypto-Trojaner Hanno Foest <hurga-news2@tigress.com> - 2016-03-30 11:41 +0200
Re: Backupkonzept für Crypto-Trojaner "Ralph A. Schmid, dk5ras" <ralph@schmid.xxx> - 2016-03-30 14:10 +0200
Re: Backupkonzept für Crypto-Trojaner Hanno Foest <hurga-news2@tigress.com> - 2016-03-30 10:09 +0200
Re: Backupkonzept für Crypto-Trojaner Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2016-03-30 12:09 +0200
Re: Backupkonzept für Crypto-Trojaner spamfalle2@arcor.de (Marc Stibane) - 2016-03-30 20:20 +0200
Re: Backupkonzept für Crypto-Trojaner Lothar Frings <Lothar.Frings@gmx.de> - 2016-03-28 08:20 -0700
Re: Backupkonzept für Crypto-Trojaner spamfalle2@arcor.de (Marc Stibane) - 2016-03-29 09:05 +0200
Re: Backupkonzept für Crypto-Trojaner Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2016-03-29 08:40 +0000
Re: Backupkonzept für Crypto-Trojaner Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2016-03-29 11:21 +0200
Re: Backupkonzept für Crypto-Trojaner Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2016-03-29 14:57 +0000
Re: Backupkonzept für Crypto-Trojaner Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2016-03-29 17:06 +0200
Re: Backupkonzept für Crypto-Trojaner Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2016-03-29 16:26 +0000
Re: Backupkonzept für Crypto-Trojaner Christian Jesserer <jessi.nutznetz@gmx.at> - 2016-03-29 12:01 +0200
Re: Backupkonzept für Crypto-Trojaner Fidel-Sebastian Hunrichse-Lara <Fidel-Sebastian_Hunrichse-Lara@b.maus.de> - 2016-03-29 16:57 +0200
Page 1 of 3 [1] 2 3 Next page →
| From | Rico Heil <news-spam@silmaril.de> |
|---|---|
| Date | 2016-03-25 22:02 +0100 |
| Subject | Backupkonzept für Crypto-Trojaner |
| Message-ID | <nd491n$pbn$1@solani.org> |
Hallo zusammen, die aktuelle c't beschäftigt sich damit und vermutlich auch viele andere Leute: Wie sichert man seine Daten sinnvoll, um auch bei Befall durch einen Crypto-Trojaner fein raus zu sein? Die c't schreibt in erster Linie was von abgetrennten Backups. Externe Festplatten als Backup zu haben ist zwar toll (hat auch noch den Zusatznutzen der Blitzsicherheit, wenn man wirklich alle Kabel entfernt), der Nachteil ist aber, dass der Backup-Prozess manuelle Schritte enthält, also in der Praxis viel zu selten gemacht wird. Meine Idee dazu wäre: Man hat einen Backup-Server im lokalen Netzwerk, der unter Linux läuft (könnte ein PC sein oder ein Linux-NAS). Dort gibt es ein Backup-Verzeichnis, das per SMB freigegeben ist. Auf dieses spiegeln alle Clients ihre zu sichernden Dateien (möglichst automatisiert). Auf dem Backup-Server läuft "Back In Time". Dieses sichert regelmäßig Snapshots in einen Pfad des Servers, der nicht im Netzwerk freigegeben ist (könnte aber durchaus auf dem gleichen lokalen Dateisystem liegen). Der böse Trojaner auf einem Client könnte dann natürlich lokale Dateien verschlüsseln und die würden auch noch automatisch die Kopie in der Freigabe des Backup-Servers demolieren. Im Back-In-Time-Backup würde das zu vielen neuen Dateiversionen führen, die alten wären aber immer noch vorhanden. Man müsste nur darauf achten, dass genug Speicherplatz verfügbar ist bzw. dass bei voller Platte nicht automatisch alte Snapshots gelöscht werden - sonst säße man irgendwann doch wieder mit den aktuellen verschlüsselten Exemplaren da. Was meint Ihr dazu? Funktioniert das so, oder habe ich irgendwo einen Denkfehler, der ein Loch in dieses Konzept schießt? Falls das so funktioniert, ist die nächste Frage gleich, welche Hardware dafür empfehlenswert wäre. Ich hätte am liebsten ein möglichst stromsparendes NAS mit Linux und viel Plattenplatz. Ordentliche GB-LAN-Anbindung wäre auch wünschenswert. In meinem Fall werden etwa 4 TB Backup-Kapazität benötigt, d.h. in Summe sollten 12 TB zur Verfügung stehen, möglichst erweiterbar (Faktor 3 kommt von 1x SMB-Ordner, 1x aktueller Snapshot und 1x Reserve für ältere Snapshots). Und kosten soll's natürlich am besten nix ;-) Oder wenigstens nicht mehr als nötig :-) Vielen Dank für alle Tipps! Rico
[toc] | [next] | [standalone]
| From | v_borchert@despammed.com (Volker Borchert) |
|---|---|
| Date | 2016-03-26 08:49 +0000 |
| Subject | Re: Backupkonzept f??r Crypto-Trojaner |
| Message-ID | <nd5iev$9c9$1@Gaia.teknon.de> |
| In reply to | #248188 |
Rico Heil wrote: > Wie sichert man seine Daten sinnvoll, um auch bei Befall durch einen > Crypto-Trojaner fein raus zu sein? > > Die c't schreibt in erster Linie was von abgetrennten Backups. Externe > Festplatten als Backup zu haben ist zwar toll (hat auch noch den > Zusatznutzen der Blitzsicherheit, wenn man wirklich alle Kabel > entfernt), der Nachteil ist aber, dass der Backup-Prozess manuelle > Schritte enthält, also in der Praxis viel zu selten gemacht wird. Wenn du aus dem Urlaub zurück bist, brennst du deine Fotos auf DVD. Wenn du deine Steuererklärung gemacht hast, brennst du sie auf CD. Jeweils genau zweimal, ein Exemplar off-site gelagert. VC-Repositories ändern sich zwar laufend, andererseits ist aber nicht einzusehen, warum die als SMB-share sichtbar sein sollten. Solange es also kein "cvs encrypt" oder "svn ransom" gibt... Für deine Mail benutze einen lokalen IMAP Server als Archiv. -- "I'm a doctor, not a mechanic." Dr Leonard McCoy <mccoy@ncc1701.starfleet.fed> "I'm a mechanic, not a doctor." Volker Borchert <v_borchert@despammed.com>
[toc] | [prev] | [next] | [standalone]
| From | Peter Mc Donough <mcd-mail-lists@gmx.net> |
|---|---|
| Date | 2016-03-26 10:31 +0100 |
| Subject | Re: Backupkonzept f??r Crypto-Trojaner |
| Message-ID | <dln37uFin34U1@mid.individual.net> |
| In reply to | #248210 |
Am 26.03.2016 um 09:49 schrieb Volker Borchert: > Rico Heil wrote: > >> Wie sichert man seine Daten sinnvoll, um auch bei Befall durch einen >> Crypto-Trojaner fein raus zu sein? >> >> Die c't schreibt in erster Linie was von abgetrennten Backups. Externe >> Festplatten als Backup zu haben ist zwar toll (hat auch noch den >> Zusatznutzen der Blitzsicherheit, wenn man wirklich alle Kabel >> entfernt), der Nachteil ist aber, dass der Backup-Prozess manuelle >> Schritte enthält, also in der Praxis viel zu selten gemacht wird. > > Wenn du aus dem Urlaub zurück bist, brennst du deine Fotos auf DVD. > Wenn du deine Steuererklärung gemacht hast, brennst du sie auf CD. > Jeweils genau zweimal, ein Exemplar off-site gelagert. Zusammen mit einem Laufwerk. Die Fotos alle zwei Jahre kontrollieren und gegebenenfalls neu brennen, das Laufwerk überprüfen;-) Im Ernst, mittlerweile halte ich die Cloud und ein lokales Massenbackupmedium für solche Zwecke für die bessere Lösung. Gruß Peter
[toc] | [prev] | [next] | [standalone]
| From | Gerrit Heitsch <gerrit@laosinh.s.bawue.de> |
|---|---|
| Date | 2016-03-27 10:20 +0200 |
| Subject | Re: Backupkonzept f??r Crypto-Trojaner |
| Message-ID | <nd80f2$9o6$1@news.bawue.net> |
| In reply to | #248213 |
On 03/26/2016 10:31 AM, Peter Mc Donough wrote: > > Im Ernst, mittlerweile halte ich die Cloud und ein lokales > Massenbackupmedium für solche Zwecke für die bessere Lösung. Die Cloud nur wenn die Daten VOR dem Upload verschlüsselt werden, also niemals im Klartext/Klarbild dort vorhanden sind. Gerrit
[toc] | [prev] | [next] | [standalone]
| From | Peter Mc Donough <mcd-mail-lists@gmx.net> |
|---|---|
| Date | 2016-03-27 12:14 +0200 |
| Subject | Re: Backupkonzept f??r Crypto-Trojaner |
| Message-ID | <dlpq47F90mbU1@mid.individual.net> |
| In reply to | #248280 |
Am 27.03.2016 um 10:20 schrieb Gerrit Heitsch: > On 03/26/2016 10:31 AM, Peter Mc Donough wrote: >> >> Im Ernst, mittlerweile halte ich die Cloud und ein lokales >> Massenbackupmedium für solche Zwecke für die bessere Lösung. > > Die Cloud nur wenn die Daten VOR dem Upload verschlüsselt werden, also > niemals im Klartext/Klarbild dort vorhanden sind. Genau. Für den schnellen Zugriff genügt das lokale Massenbackupmedium. In der Cloud sind die verschlüsselten Daten. Mit einiger Wahrscheinlichkeit sicherer untergebracht als im eigenen Haus. Alle Daten würde ich eh nicht in die Cloud legen. Gruß Peter
[toc] | [prev] | [next] | [standalone]
| From | Rico Heil <news-spam@silmaril.de> |
|---|---|
| Date | 2016-03-26 21:11 +0100 |
| Subject | Re: Backupkonzept f??r Crypto-Trojaner |
| Message-ID | <nd6qd6$sja$1@solani.org> |
| In reply to | #248210 |
Am 26.03.2016 um 09:49 schrieb Volker Borchert: > Wenn du aus dem Urlaub zurück bist, brennst du deine Fotos auf DVD. > Wenn du deine Steuererklärung gemacht hast, brennst du sie auf CD. > Jeweils genau zweimal, ein Exemplar off-site gelagert. Und dann wieder das Geschiss mit den alternden Medien? Nein danke! "Mitwachsende" Plattenkapazität hat sich bei mir bewährt - mal ganz abgesehen von der Tatsache dass die RAW-Bilder eines Urlaubs nicht auf eine DVD passen. > VC-Repositories ändern sich zwar laufend, andererseits ist aber nicht > einzusehen, warum die als SMB-share sichtbar sein sollten. Solange es > also kein "cvs encrypt" oder "svn ransom" gibt... Stimmt. Konzeptionell ähnlich meinem Vorschlag mit Back In Time. Nur dass ich dort den zusätzlichen Vorteil habe, dass man zum Zugriff auf das Backup nichts weiter benötigt als ein Betriebssystem, das das Dateisystem lesen kann. Die zusätzliche Abstraktionsebene bei SVN & Co sehe ich hier eher als weitere Fehlerquelle. > Für deine Mail benutze einen lokalen IMAP Server als Archiv. Das klingt nach einer schönen Idee, aber von diesem Archiv bräuchte es dann auch wieder ein versioniertes Backup. Ich gehe davon aus, dass wir in absehbarer Zukunft Ransomware sehen werden, die IMAP-Postfach-Inhalte verschlüsselt. Oder kann man den Server so konfigurieren, dass er zwar das Erstellen und Verschieben von Nachrichten erlaubt, aber nicht das Löschen oder verändern (geht letzteres überhaupt mit IMAP)? Rico
[toc] | [prev] | [next] | [standalone]
| From | Fidel-Sebastian Hunrichse-Lara <Fidel-Sebastian_Hunrichse-Lara@b.maus.de> |
|---|---|
| Date | 2016-03-26 16:41 +0100 |
| Message-ID | <nd6ae3$l70$1@dont-email.me> |
| In reply to | #248188 |
Salve allerseits, Rico Heil schrieb: > die aktuelle c't beschäftigt sich damit und vermutlich auch viele andere > Leute: > Wie sichert man seine Daten sinnvoll, um auch bei Befall durch einen > Crypto-Trojaner fein raus zu sein? > > Die c't schreibt in erster Linie was von abgetrennten Backups. Externe > Festplatten als Backup zu haben ist zwar toll (hat auch noch den > Zusatznutzen der Blitzsicherheit, wenn man wirklich alle Kabel > entfernt), der Nachteil ist aber, dass der Backup-Prozess manuelle > Schritte enthält, also in der Praxis viel zu selten gemacht wird. > Ich mache nach jedem Update eine Sicherung von meiner Boot-SSD! Meine Daten-SSD wird wöchentlich gesichert – sollte privat reichen... M.f.G. -- Diese E-Mail-Adresse wird nur aus nostalgischen Gründen verwendet. Sie wird praktisch nie gelesen. Das MausNet ist nicht tot – es riecht nur etwas komisch... ;-)
[toc] | [prev] | [next] | [standalone]
| From | Rico Heil <news-spam@silmaril.de> |
|---|---|
| Date | 2016-03-26 21:19 +0100 |
| Message-ID | <nd6qru$u71$1@solani.org> |
| In reply to | #248245 |
Am 26.03.2016 um 16:41 schrieb Fidel-Sebastian Hunrichse-Lara: > Ich mache nach jedem Update eine Sicherung von meiner Boot-SSD! Sollte das nicht heißen *vor* dem Update? Ich stelle mir gerade den Ablauf vor: 1) Windows updates einspielen, 2) Backup machen, 3) feststellen dass etwas seit dem Update nicht mehr geht, 4) Äh... Moment mal... Mist, ich hab kein Backup vor dem Update mehr! Rico
[toc] | [prev] | [next] | [standalone]
| From | Bernd Ullrich <ullrich_bernd@hotmail.com> |
|---|---|
| Date | 2016-03-26 22:13 +0100 |
| Message-ID | <dlocbbFt3g6U1@mid.individual.net> |
| In reply to | #248263 |
Am 26.03.2016 um 21:19 schrieb Rico Heil: > Am 26.03.2016 um 16:41 schrieb Fidel-Sebastian Hunrichse-Lara: >> Ich mache nach jedem Update eine Sicherung von meiner Boot-SSD! > > Sollte das nicht heiÃen *vor* dem Update? ------------ > Ich stelle mir gerade den Ablauf vor: > 1) Windows updates einspielen, > 2) Backup machen, > 3) feststellen dass etwas seit dem Update nicht mehr geht, > 4) Ãh... Moment mal... Mist, ich hab kein Backup vor dem Update mehr! Dann hast _du_ an der falschen Stelle gespart. BU
[toc] | [prev] | [next] | [standalone]
| From | Ruediger Lahl <ruediger.lahl@gmx.de> |
|---|---|
| Date | 2016-03-26 21:29 +0000 |
| Message-ID | <nd6uv0$md7$1@news.albasani.net> |
| In reply to | #248263 |
Rico Heil <news-spam@silmaril.de> wrote: > Am 26.03.2016 um 16:41 schrieb Fidel-Sebastian Hunrichse-Lara: >> Ich mache nach jedem Update eine Sicherung von meiner Boot-SSD! > > Sollte das nicht heißen *vor* dem Update? > > Ich stelle mir gerade den Ablauf vor: > 1) Windows updates einspielen, > 2) Backup machen, > 3) feststellen dass etwas seit dem Update nicht mehr geht, > 4) Äh... Moment mal... Mist, ich hab kein Backup vor dem Update mehr! Doch, hast du. Systemsteuerung -> Programme und Funktionen [Updates einblenden] -> letztes Update deinstallieren. Startet Win gar nicht mehr, mit IIRC 'F8' starten und 'letzte als lauffähig bekannte Version wiederherstellen' auswählen. Windows bietet da schon einige Sicherheitsmechanismen. -- bis denne
[toc] | [prev] | [next] | [standalone]
| From | Fidel-Sebastian Hunrichse-Lara <Fidel-Sebastian_Hunrichse-Lara@b.maus.de> |
|---|---|
| Date | 2016-03-26 23:57 +0100 |
| Message-ID | <nd73vg$jgq$1@dont-email.me> |
| In reply to | #248263 |
Salve allerseits, Rico Heil schrieb: > Am 26.03.2016 um 16:41 schrieb Fidel-Sebastian Hunrichse-Lara: >> Ich mache nach jedem Update eine Sicherung von meiner Boot-SSD! > > Sollte das nicht heißen *vor* dem Update? > > Ich stelle mir gerade den Ablauf vor: > 1) Windows updates einspielen, > 2) Backup machen, > 3) feststellen dass etwas seit dem Update nicht mehr geht, > 4) Äh... Moment mal... Mist, ich hab kein Backup vor dem Update mehr! > Chlor! Ob man sein Backup davor oder danach macht, ist nämlich schlussendlich Jacke wie Hose! Man muss diesbezüglich nur konsequent sein und nicht mal so und mal so es handhaben... M.f.G. -- Diese E-Mail-Adresse wird nur aus nostalgischen Gründen verwendet. Sie wird praktisch nie gelesen. Das MausNet ist nicht tot – es riecht nur etwas komisch... ;-)
[toc] | [prev] | [next] | [standalone]
| From | Gerrit Heitsch <gerrit@laosinh.s.bawue.de> |
|---|---|
| Date | 2016-03-27 10:22 +0200 |
| Message-ID | <nd80it$9o6$2@news.bawue.net> |
| In reply to | #248263 |
On 03/26/2016 09:19 PM, Rico Heil wrote: > Am 26.03.2016 um 16:41 schrieb Fidel-Sebastian Hunrichse-Lara: >> Ich mache nach jedem Update eine Sicherung von meiner Boot-SSD! > > Sollte das nicht heißen *vor* dem Update? Beides natürlich. Ein Backup davor damit man ein garantiert lauffähiges System hat und eines danach damit das Update im Backup ist. Ausserdem hat man natürlich mehr als ein Backup. Gerit
[toc] | [prev] | [next] | [standalone]
| From | Fidel-Sebastian Hunrichse-Lara <Fidel-Sebastian_Hunrichse-Lara@b.maus.de> |
|---|---|
| Date | 2016-03-27 12:27 +0200 |
| Message-ID | <nd8cc8$tvg$1@dont-email.me> |
| In reply to | #248281 |
Salve allerseits, Gerrit Heitsch schrieb: > On 03/26/2016 09:19 PM, Rico Heil wrote: >> Am 26.03.2016 um 16:41 schrieb Fidel-Sebastian Hunrichse-Lara: >>> Ich mache nach jedem Update eine Sicherung von meiner Boot-SSD! >> >> Sollte das nicht heißen *vor* dem Update? > > Beides natürlich. Ein Backup davor damit man ein garantiert lauffähiges > System hat und eines danach damit das Update im Backup ist. > > Ausserdem hat man natürlich mehr als ein Backup. > Yoh! Dass man nach dem Großvater-Vater-Sohn-Prinzip vorgehen sollte, setze ich schlicht als bekannt voraus... M.f.G. -- Diese E-Mail-Adresse wird nur aus nostalgischen Gründen verwendet. Sie wird praktisch nie gelesen. Das MausNet ist nicht tot – es riecht nur etwas komisch... ;-)
[toc] | [prev] | [next] | [standalone]
| From | Thomas Paulsen <kr51-2@gmx.de> |
|---|---|
| Date | 2016-03-27 16:10 +0200 |
| Message-ID | <20160327161059.399324d7@siC5> |
| In reply to | #248188 |
Rico Heil schrieb: > Hallo zusammen, > > die aktuelle c't beschäftigt sich damit und vermutlich auch viele > andere Leute: > Wie sichert man seine Daten sinnvoll, um auch bei Befall durch einen > Crypto-Trojaner fein raus zu sein? > > Die c't schreibt in erster Linie was von abgetrennten Backups. Externe > Festplatten als Backup zu haben ist zwar toll (hat auch noch den > Zusatznutzen der Blitzsicherheit, wenn man wirklich alle Kabel > entfernt), der Nachteil ist aber, dass der Backup-Prozess manuelle > Schritte enthält, also in der Praxis viel zu selten gemacht wird. Übungssache. Neben meinem Rechner liegen drei externe Platten für Backups: Daten1, Daten2 (werden alternierend gefüttert) und Musik. Ich habe seit Jahren kein Problem damit, die von Hand anzuschließen und das Backup zu starten. Thomas
[toc] | [prev] | [next] | [standalone]
| From | Gerrit Heitsch <gerrit@laosinh.s.bawue.de> |
|---|---|
| Date | 2016-03-27 16:36 +0200 |
| Message-ID | <nd8mfv$2v7$1@news.bawue.net> |
| In reply to | #248337 |
On 03/27/2016 04:10 PM, Thomas Paulsen wrote: > Rico Heil schrieb: >> Hallo zusammen, >> >> die aktuelle c't beschäftigt sich damit und vermutlich auch viele >> andere Leute: >> Wie sichert man seine Daten sinnvoll, um auch bei Befall durch einen >> Crypto-Trojaner fein raus zu sein? >> >> Die c't schreibt in erster Linie was von abgetrennten Backups. Externe >> Festplatten als Backup zu haben ist zwar toll (hat auch noch den >> Zusatznutzen der Blitzsicherheit, wenn man wirklich alle Kabel >> entfernt), der Nachteil ist aber, dass der Backup-Prozess manuelle >> Schritte enthält, also in der Praxis viel zu selten gemacht wird. > > Übungssache. > > Neben meinem Rechner liegen drei externe Platten für Backups: Daten1, > Daten2 (werden alternierend gefüttert) und Musik. > > Ich habe seit Jahren kein Problem damit, die von Hand anzuschließen und > das Backup zu starten. Mache ich auch so. Das ganze per Script, so daß die Backup-HD nur die minimal nötige Zeit gemountet ist. Benutzt wird rsync mit der Option '--link-dest=' um versionierte Backups zu erzeugen. Auf dem Mac gehts per Timemachine. Noch besser wäre die Backup HD an einem anderen Rechner zu haben und die backups dort per rsync zu erzeugen. Ein Crypto-Trojaner kann dann die Originale nicht verschlüsseln weil die Files eben auf keinem direkt erreichbaren Share liegen. rsync erledigt das per SSH. Gerrit
[toc] | [prev] | [next] | [standalone]
| From | Rico Heil <news-spam@silmaril.de> |
|---|---|
| Date | 2016-03-27 21:01 +0200 |
| Message-ID | <nd9amd$q4i$1@solani.org> |
| In reply to | #248340 |
Am 27.03.2016 um 16:36 schrieb Gerrit Heitsch: > Noch besser wäre die Backup HD an einem anderen Rechner zu haben und die > backups dort per rsync zu erzeugen. Ein Crypto-Trojaner kann dann die > Originale nicht verschlüsseln weil die Files eben auf keinem direkt > erreichbaren Share liegen. rsync erledigt das per SSH. Vom Prinzip her sehr ähnlich meinem Ursprünglichen Vorschlag. Wenn ich dich richtig verstehe mit dem Unterschied, dass es in Deinem Szenario keinen "einfache" Kopie der Daten auf dem Backup-System gibt, sondern das Backup direkt per rsync eingeliefert wird. Da müsste ich mal checken, ob das Back In Time auch kann - würde ggfs. selbstgemachte Script-Fehler vermeiden. Andererseits bräuchte ich so ein Script vermutlich sowieso für die Windows-Clients. Danke für die Anregung! Diese Struktur würde aus meinen genannten 12 TB Speicherbedarf erstmal 8 TB machen. Rico
[toc] | [prev] | [next] | [standalone]
| From | Gerrit Heitsch <gerrit@laosinh.s.bawue.de> |
|---|---|
| Date | 2016-03-27 21:10 +0200 |
| Message-ID | <nd96hk$kop$1@news.bawue.net> |
| In reply to | #248407 |
On 03/27/2016 09:01 PM, Rico Heil wrote: > Am 27.03.2016 um 16:36 schrieb Gerrit Heitsch: >> Noch besser wäre die Backup HD an einem anderen Rechner zu haben und die >> backups dort per rsync zu erzeugen. Ein Crypto-Trojaner kann dann die >> Originale nicht verschlüsseln weil die Files eben auf keinem direkt >> erreichbaren Share liegen. rsync erledigt das per SSH. > > Vom Prinzip her sehr ähnlich meinem Ursprünglichen Vorschlag. > Wenn ich dich richtig verstehe mit dem Unterschied, dass es in Deinem > Szenario keinen "einfache" Kopie der Daten auf dem Backup-System gibt, > sondern das Backup direkt per rsync eingeliefert wird. Vor allem wenn man rsync mit '--link-dest=' benutzt sobald man verstanden hat was diese Option tut und wie man sie anwendet. Auch sollte man für normale Backups '--delete' vermeiden und nur mittels manuellem Aufruf Dateien im Backup löschen. Gerrit
[toc] | [prev] | [next] | [standalone]
| From | spamfalle2@arcor.de (Marc Stibane) |
|---|---|
| Date | 2016-03-28 12:22 +0200 |
| Message-ID | <1mkrpmo.2f0n7kxywx7yN@marc.my-fqdn.de> |
| In reply to | #248188 |
Rico Heil <news-spam@silmaril.de> wrote: > Wie sichert man seine Daten sinnvoll, um auch bei Befall durch einen > Crypto-Trojaner fein raus zu sein? per Copy-on-write. Oder eben mit Snapshots auf einer anderen Platte. > Man hat einen Backup-Server im lokalen Netzwerk, der unter Linux läuft oder FreeNAS... > Dort gibt es ein Backup-Verzeichnis, das per SMB freigegeben ist. Auf > dieses spiegeln alle Clients ihre zu sichernden Dateien (möglichst > automatisiert). TimeMachine ;-) > Auf dem Backup-Server läuft "Back In Time". Dieses sichert regelmäßig > Snapshots in einen Pfad des Servers, der nicht im Netzwerk freigegeben > ist (könnte aber durchaus auf dem gleichen lokalen Dateisystem liegen). Snapshots kann FreeNAS automatisch anlegen. Kostet so gut wie keinen Speicher, weil einfach nur der aktuelle Root-Block gesichert wird. Der zeigt auf die Directories, die zeigen auf die Files. Wann immer jetzt ein File neu geschrieben wird, wird es in einen leeren Bereich geschrieben und überschreibt nix bereits existierendes. Dann wird das Directory neu geschrieben, ebenfalls in einen freien Bereich. Dann das Root-Directory, und schließlich der Root-Block der darauf zeigt. Wenn man einen Snapshot reaktiviert, zeigt der alte Root-Block auf das alte Root-Directory, dadrin wird auf das alte Leaf-Directory verwiesen, darin auf das alte File. Alles noch da... > Der böse Trojaner auf einem Client könnte dann natürlich lokale Dateien > verschlüsseln und die würden auch noch automatisch die Kopie in der > Freigabe des Backup-Servers demolieren. Im Back-In-Time-Backup würde das > zu vielen neuen Dateiversionen führen, die alten wären aber immer noch > vorhanden. Oder so... Wenn das Filesystem kein Copy-on-write macht, muss man halt rechtzeitig alles kopieren, d.h. man braucht den doppelten Speicherplatz. Mit Copy-on-write wird erst beim Überschreiben einer Datei Speicherplatz verbraucht, eben für die neue Datei, die alte bleibt einfach liegen. > Man müsste nur darauf achten, dass genug Speicherplatz verfügbar ist > bzw. dass bei voller Platte nicht automatisch alte Snapshots gelöscht > werden - sonst säße man irgendwann doch wieder mit den aktuellen > verschlüsselten Exemplaren da. Genau. FreeNAS verschickt automatisch Mails ab 80%, da bleibt dann noch Zeit zum Reagieren. Und natürlich werden Snapshots entweder manuell oder ebenfalls zeitgesteuert gelöscht, z.B. nach 4 oder 6 Wochen, aber genau nicht automatisch wenn es voll wird - das würde ja den Sinn und Zweck von Snapshots konterkarieren. > Was meint Ihr dazu? Copy-on-write rules! > Funktioniert das so, oder habe ich irgendwo einen Denkfehler, der ein > Loch in dieses Konzept schießt? Warum Linux? > Falls das so funktioniert, ist die nächste Frage gleich, welche Hardware > dafür empfehlenswert wäre. > Ich hätte am liebsten ein möglichst stromsparendes NAS mit Linux und > viel Plattenplatz. Ordentliche GB-LAN-Anbindung wäre auch wünschenswert. > In meinem Fall werden etwa 4 TB Backup-Kapazität benötigt, d.h. in Summe > sollten 12 TB zur Verfügung stehen, möglichst erweiterbar (Faktor 3 > kommt von 1x SMB-Ordner, 1x aktueller Snapshot und 1x Reserve für ältere > Snapshots). a) Copy-on-write rules. Vor allem wenn man einen großen Teil Daten hat der sich wenig bis gar nicht ändert - der braucht dann nämlich NULL zusätzlichen Speicherplatz und ist trotzdem auf beliebig vielen Snapshots mit drauf. b) Ich würde nicht mehr auf einfache Redundanz (RAID-5, raidz1) vertrauen, sondern doppelte nehmen (RAID-6 bzw. raidz2). Es gibt hunderte Fail-Stories im Netz wo bei 'nem NAS mit einfacher Redundanz nach Ausfall einer Platte eine neue reingesteckt wird, die Wiederherstellung anläuft woraufhin ALLE Blöcke der alten Platten ausgelesen werden müssen um die Daten der Ersatz-Platte zu berechnen, und dann im Streß eine zweite alte Platte ausfällt... Verloren. Alles. c) Eigentlich will man auch Bitkipper im RAM ausschließen, damit das NAS einem nicht unbemerkt alle Files schrottet. Also ECC-RAM. Für Server gibt es sowas ja - mir ist absolut unbegreiflich warum man überhaupt noch Computer ohne baut. > Und kosten soll's natürlich am besten nix ;-) > Oder wenigstens nicht mehr als nötig :-) Dann bleibt nur ein Cloud-Backup ;-) > Vielen Dank für alle Tipps! Ich habe gleich zwei Backup-Server: Ein ReadyNAS Duo mit zwei 8TB-Platten, ohne Redundanz, also netto 16TB. Das läuft 24/7/52 durch, und ist recht sparsam. Und ein HP N4L (FreeNAS) mit sechs 4TB-Platten, doppelter Redundanz, 24TB brutto, und ebenfalls 16TB netto. Das schluckt ordentlich Strom, und wird deswegen nur alle 2-3 Wochen ein paar Stunden eingeschaltet. Auf beiden sind dieselben Daten - auf dem HP N4L halt mit Snapshots (Sicherheit gegen Software-Probleme / Überschreiben), Redundanz (Sicherheit gegen Hardware-Probleme / Festplattenausfall) und ECC-RAM (Sicherheit gegen Bit-Rot). Die 16TB netto Speicherplatz im HP waren auch ganz erheblich teurer als die 16TB netto im ReadyNAS Duo. Sicherheit kostet. Isso... -- In a world without walls and fences, who needs windows and gates?
[toc] | [prev] | [next] | [standalone]
| From | Gerrit Heitsch <gerrit@laosinh.s.bawue.de> |
|---|---|
| Date | 2016-03-29 11:18 +0200 |
| Message-ID | <nddchs$bqg$1@news.bawue.net> |
| In reply to | #248461 |
On 03/28/2016 12:22 PM, Marc Stibane wrote: > Rico Heil <news-spam@silmaril.de> wrote: > >> Wie sichert man seine Daten sinnvoll, um auch bei Befall durch einen >> Crypto-Trojaner fein raus zu sein? > > per Copy-on-write. Oder eben mit Snapshots auf einer anderen Platte. Copy on Write hilft nichts wenn dazu nicht auch noch ein Snapshot kommt oder du ein FS mit Versionierung hast. > Oder so... > Wenn das Filesystem kein Copy-on-write macht, muss man halt rechtzeitig > alles kopieren, d.h. man braucht den doppelten Speicherplatz. Mit > Copy-on-write wird erst beim Überschreiben einer Datei Speicherplatz > verbraucht, eben für die neue Datei, die alte bleibt einfach liegen. Nur wenn ein Snapshot existiert. Dieses Detail darf man keinesfalls vergessen. Tut man es ist die Datei trotzdem weg. > b) Ich würde nicht mehr auf einfache Redundanz (RAID-5, raidz1) > vertrauen, sondern doppelte nehmen (RAID-6 bzw. raidz2). > Es gibt hunderte Fail-Stories im Netz wo bei 'nem NAS mit einfacher > Redundanz nach Ausfall einer Platte eine neue reingesteckt wird, die > Wiederherstellung anläuft woraufhin ALLE Blöcke der alten Platten > ausgelesen werden müssen um die Daten der Ersatz-Platte zu berechnen, > und dann im Streß eine zweite alte Platte ausfällt... > Verloren. Alles. Da ZFS ein FS und ein Volumemanager in einem ist liest es beim Sync eines RAID nur die belegten Blöcke aus. Ist das RAID voll sind das natürlich alle, ansonsten eben je nach Füllstand. Das kann einen Unterschied machen. Ansonsten gilt aufgrund deiner Beschreibung oben weiterhin: RAID ist kein Backup, letzteres braucht man trotzdem! Wer das nicht beachtet kann z.B. bei einem Sommergewitter alle Daten verlieren. > c) Eigentlich will man auch Bitkipper im RAM ausschließen, damit das NAS > einem nicht unbemerkt alle Files schrottet. Also ECC-RAM. Für Server > gibt es sowas ja - mir ist absolut unbegreiflich warum man überhaupt > noch Computer ohne baut. Ja, wer einen Server mit ZFS oder ähnlichem betreibt braucht ohne ECC-RAM erst gar nicht anfangen. Ein 'scrub' und ein defektes Bit im RAM an passender Stelle und schon hat man seine Daten gesehen. Warum es noch Rechner ohne ECC-RAM gibt? Der extra RAM-Chip kostet Geld und Platz (siehe SO-DIMMs für Laptops). Meist gehts ja auch ohne, aber wenn nicht kostet das schnell mehr als was man für ECC-RAM hätte hinlegen müssen. Gerrit
[toc] | [prev] | [next] | [standalone]
| From | Michael Bode <m.g.bode@web.de> |
|---|---|
| Date | 2016-03-29 21:27 +0200 |
| Message-ID | <dm039pFropfU1@mid.individual.net> |
| In reply to | #248587 |
Am 29.03.2016 um 11:18 schrieb Gerrit Heitsch: > Warum es noch Rechner ohne ECC-RAM gibt? Der extra RAM-Chip kostet Geld > und Platz (siehe SO-DIMMs für Laptops). Meist gehts ja auch ohne, aber > wenn nicht kostet das schnell mehr als was man für ECC-RAM hätte > hinlegen müssen. Wie heißt denn das AMD Gegenstück zu einem Core i5 5200U und wie sieht der rechen- und verlustleistungsmäßig im Vergleich aus?
[toc] | [prev] | [next] | [standalone]
Page 1 of 3 [1] 2 3 Next page →
Back to top | Article view | ger.ct
csiph-web