Восстановление файловой помойки из резервной копий

Не расстраивайся, судя по схеме бэкапа и отсутствию скрипта для восстановления, твой предшественник был не меньшим дном.

Каким скриптом делалсь бекапы?

Написано же, sh )

Сама помойка должна остаться в неизменном виде.

Не совсем понятно, если файл есть, то из бэкапа не восстанавливать? А что вы хотите тогда получить? Восстановить все удалённые файлы? А критерий по нужности удалённых какой?

Ну при учете того что даты в пути есть, то пройти рекурсивно по ним и вернуть на место.

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

Спасибо за поддержку))

Имею ввиду что на выходе должна получиться еще одна папка с восстановленными документами, а помойка остаться в том же виде.

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

Тупой перебор будет выглядеть так:
1.Копируешь из любого $DUMPPLACE/$NOWYEAR/$NOWMONTH/$NOWDAY структуру, создаешь список всех файлов с полными путями (A).
2. Делаешь список директорий $DUMPPLACE/$NOWYEAR/$NOWMONTH/$NOWDAY.
3. В каждой директории из этого списка формируешь список структуры (N).
4. Каждую строку из списка N ищешь в списке A. Если файл новее, то перезаписываешь. Если файла нет, копируешь с полным путём.
5. Из полученного создаешь новый список (A+1), далее в 3 к списку N+1

Ну если по простому то как-то так:

#!/bin/bash

LEVEL=5
STARTDIR=/DUMPPLACE
OUTDIR=/restore

find_out=/tmp/find_out$$.txt
find "$STARTDIR" > $find_out
del=
for ((i=0; i<LEVEL; i++)); do
        del="$del*/"
done

while read f; do
        p=${f#$del}
        [[ $p = $f ]] && continue
        if [[ $f -nt $OUTDIR/$p ]]; then
                if [[ -d $f ]]; then
                        echo mkdir -p "$OUTDIR/$p"
                else
                        echo copy "$f" "$OUTDIR/$p"
                fi
        else
                echo skip "$p"
        fi
done < $find_out
rm $find_out

Где первые переменные надо сделать под вас. LEVEL - это количество '/' в полном пути из $DUMPPLACE/$NOWYEAR/$NOWMONTH/$NOWDAY/, то есть в том числе и в $DUMPPLACE. echo сами после теста первые два удалите.

Плохой вариант, оперировать нужно датами в пути, чего у вас нет.

Можно проще. Если даты в /$NOWYEAR/$NOWMONTH/$NOWDAY в нормальном (сортируемом) формате, то:
1. Не очень кошерно. Просто выхлоп на sort от старым в новым и обычным cp. Минус: в результате старые постепенно будут перезаписыватся новыми.
2. Кошерно. Наоборот от новых к старым. Только запустить cp с параметром -i и ему на вход что-то типа echo «n» |

Если даты «не правильные», например месяц пишется буквами или одной цифрой, то сначала получить список, преобразовать, а потом все тоже самое.

Плохой вариант, оперировать нужно датами в пути, чего у вас нет.

Зачем? Дата в пути - дата создания архива и нужна для ограничения восстановления по указанную дату. Я у ТСа спросил - нужно восстановить все удаленные? Раз так, то оперировать датой модификации вполне достаточно.

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

???Каким инструментом лучше поделить текстовый файл на строки?

Задумка следующая: find'ом получить файл со всеми папками куда сохранялись файлы из определенной папки. Дальше идти по полученному списку, построчно, циклом. Файлы, лежащие по адресу, коим является каждая отдельная строка, будут копироваться(пока так, в дальнейшем пропускаться если они уже есть и дата имеющегося файла старше копируемого). Каждая строка будет обрезаться до нужного мне адреса, после чего всё что скопировано будет копироваться по этому адресу. Это в общих чертах.

И сразу, чем отсортировать строки по человечьей логике где 02.13 идет после 02.11 ?

./2017/02/11_0200/all/Общие документы/СМЕТЧИК

./2017/02/21_1400/all/Общие документы/СМЕТЧИК

./2017/02/16_0200/all/Общие документы/СМЕТЧИК

./2017/02/21_0200/all/Общие документы/СМЕТЧИК

./2017/02/13_1400/all/Общие документы/СМЕТЧИК

./2017/02/20_1400/all/Общие документы/СМЕТЧИК

./2017/02/15_1400/all/Общие документы/СМЕТЧИК

([cut ] не работает что-ли?)

Хотя выводу файлы туда копируются.

Хех. Я же указал, что это тестовый скрипт, оно не копирует, а только выводит, и надо удалить первые два echo. И, чтобы даты сохранялись у файлов, желательно указать ключ -a у cp. (Ну и copy заменить на cp).

Спасибо огромное, это оно! Потихоньку :-/ врубаюсь.

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

ЗЫ Не в эту тему, но... если уж оперировать чисто датой с самой фс, то и rsync-ка достаточно.

И сразу, чем отсортировать строки по человечьей логике где 02.13 идет после 02.11 ?

Через строчку читаете? Я выше писал sort

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

Это противоречит самому принципу формирования того архива у ТСа — по модификации. :) То есть не важно, подправили ли дату модификации, мы сам архив имеем по этому критерию, а не другому.

оперировать чисто датой с самой фс, то и rsync-ка достаточно.

Эээ, кого с чем sync? У нас же куча инкрементальных бэкапов, а не два диска со старым и новым.

Это противоречит самому принципу формирования того архива у ТСа — по модификации. :)

Ничуть. Как раз там все правильно, в пути есть даты на которые как раз и стоит опираться. Кстати вполне кошерные

Эээ, кого с чем sync? У нас же куча инкрементальных бэкапов, а не два диска со старым и новым.

Я про ваш скрипт, пройтись рекурсивно и rsync на каждый каталог, не надо тогда проверок и всяких mkdir

Как раз там все правильно, в пути есть даты на которые как раз и стоит опираться. Кстати вполне кошерные

Да, если б не одно логическое следствие, что попало оно туда по причине изменения в плюс.

Я про ваш скрипт, пройтись рекурсивно и rsync на каждый каталог, не надо тогда проверок и всяких mkdir

Да полноте, это же из пушки по воробьям. Что вы имеете против mkdir? То что оно exec, а не syscall ? Ну да, но это какая-то натуральная экономия на спичках при разбрасывании брёвнами, скажем, на один изменнённый файл в день вызывать exec(rsync) даже если там всего-то и не файл, а скажем создали новый пустой каталог. :)

Да, если б не одно логическое следствие, что попало оно туда по причине изменения в плюс.

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

Да полноте, это же из пушки по воробьям....

Лаконичней в написании и как следствие меньше вероятность ошибки в скрипте.

Лаконичней в написании и как следствие меньше вероятность ошибки в скрипте.

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

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

Как к нему прикрутить фильтр по расширению файлов?

Если только нужные, то проще в find DIR -name '*.txt' засунуть, если кроме этих, то ${p%%.txt} будет отлично от $p если у имени на конце ".txt". Ну а далее — учите bash, попробуйте самостоятельно :)

Огромное благодарю за помощь и поддержку. Просто уж слишком резко понадобилось. Дальше сам :)