Date: Sun, 17 Apr 2022 12:42:48 +0200 From: Michael Gmelin <grembo@freebsd.org> To: Peter Jeremy <peterj@freebsd.org> Cc: Sami Halabi <sodynet1@gmail.com>, FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: recover deleted file Message-ID: <DE5CD56E-6E8A-4A9A-9390-BC85C75F0C9E@freebsd.org> In-Reply-To: <YluT06ygFT8JeyZF@server.rulingia.com> References: <YluT06ygFT8JeyZF@server.rulingia.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> On 17. Apr 2022, at 06:20, Peter Jeremy <peterj@freebsd.org> wrote: >=20 > =EF=BB=BFOn 2022-Apr-17 01:13:02 +0300, Sami Halabi <sodynet1@gmail.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?DE5CD56E-6E8A-4A9A-9390-BC85C75F0C9E>