Кот МатроскинlLocust В БД сохраняется имя файла, дата, путь до него и еще какая-нибудь нужная информация.

А зачем БД-то вообще для этого? Прочитать каталог и отобрать нужные по маске данные - не то чтобы долгая операция на современном железе, даже без оракловых индексов. Сколько там этих файлов будет - 100 тыс, 200? Ерунда.

Основную проблему в схеме я вижу в нетранзакционности операции синхронизации файловой системы и БД -что может приводить к появлению мусора в базе.

а если люся все свои файлы называет 1.тхт, что будем делать?на фоне того что юморист петя свои файлы спецом называет 1(2).тхт :)

нормальная фишечка
файлы на винчестере, чтоб не сильно вешалась файловая система, в подпапках- первые 3 символа имени файла

имена - хеши.

таблица
idfile,filehash,orig_name,md5,date,.....

помещение в архив
1)insert into files ....
2)cp orig_name .../archive/sub_folder/filehash
3)!!! touch -m Для этого файла с датой, такойже как и в базе

периодически проверку делать
снимок из базы ввида snapshot.db и пропустить через sort
файл-имя md5

снимок из файловой системы в такомже виде - snapshot.fs(find | md5sum |sort )

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

ну а потом пару плясок с бубном(шел утилиты)

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

а вот мусор позложнее..надо сначала из этих списков срезать мд5суму, оставив только имя(sed)
и найти те имена что встречаються на шдд но нету в базе - это мусор - удалять.

ну а выбрать уже можно будет по всему что в базу напихаете, хоть по значению последнего байта в файле.