Date: Sun, 17 Apr 2022 14:13:07 +1000 From: Peter Jeremy <peterj@freebsd.org> To: Sami Halabi <sodynet1@gmail.com> Cc: FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: recover deleted file Message-ID: <YluT06ygFT8JeyZF@server.rulingia.com> In-Reply-To: <CAEW%2BogY_PeZs0AKn%2BUY4gDk8Q8XmNR%2BO5u3Yte9tncXh2fTnDQ@mail.gmail.com> References: <CAEW%2Boga0BNKZKsnAQWzEqMuUzUwAR293w0XLXM0YhQAsQiESyA@mail.gmail.com> <CANCZdfqNRD9G-q72mD2ZjUYPwnqwmLLzQeuopxZPdCOEyM=jxA@mail.gmail.com> <CAEW%2BogY_PeZs0AKn%2BUY4gDk8Q8XmNR%2BO5u3Yte9tncXh2fTnDQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--omXB7HJ7cySNH9NA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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 =66rom 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 =66rom someone accidently doing a "DELETE FROM xxx;" or "DROP TABLE xxx;" --=20 Peter Jeremy --omXB7HJ7cySNH9NA Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQKTBAEBCgB9FiEE7rKYbDBnHnTmXCJ+FqWXoOSiCzQFAmJbk8hfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEVF QjI5ODZDMzA2NzFFNzRFNjVDMjI3RTE2QTU5N0EwRTRBMjBCMzQACgkQFqWXoOSi CzS6Lw//RlB1FQSz5/4bt0Z82lMstg9nGtA9JbWTpS9fX1J0mfYQdFzpy0Zv2PIE 3eYGQfBQP1j9qPNgaAasSkW3xpppd/AkDaJvnw8qM4zA6CYesrT9jwjfMnH6p1wI CPVd9DtBZcDbxmSIY/dvFaUUNO8HouR0GR8vtjcihgtjNT/zQ4E93Hz+M0ut4CSz YjsVe5e9hB678JPFHZsynjLnxOlB2G4s8aKZ33KEmdGtTdg3cI5qDx1US68LwNpv VESnKU879F7kSa8j6tY6nRyA/BXH0Hw4g+bnyFf6Pg5Nzwsrf7Cj4LGBUjHpaXZj faXdJtV1y1dXggWrqqWlJ7sQcdQUEi6epnx4PPNlll5/ZwqejQAftbklD27HT3Nz LnCXR5YbVGsKQ0KV/VbHGddhCYx0cfvy0F3oukOIE+TjL8kj6R28++L2HqOond1M dECNHleTqzZDbYN1urgu1QDpVbkar9jzqO9DmWFJAuRzd9FAwCOC0QrtnsDdumyP dtErpdqr3O+t/YOdW40NwHDEdN5QbHgLxcmdAtUsKUl0Oqbb4YUiTaSU+kqTPCF4 VNr8NcU5iMw4LgVJM1B+jimLZB5zDTUo4/DcrGh/mOEC7VFcjRoKzuluqhtNaCdl B6crGesRwG4hwFVMdoohJ9sQWwbQShE7koK7nFPdMcScMZoN6/c= =EuXT -----END PGP SIGNATURE----- --omXB7HJ7cySNH9NA--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?YluT06ygFT8JeyZF>