From nobody Sun Apr 17 10:42:48 2022 X-Original-To: freebsd-current@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 704F511DAEC2 for ; Sun, 17 Apr 2022 10:42:53 +0000 (UTC) (envelope-from grembo@freebsd.org) Received: from mail.evolve.de (mail.evolve.de [213.239.217.29]) (using TLSv1.3 with cipher TLS_CHACHA20_POLY1305_SHA256 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA512 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mail.evolve.de", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Kh68r3mvCz4mLn; Sun, 17 Apr 2022 10:42:52 +0000 (UTC) (envelope-from grembo@freebsd.org) Received: by mail.evolve.de (OpenSMTPD) with ESMTP id e996cce7; Sun, 17 Apr 2022 10:42:50 +0000 (UTC) Received: by mail.evolve.de (OpenSMTPD) with ESMTPSA id c310bdbd (TLSv1.3:AEAD-CHACHA20-POLY1305-SHA256:256:NO); Sun, 17 Apr 2022 10:42:49 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (1.0) Subject: Re: recover deleted file From: Michael Gmelin In-Reply-To: Date: Sun, 17 Apr 2022 12:42:48 +0200 Cc: Sami Halabi , FreeBSD Current Message-Id: References: To: Peter Jeremy X-Mailer: iPhone Mail (19D52) X-Rspamd-Queue-Id: 4Kh68r3mvCz4mLn X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=softfail (mx1.freebsd.org: 213.239.217.29 is neither permitted nor denied by domain of grembo@freebsd.org) smtp.mailfrom=grembo@freebsd.org X-Spamd-Result: default: False [1.40 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEFALL_USER(0.00)[grembo]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MV_CASE(0.50)[]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000]; R_SPF_SOFTFAIL(0.00)[~all:c]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_SPAM_SHORT(1.00)[1.000]; MLMMJ_DEST(0.00)[freebsd-current]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:213.239.192.0/18, country:DE]; FREEMAIL_CC(0.00)[gmail.com,freebsd.org]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N > On 17. Apr 2022, at 06:20, Peter Jeremy wrote: >=20 > =EF=BB=BFOn 2022-Apr-17 01:13:02 +0300, Sami Halabi w= rote: >> I understand its hard to undelete since no one designed UFS/ZFS to do so.= . >> that why I asked in later replies to see if someone would step in and >> implement such a "feature" and I suggested some directions/thoughts. >=20 > As you point out, neither UFS nor ZFS were designed to support an > "undelete" function: Once an inode has no references (open files > or directory entries), the inode and all associated data blocks are > returned to the free list and could be used by a subsequent allocation. >=20 > What semantics would you like UFS or ZFS to implement instead? Is it > just that the inode and associated data blocks should stay in limbo > for some period? If, what controls the period? What if a file is > truncated to 0 or overwritten before being unlinked? How much would > you be willing to pay for "undelete" functionality? >=20 >> As soren@ suggested in later reply it maybe would be easier to implement >> custom rm script that moves files to "Recycle bin" directory (and empty i= t >> after some period) >=20 > Alternatively, you could alias "rm" to "rm -i". >=20 >> but as a programmer I know that perfection is needed :) >> so It might start as a simple task and end in many what-if's >> (unfortunattly I did my last C programming in late 2003!). >=20 > This doesn't need to be C. You could do this in your scripting > language of choice. Or you could offer to pay someone to do this > for you. >=20 >> What amzes me is that this "feature" was asked too much in the last decad= e >> or two and no one ever implemented it, maybe it's not needed in daily >> usage, but in disasters it would be super userful, save admins many time >> and nerves.. >=20 > I went rummaging back through my mail archives and it actually doesn't > seem to come up that often. You seem to be about the 3rd person this > century on the lists I read. I did find a discussion in zfs-discuss > from May/June 2006 about supporting undelete but it seems that no > agreement on the desired behaviour was achieved. >=20 >> For now I did some backup tools locally and used chflags to mark them >> undeletable so I wouldn't do that mistake again, >=20 > You could also consider snapshots - both UFS and ZFS support snapshots. >=20 > If the information is very critical (you mentioned legal consequences) > then you might like to consider real-time replication of the MySQL redo > logs to another systems - though that won't necessarily protect you > from someone accidently doing a "DELETE FROM xxx;" or "DROP TABLE xxx; It will, if you keep the binary logs/replication logs around. Combined with r= egular zfs snapshots (on the replicant=E2=80=98s side) you can do a robust a= nd relatively speedy point in time recovery that prevents data loss (ideally= , access to the main db and the replicant is segregated). Saved me more than= once. Best Michael