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>
index | next in thread | previous in thread | raw e-mail
> On 17. Apr 2022, at 06:20, Peter Jeremy <peterj@freebsd.org> wrote: > > On 2022-Apr-17 01:13:02 +0300, Sami Halabi <sodynet1@gmail.com> wrote: >> 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. > > 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. > > 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? > >> 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 it >> after some period) > > Alternatively, you could alias "rm" to "rm -i". > >> 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!). > > 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. > >> What amzes me is that this "feature" was asked too much in the last decade >> 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.. > > 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. > >> For now I did some backup tools locally and used chflags to mark them >> undeletable so I wouldn't do that mistake again, > > You could also consider snapshots - both UFS and ZFS support snapshots. > > 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 regular zfs snapshots (on the replicant‘s side) you can do a robust and 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 Michaelhome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?DE5CD56E-6E8A-4A9A-9390-BC85C75F0C9E>