> On 17. Apr 2022, at 06:20, Peter Jeremy <pet...@freebsd.org> wrote:
>
> On 2022-Apr-17 01:13:02 +0300, Sami Halabi <sodyn...@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
Michael
