Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > ger.ct > #556102 > unrolled thread
| Started by | "Dr. Joachim Neudert" <neudert@5sl.org> |
|---|---|
| First post | 2022-05-29 10:03 +0200 |
| Last post | 2022-05-29 16:54 +0200 |
| Articles | 20 on this page of 135 — 29 participants |
Back to article view | Back to ger.ct
Festplatten vernichten "Dr. Joachim Neudert" <neudert@5sl.org> - 2022-05-29 10:03 +0200
Re: Festplatten vernichten Michael Pachta <mipani@gmx.de> - 2022-05-29 10:23 +0200
Re: Festplatten vernichten Bernd Ohm <invalid@invalid.invalid> - 2022-05-29 10:25 +0200
Re: Festplatten vernichten Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2022-05-29 10:32 +0200
Re: Festplatten vernichten "Wendelin Uez" <wuez@online.de> - 2022-05-29 18:34 +0200
Re: Festplatten vernichten Shinji Ikari <shinji@gmx.net> - 2022-05-29 20:09 +0200
Re: Festplatten vernichten Michael Pachta <mipani@gmx.de> - 2022-05-29 20:48 +0200
Re: Festplatten vernichten Shinji Ikari <shinji@gmx.net> - 2022-05-29 20:57 +0200
Re: Festplatten vernichten Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2022-05-29 21:10 +0200
Re: Festplatten vernichten Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2022-05-29 21:03 +0200
Re: Festplatten vernichten Andreas Bockelmann <xotzil@gmx.de> - 2022-05-29 10:30 +0200
Re: Festplatten vernichten Michael Bode <m.g.bode@web.de> - 2022-05-29 10:33 +0200
Re: Festplatten vernichten Hermann Riemann <nospam.ng@hermann-riemann.de> - 2022-05-29 13:23 +0200
Re: Festplatten vernichten "Wendelin Uez" <wuez@online.de> - 2022-05-29 17:59 +0200
Re: Festplatten vernichten Hermann Riemann <nospam.ng@hermann-riemann.de> - 2022-05-29 19:01 +0200
Re: Festplatten vernichten Ulrich Weise <ulrich.weise@t-online.de> - 2022-05-30 10:20 +0200
Re: Festplatten vernichten "Wendelin Uez" <wuez@online.de> - 2022-05-30 12:47 +0200
Re: Festplatten vernichten Matthias Eißing <meissing@gmx.de> - 2022-05-30 13:44 +0200
Re: Festplatten vernichten Shinji Ikari <shinji@gmx.net> - 2022-05-30 14:27 +0200
Re: Festplatten vernichten "Wendelin Uez" <wuez@online.de> - 2022-05-30 20:39 +0200
Re: Festplatten vernichten Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2022-05-30 20:51 +0200
Re: Festplatten vernichten Shinji Ikari <shinji@gmx.net> - 2022-05-30 20:55 +0200
Re: Festplatten vernichten "Wendelin Uez" <wuez@online.de> - 2022-05-31 10:17 +0200
Re: Festplatten vernichten Michael Zink <michael@swamp.franken.de> - 2022-05-30 09:22 +0200
Re: Festplatten vernichten Hermann Riemann <nospam.ng@hermann-riemann.de> - 2022-05-30 09:33 +0200
Re: Festplatten vernichten Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2022-05-30 11:45 +0200
Re: Festplatten vernichten Hermann Riemann <nospam.ng@hermann-riemann.de> - 2022-05-30 12:57 +0200
Re: Festplatten vernichten Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2022-05-30 13:13 +0200
Re: Festplatten vernichten Frank Scheffski <usenet@alles-moppelkotze.de> - 2022-05-29 10:42 +0200
Re: Festplatten vernichten Hermann Riemann <nospam.ng@hermann-riemann.de> - 2022-05-29 14:09 +0200
Re: Festplatten vernichten Andreas Bockelmann <xotzil@gmx.de> - 2022-05-29 15:28 +0200
Re: Festplatten vernichten Wolf gang P u f f e <remail@gmx.com> - 2022-05-29 20:32 +0200
Re: Festplatten vernichten Bonita Montero <Bonita.Montero@gmail.com> - 2022-05-29 11:00 +0200
Re: Festplatten vernichten Marco Moock <mo01@posteo.de> - 2022-05-29 12:07 +0200
Re: Festplatten vernichten Hermann Riemann <nospam.ng@hermann-riemann.de> - 2022-05-29 14:13 +0200
Re: Festplatten vernichten Bonita Montero <Bonita.Montero@gmail.com> - 2022-05-29 14:29 +0200
Re: Festplatten vernichten Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2022-05-29 17:25 +0200
Re: Festplatten vernichten Bonita Montero <Bonita.Montero@gmail.com> - 2022-05-29 18:19 +0200
Re: Festplatten vernichten Bernd Ullrich <ullrich_bernd@hotmail.com> - 2022-05-29 18:45 +0200
Re: Festplatten vernichten Bonita Montero <Bonita.Montero@gmail.com> - 2022-06-01 07:44 +0200
Re: Festplatten vernichten Shinji Ikari <shinji@gmx.net> - 2022-05-29 20:12 +0200
Re: Festplatten vernichten Bonita Montero <Bonita.Montero@gmail.com> - 2022-06-01 07:43 +0200
Re: Festplatten vernichten Shinji Ikari <shinji@gmx.net> - 2022-06-01 08:44 +0200
Re: Festplatten vernichten Bonita Montero <Bonita.Montero@gmail.com> - 2022-06-01 09:02 +0200
Re: Festplatten vernichten spamfalle2@arcor.de (Marc Stibane) - 2022-06-03 08:38 +0200
Re: Festplatten vernichten "Dr. Joachim Neudert" <neudert@5sl.org> - 2022-06-03 09:02 +0200
Re: Festplatten vernichten Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2022-06-03 09:28 +0200
Re: Festplatten vernichten "Peter Heitzer" <peter.heitzer@rz.uni-regensburg.de> - 2022-06-03 07:33 +0000
Re: Festplatten vernichten Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2022-06-03 09:57 +0200
Re: Festplatten vernichten Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2022-06-03 16:45 +0200
Re: Festplatten vernichten Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2022-06-04 18:11 +0200
Re: Festplatten vernichten Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2022-06-04 21:12 +0200
Re: Festplatten vernichten Bonita Montero <Bonita.Montero@gmail.com> - 2022-06-03 10:25 +0200
Re: Festplatten vernichten "Dr. Joachim Neudert" <neudert@5sl.org> - 2022-06-03 09:44 +0200
Re: Festplatten vernichten Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2022-06-03 10:01 +0200
Re: Festplatten vernichten spamfalle2@arcor.de (Marc Stibane) - 2022-06-03 14:15 +0200
Re: Festplatten vernichten Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2022-06-03 14:34 +0200
Re: Festplatten vernichten "Wendelin Uez" <wuez@online.de> - 2022-06-03 10:41 +0200
Re: Festplatten vernichten "Dr. Joachim Neudert" <neudert@5sl.org> - 2022-06-03 11:41 +0200
Re: Festplatten vernichten Michael Bode <m.g.bode@web.de> - 2022-06-03 17:26 +0200
Re: Festplatten vernichten Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2022-06-04 18:13 +0200
Re: Festplatten vernichten Michael Bode <m.g.bode@web.de> - 2022-06-04 23:10 +0200
Re: Festplatten vernichten Michael Bode <m.g.bode@web.de> - 2022-06-04 23:11 +0200
Re: Festplatten vernichten Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2022-06-04 23:33 +0200
Re: Festplatten vernichten Michael Bode <m.g.bode@web.de> - 2022-06-05 00:00 +0200
Re: Festplatten vernichten Bonita Montero <Bonita.Montero@gmail.com> - 2022-06-03 09:10 +0200
Re: Festplatten vernichten Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2022-06-03 09:29 +0200
Re: Festplatten vernichten Bonita Montero <Bonita.Montero@gmail.com> - 2022-06-03 10:26 +0200
Re: Festplatten vernichten Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2022-06-03 10:50 +0200
Re: Festplatten vernichten Bonita Montero <Bonita.Montero@gmail.com> - 2022-06-03 10:56 +0200
Re: Festplatten vernichten Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2022-06-03 11:04 +0200
Re: Festplatten vernichten Bonita Montero <Bonita.Montero@gmail.com> - 2022-06-03 13:04 +0200
Re: Festplatten vernichten Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2022-06-03 13:06 +0200
Re: Festplatten vernichten Bonita Montero <Bonita.Montero@gmail.com> - 2022-06-03 13:35 +0200
Re: Festplatten vernichten Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2022-06-03 13:42 +0200
Re: Festplatten vernichten Bonita Montero <Bonita.Montero@gmail.com> - 2022-06-03 14:25 +0200
Re: Festplatten vernichten Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2022-06-03 14:46 +0200
Re: Festplatten vernichten Bonita Montero <Bonita.Montero@gmail.com> - 2022-06-03 14:54 +0200
Re: Festplatten vernichten Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2022-06-03 14:58 +0200
Re: Festplatten vernichten Bonita Montero <Bonita.Montero@gmail.com> - 2022-06-03 15:02 +0200
Re: Festplatten vernichten Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2022-06-03 15:06 +0200
Re: Festplatten vernichten Bonita Montero <Bonita.Montero@gmail.com> - 2022-06-03 15:14 +0200
Re: Festplatten vernichten Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2022-06-04 18:08 +0200
Re: Festplatten vernichten Bonita Montero <Bonita.Montero@gmail.com> - 2022-06-04 18:32 +0200
Re: Festplatten vernichten Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2022-06-04 18:55 +0200
Re: Festplatten vernichten Bonita Montero <Bonita.Montero@gmail.com> - 2022-06-04 18:59 +0200
Re: Festplatten vernichten Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2022-06-04 19:04 +0200
Re: Festplatten vernichten Bonita Montero <Bonita.Montero@gmail.com> - 2022-06-04 19:10 +0200
Re: Festplatten vernichten Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2022-06-04 19:27 +0200
Re: Festplatten vernichten Bonita Montero <Bonita.Montero@gmail.com> - 2022-06-04 19:29 +0200
Re: Festplatten vernichten spamfalle2@arcor.de (Marc Stibane) - 2022-06-03 14:15 +0200
Re: Festplatten vernichten Bonita Montero <Bonita.Montero@gmail.com> - 2022-06-03 14:27 +0200
Re: Festplatten vernichten Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2022-06-03 14:33 +0200
Re: Festplatten vernichten Bonita Montero <Bonita.Montero@gmail.com> - 2022-06-03 14:37 +0200
Re: Festplatten vernichten Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2022-06-03 14:47 +0200
Re: Festplatten vernichten Bonita Montero <Bonita.Montero@gmail.com> - 2022-06-03 14:54 +0200
Re: Festplatten vernichten Ulrich Weise <ulrich.weise@t-online.de> - 2022-05-29 11:42 +0200
Re: Festplatten vernichten Wolf gang P u f f e <remail@gmx.com> - 2022-05-29 12:02 +0200
Re: Festplatten vernichten Marco Moock <mo01@posteo.de> - 2022-05-29 12:05 +0200
Re: Festplatten vernichten Ruediger Lahl <ruediger.lahl@gmx.de> - 2022-05-29 11:52 +0200
Re: Festplatten vernichten Bonita Montero <Bonita.Montero@gmail.com> - 2022-05-29 12:47 +0200
Re: Festplatten vernichten Lothar Kimmeringer <news201705@kimmeringer.de> - 2022-05-29 21:13 +0200
Re: Festplatten vernichten mit Grill Hermann Riemann <nospam.ng@hermann-riemann.de> - 2022-05-30 08:30 +0200
Re: Festplatten vernichten mit Grill Lothar Kimmeringer <news201705@kimmeringer.de> - 2022-05-30 18:57 +0200
Re: Festplatten vernichten mit Grill Wolfgang Kynast <wky@gmx.de> - 2022-05-30 19:49 +0200
Re: Festplatten vernichten Bonita Montero <Bonita.Montero@gmail.com> - 2022-05-31 13:36 +0200
Re: Festplatten vernichten Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2022-05-29 11:02 +0000
Re: Festplatten vernichten "Dr. Joachim Neudert" <neudert@5sl.org> - 2022-05-29 13:32 +0200
Re: Festplatten vernichten "Dr. Joachim Neudert" <neudert@5sl.org> - 2022-05-29 13:37 +0200
Re: Festplatten vernichten Wolfgang Kynast <wky@gmx.de> - 2022-05-29 13:41 +0200
Re: Festplatten vernichten Daniel Weber <usenet@daniel-weber.eu> - 2022-05-29 14:40 +0200
Re: Festplatten vernichten Ulf Kutzner <Ulf.Kutzner@web.de> - 2022-05-29 07:54 -0700
Re: Festplatten vernichten Daniel Weber <usenet@daniel-weber.eu> - 2022-05-30 11:27 +0200
Re: Festplatten vernichten Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2022-05-29 16:11 +0000
Re: Festplatten vernichten Hartmut Ott <hottm@arcor.de> - 2022-05-29 15:50 +0200
Re: Festplatten vernichten Herwig <herwig.huener@t-online.de> - 2022-05-29 07:02 -0700
Re: Festplatten vernichten Hermann Riemann <nospam.ng@hermann-riemann.de> - 2022-05-29 17:24 +0200
Re: Festplatten vernichten Ulf Kutzner <Ulf.Kutzner@web.de> - 2022-05-29 08:37 -0700
Re: Festplatten vernichten Hermann Riemann <nospam.ng@hermann-riemann.de> - 2022-05-29 18:10 +0200
Re: Festplatten vernichten Ruediger Lahl <ruediger.lahl@gmx.de> - 2022-05-30 05:59 +0200
Re: Festplatten vernichten Ulf Kutzner <Ulf.Kutzner@web.de> - 2022-05-29 08:40 -0700
Re: Festplatten vernichten Michael Pachta <mipani@gmx.de> - 2022-05-30 12:49 +0200
Re: Festplatten vernichten Hartmut Ott <hottm@arcor.de> - 2022-05-30 15:16 +0200
Re: Festplatten vernichten Herwig <herwig.huener@t-online.de> - 2022-05-29 07:00 -0700
Re: Festplatten vernichten Hermann Riemann <nospam.ng@hermann-riemann.de> - 2022-05-29 18:56 +0200
Re: Festplatten vernichten Ned Kelly <ned.kelly@nefkom.net> - 2022-05-29 20:52 +0200
Re: Festplatten vernichten Induktionskochfeldplatte oder Mikrowelle? Hermann Riemann <nospam.ng@hermann-riemann.de> - 2022-05-30 08:25 +0200
Re: Festplatten vernichten Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2022-05-30 08:55 +0200
Re: Festplatten vernichten Ned Kelly <ned.kelly@nefkom.net> - 2022-05-31 13:13 +0200
Re: Festplatten vernichten Hermann Riemann <nospam.ng@hermann-riemann.de> - 2022-05-31 14:23 +0200
Re: Festplatten vernichten Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2022-05-29 16:41 +0200
Re: Festplatten vernichten Hermann Riemann <nospam.ng@hermann-riemann.de> - 2022-05-29 17:21 +0200
Re: Festplatten vernichten Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2022-05-29 17:49 +0200
Re: Festplatten vernichten Shinji Ikari <shinji@gmx.net> - 2022-05-29 20:15 +0200
Re: Festplatten vernichten Bonita Montero <Bonita.Montero@gmail.com> - 2022-05-29 16:54 +0200
Page 4 of 7 — ← Prev page 1 2 3 [4] 5 6 7 Next page →
| From | Gerrit Heitsch <gerrit@laosinh.s.bawue.de> |
|---|---|
| Date | 2022-06-04 18:13 +0200 |
| Message-ID | <t7g0ak$pnd$2@news.bawue.net> |
| In reply to | #556712 |
On 6/3/22 17:26, Michael Bode wrote: > "Dr. Joachim Neudert" <neudert@5sl.org> writes: > >> Am 03.06.22 um 08:38 schrieb Marc Stibane: >>> Explizit "sicher löschen" mache ich, indem ich den Key aus meiner >>> KeyChain lösche (und den Zettel wo ich ihn aufgeschrieben habe >>> verbrenne). Kein Zugriff auf die Platte selber nötig... >> >> Ich möchte wetten, kein anderes Verfahren, kein Headcrash und kein >> Diebstahl hat schon mehr irreversible Datenverluste bewirkt als das >> bombenfeste Verschlüsseln der Fstplatten. >> >> So wie mit den USVs. USV-Tests richten mehr Schaden an als >> Stromausfälle es je könnten. Frag bei den Betreibern des >> Tchernobyl-Reaktors nach. >> >> (Wenn man bei den kleinen APC USVs mal auf den grün leuchtenden Knopf >> drückt, in der Hoffnung jetzt testet sie sich mal und schaltet um auf >> Akkubetrieb- Puff, ist der Server stromlos und die Platten sind im >> down-spin...) > > Deshalb ist ja auch das eine Netzteil des Servers in die USV eingesteckt > und das andere hängt direkt am Netz. Oder an einer zweiten USV, aber dazu braucht man einen richtigen Server mit mindesten 2 Netzteilen. Gerrit
[toc] | [prev] | [next] | [standalone]
| From | Michael Bode <m.g.bode@web.de> |
|---|---|
| Date | 2022-06-04 23:10 +0200 |
| Message-ID | <jg202aFh996U4@mid.individual.net> |
| In reply to | #556773 |
Gerrit Heitsch <gerrit@laosinh.s.bawue.de> writes: >>> (Wenn man bei den kleinen APC USVs mal auf den grün leuchtenden Knopf >>> drückt, in der Hoffnung jetzt testet sie sich mal und schaltet um auf >>> Akkubetrieb- Puff, ist der Server stromlos und die Platten sind im >>> down-spin...) >> >> Deshalb ist ja auch das eine Netzteil des Servers in die USV eingesteckt >> und das andere hängt direkt am Netz. > > Oder an einer zweiten USV, aber dazu braucht man einen richtigen > Server mit mindesten 2 Netzteilen. Wenn es nur ein Netzteil hat, ist es nicht wichtig.
[toc] | [prev] | [next] | [standalone]
| From | Michael Bode <m.g.bode@web.de> |
|---|---|
| Date | 2022-06-04 23:11 +0200 |
| Message-ID | <jg2048Fh996U5@mid.individual.net> |
| In reply to | #556807 |
Michael Bode <m.g.bode@web.de> writes: > Gerrit Heitsch <gerrit@laosinh.s.bawue.de> writes: > > >>>> (Wenn man bei den kleinen APC USVs mal auf den grün leuchtenden Knopf >>>> drückt, in der Hoffnung jetzt testet sie sich mal und schaltet um auf >>>> Akkubetrieb- Puff, ist der Server stromlos und die Platten sind im >>>> down-spin...) >>> >>> Deshalb ist ja auch das eine Netzteil des Servers in die USV eingesteckt >>> und das andere hängt direkt am Netz. >> >> Oder an einer zweiten USV, aber dazu braucht man einen richtigen >> Server mit mindesten 2 Netzteilen. > > Wenn es nur ein Netzteil hat, ist es nicht wichtig. Nachtrag: oder ein Knoten eines HA-Clusters.
[toc] | [prev] | [next] | [standalone]
| From | Gerrit Heitsch <gerrit@laosinh.s.bawue.de> |
|---|---|
| Date | 2022-06-04 23:33 +0200 |
| Message-ID | <t7gj2r$1ib$1@news.bawue.net> |
| In reply to | #556808 |
On 6/4/22 23:11, Michael Bode wrote: > Michael Bode <m.g.bode@web.de> writes: > >> Gerrit Heitsch <gerrit@laosinh.s.bawue.de> writes: >> >> >>>>> (Wenn man bei den kleinen APC USVs mal auf den grün leuchtenden Knopf >>>>> drückt, in der Hoffnung jetzt testet sie sich mal und schaltet um auf >>>>> Akkubetrieb- Puff, ist der Server stromlos und die Platten sind im >>>>> down-spin...) >>>> >>>> Deshalb ist ja auch das eine Netzteil des Servers in die USV eingesteckt >>>> und das andere hängt direkt am Netz. >>> >>> Oder an einer zweiten USV, aber dazu braucht man einen richtigen >>> Server mit mindesten 2 Netzteilen. >> >> Wenn es nur ein Netzteil hat, ist es nicht wichtig. > > Nachtrag: oder ein Knoten eines HA-Clusters. Auch bei denen will man eigentlich nicht, daß der Ausfall eines Netzteiles oder der Stromversorgung den Knoten offline nimmt. Der Ausfall eines Knotens darf natürlich passieren, aber es sollte schon ein guter Grund (TM) sein. Gerrit
[toc] | [prev] | [next] | [standalone]
| From | Michael Bode <m.g.bode@web.de> |
|---|---|
| Date | 2022-06-05 00:00 +0200 |
| Message-ID | <jg22vbFh996U6@mid.individual.net> |
| In reply to | #556809 |
Gerrit Heitsch <gerrit@laosinh.s.bawue.de> writes: > On 6/4/22 23:11, Michael Bode wrote: >> Michael Bode <m.g.bode@web.de> writes: >> >>> Gerrit Heitsch <gerrit@laosinh.s.bawue.de> writes: >>> >>> >>>>>> (Wenn man bei den kleinen APC USVs mal auf den grün leuchtenden Knopf >>>>>> drückt, in der Hoffnung jetzt testet sie sich mal und schaltet um auf >>>>>> Akkubetrieb- Puff, ist der Server stromlos und die Platten sind im >>>>>> down-spin...) >>>>> >>>>> Deshalb ist ja auch das eine Netzteil des Servers in die USV eingesteckt >>>>> und das andere hängt direkt am Netz. >>>> >>>> Oder an einer zweiten USV, aber dazu braucht man einen richtigen >>>> Server mit mindesten 2 Netzteilen. >>> >>> Wenn es nur ein Netzteil hat, ist es nicht wichtig. >> >> Nachtrag: oder ein Knoten eines HA-Clusters. > > Auch bei denen will man eigentlich nicht, daß der Ausfall eines > Netzteiles oder der Stromversorgung den Knoten offline nimmt. Der > Ausfall eines Knotens darf natürlich passieren, aber es sollte schon > ein guter Grund (TM) sein. Aus Spaß muss das nicht sein. Aber bei einem Update muss man halt die einzelnen Knoten schon mal rebooten. Dafür ist das ja da. Gibt natürlich auch die Luxusausführung, wo im einzelnen Knoten nicht die Netzteile redundant sind, sondern gleich die ganze Hardware. Eine Nimble ist schon ein geiles Gerät.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2022-06-03 09:10 +0200 |
| Message-ID | <t7cc40$au$1@dont-email.me> |
| In reply to | #556624 |
> Welchen Zweck hat das? Einmal überschreiben (mit Nullen oder sonstwas) > sorgt auch dafür dass man die Daten nicht mehr wiederherstellen kann. Ja, es dauert aber um Größenordnugnen länger als einmal einen Key zu überschreiben der nach außen eh nicht lesbar ist, dass die Daten mit einem Schlag zu irgendwas werden. > Wozu also das "sichere Löschen"? Und warum wird das per Key abgesichert, > überschreiben aber nicht? Ich mein das ist so bei SSDs nicht implementiert und von mir schon zu über-vorsichtig ausgelegt. Aber grundsätzlich könnte es doch Malware geben die es irgrndwie schafft, der SSD dieses spezielle Komando zu geben, dass dem Nutzer alles unterm Arsch weggezogen wird. > Bei MacOS kann man die Platte beim Einrichten (vom OS) verschlüsseln, > man braucht dann den Key zum Mounten (lesen und schreiben). ... Völllig andere Zielsetzung.
[toc] | [prev] | [next] | [standalone]
| From | Gerrit Heitsch <gerrit@laosinh.s.bawue.de> |
|---|---|
| Date | 2022-06-03 09:29 +0200 |
| Message-ID | <t7cd9b$862$2@news.bawue.net> |
| In reply to | #556632 |
On 6/3/22 09:10, Bonita Montero wrote: >> Welchen Zweck hat das? Einmal überschreiben (mit Nullen oder sonstwas) >> sorgt auch dafür dass man die Daten nicht mehr wiederherstellen kann. > > Ja, es dauert aber um Größenordnugnen länger als einmal einen Key zu > überschreiben der nach außen eh nicht lesbar ist, dass die Daten mit > einem Schlag zu irgendwas werden. > >> Wozu also das "sichere Löschen"? Und warum wird das per Key abgesichert, >> überschreiben aber nicht? > > Ich mein das ist so bei SSDs nicht implementiert und von mir schon zu > über-vorsichtig ausgelegt. 'ATA secure erase' ist auch bei SSDs implementiert. Gerrit
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2022-06-03 10:26 +0200 |
| Message-ID | <t7cgjo$sim$2@dont-email.me> |
| In reply to | #556637 |
Am 03.06.2022 um 09:29 schrieb Gerrit Heitsch: > On 6/3/22 09:10, Bonita Montero wrote: >>> Welchen Zweck hat das? Einmal überschreiben (mit Nullen oder sonstwas) >>> sorgt auch dafür dass man die Daten nicht mehr wiederherstellen kann. >> >> Ja, es dauert aber um Größenordnugnen länger als einmal einen Key zu >> überschreiben der nach außen eh nicht lesbar ist, dass die Daten mit >> einem Schlag zu irgendwas werden. >> >>> Wozu also das "sichere Löschen"? Und warum wird das per Key abgesichert, >>> überschreiben aber nicht? >> >> Ich mein das ist so bei SSDs nicht implementiert und von mir schon zu >> über-vorsichtig ausgelegt. > > 'ATA secure erase' ist auch bei SSDs implementiert. SSDs die was anderes machen als NVMe sind bald History.
[toc] | [prev] | [next] | [standalone]
| From | Gerrit Heitsch <gerrit@laosinh.s.bawue.de> |
|---|---|
| Date | 2022-06-03 10:50 +0200 |
| Message-ID | <t7ci18$a57$1@news.bawue.net> |
| In reply to | #556650 |
On 6/3/22 10:26, Bonita Montero wrote: > Am 03.06.2022 um 09:29 schrieb Gerrit Heitsch: >> On 6/3/22 09:10, Bonita Montero wrote: >>>> Welchen Zweck hat das? Einmal überschreiben (mit Nullen oder sonstwas) >>>> sorgt auch dafür dass man die Daten nicht mehr wiederherstellen kann. >>> >>> Ja, es dauert aber um Größenordnugnen länger als einmal einen Key zu >>> überschreiben der nach außen eh nicht lesbar ist, dass die Daten mit >>> einem Schlag zu irgendwas werden. >>> >>>> Wozu also das "sichere Löschen"? Und warum wird das per Key >>>> abgesichert, >>>> überschreiben aber nicht? >>> >>> Ich mein das ist so bei SSDs nicht implementiert und von mir schon zu >>> über-vorsichtig ausgelegt. >> >> 'ATA secure erase' ist auch bei SSDs implementiert. > > SSDs die was anderes machen als NVMe sind bald History. Eher nicht, denn M.2-Slots hat man meist nur einen oder, mit Glück, zwei. SSDs mit SATA wirds noch eine ganze Weile geben. Auch NVMe SSDs haben ein secure erase Kommando. nvme list nvme format -s1 /dev/<device> Installier dir 'nvme-cli' wenn du Linux hast. Gerrit
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2022-06-03 10:56 +0200 |
| Message-ID | <t7ciat$98l$1@dont-email.me> |
| In reply to | #556655 |
Am 03.06.2022 um 10:50 schrieb Gerrit Heitsch: > On 6/3/22 10:26, Bonita Montero wrote: >> Am 03.06.2022 um 09:29 schrieb Gerrit Heitsch: >>> On 6/3/22 09:10, Bonita Montero wrote: >>>>> Welchen Zweck hat das? Einmal überschreiben (mit Nullen oder sonstwas) >>>>> sorgt auch dafür dass man die Daten nicht mehr wiederherstellen kann. >>>> >>>> Ja, es dauert aber um Größenordnugnen länger als einmal einen Key zu >>>> überschreiben der nach außen eh nicht lesbar ist, dass die Daten mit >>>> einem Schlag zu irgendwas werden. >>>> >>>>> Wozu also das "sichere Löschen"? Und warum wird das per Key >>>>> abgesichert, >>>>> überschreiben aber nicht? >>>> >>>> Ich mein das ist so bei SSDs nicht implementiert und von mir schon zu >>>> über-vorsichtig ausgelegt. >>> >>> 'ATA secure erase' ist auch bei SSDs implementiert. >> >> SSDs die was anderes machen als NVMe sind bald History. > > Eher nicht, denn M.2-Slots hat man meist nur einen oder, mit > Glück, zwei. SSDs mit SATA wirds noch eine ganze Weile geben. Ich meine SSD und 1-N Platten sind ja nicht selten, aber mehrere SSDs schon > Auch NVMe SSDs haben ein secure erase Kommando. Ja, vermutlich per ATA-Befehl. Hrhr.
[toc] | [prev] | [next] | [standalone]
| From | Gerrit Heitsch <gerrit@laosinh.s.bawue.de> |
|---|---|
| Date | 2022-06-03 11:04 +0200 |
| Message-ID | <t7cirk$ahv$1@news.bawue.net> |
| In reply to | #556656 |
On 6/3/22 10:56, Bonita Montero wrote: > Am 03.06.2022 um 10:50 schrieb Gerrit Heitsch: >> On 6/3/22 10:26, Bonita Montero wrote: >>> Am 03.06.2022 um 09:29 schrieb Gerrit Heitsch: >>>> On 6/3/22 09:10, Bonita Montero wrote: >>>>>> Welchen Zweck hat das? Einmal überschreiben (mit Nullen oder >>>>>> sonstwas) >>>>>> sorgt auch dafür dass man die Daten nicht mehr wiederherstellen kann. >>>>> >>>>> Ja, es dauert aber um Größenordnugnen länger als einmal einen Key zu >>>>> überschreiben der nach außen eh nicht lesbar ist, dass die Daten mit >>>>> einem Schlag zu irgendwas werden. >>>>> >>>>>> Wozu also das "sichere Löschen"? Und warum wird das per Key >>>>>> abgesichert, >>>>>> überschreiben aber nicht? >>>>> >>>>> Ich mein das ist so bei SSDs nicht implementiert und von mir schon zu >>>>> über-vorsichtig ausgelegt. >>>> >>>> 'ATA secure erase' ist auch bei SSDs implementiert. >>> >>> SSDs die was anderes machen als NVMe sind bald History. >> >> Eher nicht, denn M.2-Slots hat man meist nur einen oder, mit >> Glück, zwei. SSDs mit SATA wirds noch eine ganze Weile geben. > > Ich meine SSD und 1-N Platten sind ja nicht selten, > aber mehrere SSDs schon Ein RAID1 aus SSDs hätte schon was. Problem ist nur, für NVMe braucht man PCIe lanes und da gibt es immer noch Engpässe. >> Auch NVMe SSDs haben ein secure erase Kommando. > > Ja, vermutlich per ATA-Befehl. Hrhr. Nein, denn dann ginge es ja weiterhin mit 'hdparm' unter Linux. Tut es aber nicht. Du brauchst das 'nvme' Kommando. Gerrit
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2022-06-03 13:04 +0200 |
| Message-ID | <t7cps3$1sf$1@dont-email.me> |
| In reply to | #556658 |
> Ein RAID1 aus SSDs hätte schon was. Problem ist nur, für NVMe > braucht man PCIe lanes und da gibt es immer noch Engpässe. Alles außer linearem Kopieren von größeren Files wird dadurch eh nicht mekrbar beschleunigt.
[toc] | [prev] | [next] | [standalone]
| From | Gerrit Heitsch <gerrit@laosinh.s.bawue.de> |
|---|---|
| Date | 2022-06-03 13:06 +0200 |
| Message-ID | <t7cpv4$dco$1@news.bawue.net> |
| In reply to | #556672 |
On 6/3/22 13:04, Bonita Montero wrote: >> Ein RAID1 aus SSDs hätte schon was. Problem ist nur, für NVMe >> braucht man PCIe lanes und da gibt es immer noch Engpässe. > > Alles außer linearem Kopieren von größeren Files wird dadurch > eh nicht mekrbar beschleunigt. Darum geht es bei RAID1 auch nicht, sondern um Betriebssicherheit. SSDs sind auch nur Hardware die jederzeit und ohne Warnung den Geist aufgeben kann. Gerrit
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2022-06-03 13:35 +0200 |
| Message-ID | <t7crl5$g3m$1@dont-email.me> |
| In reply to | #556673 |
Am 03.06.2022 um 13:06 schrieb Gerrit Heitsch: > On 6/3/22 13:04, Bonita Montero wrote: >>> Ein RAID1 aus SSDs hätte schon was. Problem ist nur, für NVMe >>> braucht man PCIe lanes und da gibt es immer noch Engpässe. >> >> Alles außer linearem Kopieren von größeren Files wird dadurch >> eh nicht mekrbar beschleunigt. > > Darum geht es bei RAID1 auch nicht, sondern um Betriebssicherheit. SSDs > sind auch nur Hardware die jederzeit und ohne Warnung den Geist aufgeben > kann. Natürlich geht es bei RAID1 auch darum, denn wenn ich z.B. 10MB lese, dann kommen 5MB von der einen Platte, 5MB von der anderen; nur geschrieben wird synchron. Ich wüsste allerdings nicht, wozu ich ein RAID1 mit SSSs brauche. Ich habe einfach ein simple 2TB WD NVMe-SSD mit PCIe 3.0, und die 120GB, die ich da an Daten drauf habe habe ich in 6min auf eine SATA Staging-SSD und von dort aus gehts dann gleichermaßen, aber eben langsamer auf eine externe Platte. Zweite SSD im RAID ist wirklich Overkill.
[toc] | [prev] | [next] | [standalone]
| From | Gerrit Heitsch <gerrit@laosinh.s.bawue.de> |
|---|---|
| Date | 2022-06-03 13:42 +0200 |
| Message-ID | <t7cs28$e85$1@news.bawue.net> |
| In reply to | #556677 |
On 6/3/22 13:35, Bonita Montero wrote: > Am 03.06.2022 um 13:06 schrieb Gerrit Heitsch: >> On 6/3/22 13:04, Bonita Montero wrote: >>>> Ein RAID1 aus SSDs hätte schon was. Problem ist nur, für NVMe >>>> braucht man PCIe lanes und da gibt es immer noch Engpässe. >>> >>> Alles außer linearem Kopieren von größeren Files wird dadurch >>> eh nicht mekrbar beschleunigt. >> >> Darum geht es bei RAID1 auch nicht, sondern um Betriebssicherheit. >> SSDs sind auch nur Hardware die jederzeit und ohne Warnung den Geist >> aufgeben kann. > > Natürlich geht es bei RAID1 auch darum, denn wenn ich z.B. 10MB > lese, dann kommen 5MB von der einen Platte, 5MB von der anderen; > nur geschrieben wird synchron. Beides ist konfigurierbar. Sobald z.B. SOD involviert ist und über längere Leitungen angebunden wird es sinnvoll primär vom lokalen Storage zu lesen und vom entfernten nur zu lesen wenn der lokale ausgefallen ist. > Ich wüsste allerdings nicht, wozu ich ein RAID1 mit SSSs brauche. Du nicht, andere schon. > Ich habe einfach ein simple 2TB WD NVMe-SSD mit PCIe 3.0, und die > 120GB, die ich da an Daten drauf habe habe ich in 6min auf eine > SATA Staging-SSD und von dort aus gehts dann gleichermaßen, aber > eben langsamer auf eine externe Platte. > Zweite SSD im RAID ist wirklich Overkill. Und wieviel wäre verloren wenn dir deine Haupt-SSD kurz dem Backuplauf auf die SATA-SSD aufgibt? Es gibt Leute bei denen das eine Menge verlorende Arbeit sein kann wenn es auch nur 1 Tag ist. Die wollen RAID. Gerrit
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2022-06-03 14:25 +0200 |
| Message-ID | <t7cuj5$7mr$1@dont-email.me> |
| In reply to | #556678 |
>> Natürlich geht es bei RAID1 auch darum, denn wenn ich z.B. 10MB >> lese, dann kommen 5MB von der einen Platte, 5MB von der anderen; >> nur geschrieben wird synchron. > Beides ist konfigurierbar. Sobald z.B. SOD involviert ist und über > längere Leitungen angebunden wird es sinnvoll primär vom lokalen Storage > zu lesen und vom entfernten nur zu lesen wenn der lokale ausgefallen ist. Halte ich für Unsinn, denn das synchrone Lesen anzuschalten bringt nix. Ich mein jede SSD hat ihre eigene Prüfsumme pro Block, da muss ich den Block nicht doppelt lesen. Fällt eine SSD aus, dann wird auf die Signatur der verbleibenden ge- schrieben, dass die jetzt ausm Verbund ist falls die teilweise lesbar wieder auftaucht. So ist das Ganze wasserdicht. Wer solch eine Option bietet ist entweder kein Fachmann, oder man bietet das eben an für Leute die keine Fachmänner sind und ein sicheres Gefühl haben wollen. > Du nicht, andere schon. Ja, um Geld auszugeben. Auf dem Desktop ist das Käse, denn selbst beim Video-Schnitt kommt die Verarbeitung bei einer einzelnen NVMe-SSD nicht mit. > Und wieviel wäre verloren wenn dir deine Haupt-SSD kurz dem Backuplauf > auf die SATA-SSD aufgibt? Das erfolgt automatisch danach, d.h. kaum was.
[toc] | [prev] | [next] | [standalone]
| From | Gerrit Heitsch <gerrit@laosinh.s.bawue.de> |
|---|---|
| Date | 2022-06-03 14:46 +0200 |
| Message-ID | <t7cvqa$fos$1@news.bawue.net> |
| In reply to | #556685 |
On 6/3/22 14:25, Bonita Montero wrote: >>> Natürlich geht es bei RAID1 auch darum, denn wenn ich z.B. 10MB >>> lese, dann kommen 5MB von der einen Platte, 5MB von der anderen; >>> nur geschrieben wird synchron. > >> Beides ist konfigurierbar. Sobald z.B. SOD involviert ist und über >> längere Leitungen angebunden wird es sinnvoll primär vom lokalen >> Storage zu lesen und vom entfernten nur zu lesen wenn der lokale >> ausgefallen ist. > > Halte ich für Unsinn, denn das synchrone Lesen anzuschalten bringt nix. > Ich mein jede SSD hat ihre eigene Prüfsumme pro Block, da muss ich den > Block nicht doppelt lesen. Braucht sie auch nicht. Aber es kann sinnvoll sein, wie oben beschrieben, immer nur von einer Seite des RAID1 zu lesen weil die schneller angebunden ist. Schreiben muss man natürlich auf beide. >> Du nicht, andere schon. > > Ja, um Geld auszugeben. Auf dem Desktop ist das Käse, denn selbst beim > Video-Schnitt kommt die Verarbeitung bei einer einzelnen NVMe-SSD nicht > mit. Es geht darum, daß bei einem Ausfall einer SSD wirklich keine Daten verlorengehen. Dazu brauchst du RAID1. Gerrit
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2022-06-03 14:54 +0200 |
| Message-ID | <t7d09e$kig$1@dont-email.me> |
| In reply to | #556692 |
> Braucht sie auch nicht. Aber es kann sinnvoll sein, wie oben > beschrieben, immer nur von einer Seite des RAID1 zu lesen weil die > schneller angebunden ist. Schreiben muss man natürlich auf beide. Was ist denn das für ein hahnebüchener Unsinn ? SOHO NVMe RAID 1 ist schon selten, aber wieso soll man denn so seltsam drauf sein, sein RAID1 asymmetrisch zu bestücken ? Erfindest Du gerade mal wieder deine Argumentation um deine vorherige posthum zu retten ? > Es geht darum, daß bei einem Ausfall einer SSD wirklich keine Daten > verlorengehen. Dazu brauchst du RAID1. Macht aber kaum einer. SSD-RAID1 im DB-Server beim Data Warehousing mag es geben. Sonst sicher fast gar nicht.
[toc] | [prev] | [next] | [standalone]
| From | Gerrit Heitsch <gerrit@laosinh.s.bawue.de> |
|---|---|
| Date | 2022-06-03 14:58 +0200 |
| Message-ID | <t7d0i1$fup$1@news.bawue.net> |
| In reply to | #556694 |
On 6/3/22 14:54, Bonita Montero wrote: >> Braucht sie auch nicht. Aber es kann sinnvoll sein, wie oben >> beschrieben, immer nur von einer Seite des RAID1 zu lesen weil die >> schneller angebunden ist. Schreiben muss man natürlich auf beide. > > Was ist denn das für ein hahnebüchener Unsinn ? > SOHO NVMe RAID 1 ist schon selten, aber wieso soll man denn so seltsam > drauf sein, sein RAID1 asymmetrisch zu bestücken ? Erfindest Du gerade > mal wieder deine Argumentation um deine vorherige posthum zu retten ? Nein. Ich hab solche RAIDs unter Solaris eingerichtig. Große Server deren Storage einmal im selben RZ stand und einmal in einem entfernten RZ. Angebunden via FC (auf Glasfaser) und zu einem RAID1 zusammengefaßt. Das waren so Storage-Schränke von EMC². Viele HDDs, später mit SSD als Cache. Auf deinem Desktop kannst du das mit einer NVMe-SSD und einer SATA-SSD machen. Zu einem RAID1 zusammenfassen und dann so konfigurieren, daß nur von der NVMe-SSD gelesen wird. Gerrit
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2022-06-03 15:02 +0200 |
| Message-ID | <t7d0or$ngn$1@dont-email.me> |
| In reply to | #556696 |
Am 03.06.2022 um 14:58 schrieb Gerrit Heitsch: > On 6/3/22 14:54, Bonita Montero wrote: >>> Braucht sie auch nicht. Aber es kann sinnvoll sein, wie oben >>> beschrieben, immer nur von einer Seite des RAID1 zu lesen weil die >>> schneller angebunden ist. Schreiben muss man natürlich auf beide. >> >> Was ist denn das für ein hahnebüchener Unsinn ? >> SOHO NVMe RAID 1 ist schon selten, aber wieso soll man denn so seltsam >> drauf sein, sein RAID1 asymmetrisch zu bestücken ? Erfindest Du gerade >> mal wieder deine Argumentation um deine vorherige posthum zu retten ? > > Nein. Ich hab solche RAIDs unter Solaris eingerichtig. Große Server > deren Storage einmal im selben RZ stand und einmal in einem entfernten > RZ. Angebunden via FC (auf Glasfaser) und zu einem RAID1 zusammengefaßt. Jaja, via NVMe, neeee ? Um mal beim Thema zu bleiben. Im übrigen liegen die Zugriffs-Zeiten von HDDs in einer Größenordnung, dass dagegen irgendwelch FC-und-Switching-Latenzen eher egal sinn, dass das dann eh nicht maßgeblich ist.
[toc] | [prev] | [next] | [standalone]
Page 4 of 7 — ← Prev page 1 2 3 [4] 5 6 7 Next page →
Back to top | Article view | ger.ct
csiph-web