From nobody Fri Oct 11 07:12:01 2024 X-Original-To: questions@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4XPyVb28yPz5YPNr for ; Fri, 11 Oct 2024 07:12:07 +0000 (UTC) (envelope-from ralf-mardorf@riseup.net) Received: from mx0.riseup.net (mx0.riseup.net [198.252.153.6]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mx0.riseup.net", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4XPyVZ12XPz4h2h for ; Fri, 11 Oct 2024 07:12:06 +0000 (UTC) (envelope-from ralf-mardorf@riseup.net) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=riseup.net header.s=squak header.b=UoIyoQR5; spf=pass (mx1.freebsd.org: domain of ralf-mardorf@riseup.net designates 198.252.153.6 as permitted sender) smtp.mailfrom=ralf-mardorf@riseup.net; dmarc=pass (policy=none) header.from=riseup.net Received: from fews02-sea.riseup.net (fews02-sea-pn.riseup.net [10.0.1.112]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx0.riseup.net (Postfix) with ESMTPS id 4XPyVX5FBqz9sjZ for ; Fri, 11 Oct 2024 07:12:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak; t=1728630724; bh=WeX6vV8fgsjyUwSLan11BDLFE8lW7z12LQS4TtJHKbE=; h=Subject:From:To:Date:In-Reply-To:References:From; b=UoIyoQR5PEQmEhhrr515iMOmICWf0TizS5q/xPHUwvVlydvOSJWURQVssmZjFnudE 1vLuStJVMk1lEKRnALr32LGAVKj05t/yO87DayqIGwAIY2dpELxCAsRDlkxyd3Nvpx GkhJ52Jm6LXBRkaymLDp2q0KJVslXt6rV3yPxZWg= X-Riseup-User-ID: 8921A002837CE6D2FAA219944494EF75AA3D3B17F69805C2740CEEC0CCFCFD38 Received: from [127.0.0.1] (localhost [127.0.0.1]) by fews02-sea.riseup.net (Postfix) with ESMTPSA id 4XPyVX10M3zFtZt for ; Fri, 11 Oct 2024 07:12:03 +0000 (UTC) Message-ID: <0bd5d79d35bb036fc73cd226edae1b969b22e3ee.camel@riseup.net> Subject: Re: How to zero a failing disk drive before disposal? From: Ralf Mardorf To: questions@freebsd.org Date: Fri, 11 Oct 2024 09:12:01 +0200 In-Reply-To: <2544410a-8a99-4b2e-a194-c8326a2e0ddd@heuristicsystems.com.au> References: <5117.1728561469@segfault.tristatelogic.com> <2544410a-8a99-4b2e-a194-c8326a2e0ddd@heuristicsystems.com.au> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable List-Id: User questions List-Archive: https://lists.freebsd.org/archives/freebsd-questions List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-questions@freebsd.org Sender: owner-freebsd-questions@FreeBSD.org MIME-Version: 1.0 X-Spamd-Result: default: False [-4.30 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; DWL_DNSWL_LOW(-1.00)[riseup.net:dkim]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[riseup.net,none]; R_SPF_ALLOW(-0.20)[+a:mx0.riseup.net]; RWL_MAILSPIKE_VERYGOOD(-0.20)[198.252.153.6:from]; R_DKIM_ALLOW(-0.20)[riseup.net:s=squak]; RCVD_IN_DNSWL_LOW(-0.10)[198.252.153.6:from]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_ALL(0.00)[]; DKIM_TRACE(0.00)[riseup.net:+]; RCPT_COUNT_ONE(0.00)[1]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ASN(0.00)[asn:16652, ipnet:198.252.153.0/24, country:US]; TO_DN_NONE(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; MISSING_XM_UA(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[questions@freebsd.org]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[questions@freebsd.org]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+] X-Rspamd-Queue-Id: 4XPyVZ12XPz4h2h X-Spamd-Bar: ---- On Fri, 2024-10-11 at 13:42 +1100, Dewayne Geraghty wrote: > I worked for a provider of services for the statutory care of children > (eg removed from parents). [...] We bench-drilled the hard-disks > before sending them (out of our chain of custody) to a furnace. +1 > For personal devices we overwrite the device multiple times After countless discussions about [1] and having recovered and not recovered lost data myself, I am firmly convinced that it is sufficient for a private household to overwrite just 1 time. After that Joe and Jane Lunchbucket can't recover the data anymore and it's also quasi impossible for a geek to recover something. The problem with the Lunchbucket family's HDDs is that they only replace them when they are defective anyway. At best, you can free up stuck heads and be happy if you can get your 4 TB drive overwritten at all. In these cases, the question of how often you should overwrite does not even arise. It is not for nothing that it is said that you should mount a drive "read only" as soon as possible after data has been lost in order to have any chance of recovering anything at all. Criminals and secret services will think twice about whether it is worth subjecting the Lunchbucket family's hard drive to time-consuming and costly forensic treatment. [1] =E2=80=A2 rocketmouse@archlinux ~=20 $ man shred | grep -eiterations -eCAUTION -A1 -n, --iterations=3DN overwrite N times instead of the default (3) -- CAUTION: shred assumes the file system and hardware overwrite data i= n place. Although this is common, many platforms operate otherwise. Also,= backups and mirrors may contain unre=E2=80=90 movable copies that will let a shredded file be recovered later. Se= e the GNU coreutils manual for details.