Реально восстановить удалённые файлы?

Что, testdisk не смог? И никто отсюда не смог? И помнится, для ex4 даже был аналог undelete, но сходу не нашёл.

Попробуй, может повезет.

Перво-наперво размонтировать диск (особенно если он был системным), НИЧЕГО на него не писать. Сделать копию.

И с этой копией уже работать программами восстановления. Тут есть разные варианты, например, проприетарная R-Studio и свободная PhotoRec.

Вот имена файлов восстановить скорее всего не получится. А содержание - с большой вероятностью можно. Файлы были какого содержания (тексты, картинки, медиа, программы)?

Вот мы раньше шутили в таких случаях, что человека в гугле забанили, а скоро ведь реально забанить могут.

Ну или в RO перемонтировпть

SSD

Если успел отработать TRIM, то никак, вообще.

Думаю автор его не включал.

Он сам мог через тот же fstrim вызваться.

Для этого его надо сначала включить. Впрочем, дефолты наверно зависят от ОС. Я ведь давно не устанавливал даже дебиан с нуля на ссд, а по установленному 6-7 версией наверно судить не совсем актуально.

В некоторых дистрибутивах его systemd дёргает.

Для этого его надо сначала включить.

Он давно включается из cron/systemd.

Да, всё правильно, раньше в cron задание было.

Можно проверить командой systemctl status fstrim (у меня пишет inactive)

* fstrim.service - Discard unused blocks on filesystems from /etc/fstab
     Loaded: loaded (/lib/systemd/system/fstrim.service; static)
     Active: inactive (dead)
       Docs: man:fstrim(8)

Dimez

Можно проверить командой systemctl status fstrim

Нет, нужно проверить командой systemctl status fstrim.timer

Там еще и таймер сверху присобачен:

  systemctl status fstrim.timer
● fstrim.timer - Discard unused filesystem blocks once a week
     Loaded: loaded (/etc/systemd/system/fstrim.timer; enabled; preset: disabled)
     Active: active (waiting) since Sun 2026-10-04 20:06:48 MSK; 2 days ago
 Invocation: aa37cb4d4144473aacd849ceb916e5d2
    Trigger: Mon 2026-10-12 00:51:00 MSK; 5 days left
   Triggers: ● fstrim.service
       Docs: man:fstrim

Notice: journal has been rotated since unit was started, output may be incomplete.

● fstrim.timer - Discard unused blocks once a week
     Loaded: loaded (/lib/systemd/system/fstrim.timer; disabled; vendor preset: enabled)
     Active: inactive (dead)
    Trigger: n/a
   Triggers: ● fstrim.service
       Docs: man:fstrim

Как интересно, у меня disabled, vendor preset: enabled а у yars068 наоборот. Чтобы я его вручную отключал - не помню.

В /etc/systemd/system/ ничего про fstrim нет.

Да, потому что я его сам включил.

А ещё может быть опция монтирования discard

сам-то его пробовал? я про undelete . странное оно

testdisk - норм!

копию всего диска или раздела?

видео

если файлы на разделе то достаточно dd-копии раздела.
у тебя есть копия раздела со всем оставшимся мусором, в этом мусоре часто можно найти удаленные файлы, но не всегда.

Если он туда ничего не записывал, то файлы там точно есть. Если повезёт - не фрагментированные. Фрагментированные тоже можно восстановить, но возни больше.

Нефрагментированные ищутся так:

1) ищешь все блоки раздела, которые похожи на начало файла. Для mp4 это например буквы 'ftyp' в байтах 4..7, то есть читаешь каждый 4096-байтный блок, проверяешь в нём байты 4..7, если подходит то запоминаешь его;

2) от найденных блоков по порядку забираешь следующие сколько-то, например несколько мбайт, суёшь полученное в mpv - там будет хотя бы начало видео, по нему определяешь нужное оно или нет (все неудалённые видео с того же раздела тоже найдутся)

3) для тех видео, которые нужные, берёшь блоки по очереди сколько получится, проверяешь правильно ли они проигрываются в mpv, возможно получится забрать до конца файла и тогда всё норм

4) там, где восстанавливаемый файл кончается на серединие, придётся парсить структуры файловой системы (найти список незанятых блоков), и из этих блоков (исключив из него те, которые уже «нашлись») пытаться подобрать продолжение файла после обрыва (почти что перебором, ну или писать ещё mp4-парсер который будет автоматически проверять, подходит ли блок-кандидат в качестве продолжения).

если файлы на разделе то достаточно dd-копии раздела.

ок, понятно. т.е. dd раздела сделать, не всего диска? у мня на этом ssd ещё другие разделы с системой + ef00 и ef02. и по ошибке я fstrim раздела с системой сделал (но не того где файлы). есть смысл заморачиваться, или шансов мало?

за ссылку на арчвики спасибо

если потерянные файлы только на одном разделе, то тебе нужно полное содержимое только этого раздела, даже удаленные данные все равно остаются в пределах разметки раздела на носителе.
а с fstrim хз, по идее не влияет, но(!!) в ссд сколь знаю, для удобства перераспределения пространства добавляют слой абстракции адресов «носителя» и реальных аппаратных адресов… так что взаимодействие возможно…
еще можно вспомнить про такую красивую опцию монтирования как discard, которая разрешает драйверу/ядру посылать fstrim самостоятельно и чуть ли не постоянно без оглядок на всякие там сервисы.
но это можно мандражировать долго и упорно. просто скопируй раздел в образ - и все остальное до лампочки.

Уже много лет как банят. Когда много народу сидит с одного айпишника, гугл часто банил полностью или включал капчу на каждый запрос.

сам-то его пробовал? я про undelete . странное оно

Я пробовал. Восстановил достаточно большое количество удалённого. Другое дело, что это всё будут файлы с рандомными именами. Но валидным содержимым. И testdisk тебе тоже не даст имя файла, потому что после того, как ты сказал на файл rm, его имя исчезает безвовзратно, а вот содержимое ещё живёт физически, пока ОС не понадобится новое место. Потому что имя файла и соотвествующий ему inode хранится не в самом файле, а в директории, где этот файл лежит. Когда говоришь rm удаляется именно эта запись в каталоге. Так устроена ext4(возможно и не только эта ФС).

А данные-то где лежат? В /home? Раздел под хомяка отдельный, или всë на корне? Если второе, то всë, после fstrim выживших нет.

Никак./thread

Потому что имя файла и соотвествующий ему inode хранится не в самом файле, а в директории, где этот файл лежит

тащемта это называется «metadata» )))))) «meta» - это и означает «описание»

«meta» - это и означает «описание»

Вообще-то нет. Скорее что-то вроде «между» или «через» или в определённом смысле «сверх» или «над», но не в смысле превосходства, а в смысле более высокого уровня абстракции. Если не переводить, а описывать, то означает оно рекурсию, ну или самоподобие, фрактальность, если угодно. Метаданные — данные о данных; метатекст — текст о тексте; метанарратив — нарратив о нарративе; метагейм — «игра» на том, как устроена игра; метафизика чуть сложнее и в меньшей степени понятно современному человеку и тем более материалисту, но типа, физис типа природа, физика — дисциплина о природе, метафизика — соответственно дисциплина о природе природы. Ну и так далее.

P.S. Ещё «пере-» неплохо подходит в качестве перевода.

а вот содержимое ещё живёт физически, пока ОС не понадобится новое место

Не совсем так. «пока ОС не понадобится новое место» справедливо для HDD. В случае с ними да, просто метаданные удаляются, а само содержимое файла в смысле намагниченных областей на диске остаётся, просто в области, помеченной свободной, пока, соответственно, не перезапишется чем-то другшим («ОС не понадобится новое место»).

В случае с SSD это работает не совсем так. Да, непосредственно при rm происходит то же самое, удаляются метаданные, а область просто помечается свободной, но потом рано или поздно (и скорее рано, чем поздно, обычно от раза в сутки до раза в неделю по умолчанию) приходит fstrim и подтирает все свободные ячейки в нули. Ну или, если смонтировано с discard, то ячейки зануляются сразу же, а не по крону.

Поэтому в случае с SSD, надо как можно скорее отмонтировать раздел после такой фигни. Если сидеть с примонтированным, то даже если не было записи, против тебя работает время (причём даже если оно раз в неделю — вдруг оно сегодня? тут как повезёт). Перевод в read-only тоже не поможет. Ну это в случае, если не с discard примонтировано, конечно. Если с discard, то всё пропало сразу.

P.S. У меня оно каждый день, например:

 00  04  *   *   * /usr/bin/fstrim -A

Метаданные хранятся как раз в самом inode. Размер файла, права доступа, владелец и т.п.

нет и еще раз нет.
inode лежит отдельно от директории.
в inode как уже и сказали лежат метаданые файла. параметры файла: (даты, флаги) а также набор указателей на блоки и экстенты, в которых лежат данные файла.
https://linux-kernel-labs.github.io/refs/heads/master/labs/filesystems_part2.html#the-inode-structure
в директории лежит имя файла (в данной директории) и номер иноды с данными файла.
https://linux-kernel-labs.github.io/refs/heads/master/labs/filesystems_part2.html#dentry-structure

P.S. Ещё «пере-» неплохо подходит в качестве перевода.

Метаборщ

ну-ну. это ты первое значение описал. да ещё и не полностью. но у этого слова куча других значений, особенно как приставки.
в частности, имеется значения «вместе», «само себя» и «перечисление». по смыслу же применения - это именно «описание», «ПЕРЕЧИСЛЕНИЕ» «property».

https://azbyka.ru/otechnik/Spravochniki/bolshoj-drevnegrechesko-russkij-russko-drevnegrecheskij-slovar/12

поищи там μέτα

ну-ну. это ты первое значение описал.

Я описал кучу разных. Включая основное для приставки (а не отдельного слова).

но у этого слова куча других значений, особенно как приставки. в частности, имеется значения «вместе», «само себя» и «перечисление»

Это не разные значения, это разные костыли для перевода одного и того же смысла на язык, в котором конкретно такой же приставки не существует.

Но да, смысл есть не один.

по смыслу же применения - это именно «описание», «ПЕРЕЧИСЛЕНИЕ» «property».

Неверно.

поищи там μέτα

Ты б ещё на разговорник ссылку кинул…

inode лежит отдельно от директории.

В каком месте я говорил, что inode лежит в директории? Я сказал, что в дериктории лежит запись соответсвия имени файла и номера inode. Т.е. просто строка с именим и циферками.

в inode как уже и сказали лежат метаданые файла.

А вот это я написал в комменте, на который ты отвечаешь.

в директории лежит имя файла (в данной директории) и номер иноды с данными файла.

См. выше. Я это написал в самом первом своём коментарии.

Я бы scalpel посоветовал. Но с SSD скорее всего ничего не поможет.

На ssd с учётом trim - почти нереально.

Реально из бэкапа.

Да, я говорил в основном по hdd. С ssd и fstrim всё зависит от настроек. Я себе его на раз в неделю включал руками на компах с gentoo. В Debian оно по дефолту включено еженедельно через таймер.

Делай на другой диск образ диска, дальше testdisk в помощь: восстанавливает и имена файлов и содержимое.

Ещё режим инкогнито не любит

Если файлы были именно удалены, например, с помощью rm, никто имена не восстановит.

Да, я говорил в основном по hdd

Я так и понял.

Просто ТС указал именно SSD, поэтому я посчитал нужным дополнить. Иначе у тех, кто будет читать это позже, полюбому могло сложиться неверное впечатление — ведь вроде как контекст был типа про SSD.

из бэкапа

бэкап есть. некоторые скаченные видосы просрались. не знаю, что проще, выкачать по новой, найдя в истории браузера, или попробовать восстановить, учитывая что делал fstrim другого раздела на этом SSD, и не знаю, достаточно ли сделать dd копию нужного раздела, или надо всего диска? есть ли смысл потратить время?

fstrim другого раздела никак на ситуацию не влияет. И образы других разделов тоже никак не нужны.

не знаю, что проще, выкачать по новой, найдя в истории браузера

Имхо это проще