Евгений Хлебников, то есть, в общем виде Вы предлагаете вместе с дампом БД сохранять срез списка актуальных объектов с номерами ревизий (не важно в какой форме - прямо в дампе БД или отдельно) и при восстановлении пробегаться по этому списку, восстанавливать объекты/ревизии, которые в нем указаны и удалять все объекты, которые в списке не указаны?
А сама эта процедура (особенно поиск отсутвтвующих в списке объектов) не является слишком ресурсоемкой? Мы ведь снова приходим к ситуации, когда нам надо пробежаться по всему списку объектов в хранилище, чтобы найти отсутвтвующие в нашем срезе.
Евгений Хлебников, а зачем?
Moodle никогда не меняет файлы, более того, у него есть собственный механизм дедубликации и перед записью в хранилище, файл переименовывается в md5 от своего содержимого (а все ссылки и используемые в контенте имена файлов хранятся в БД). Поэтому, если системе нужен объект из хранилища с определенным именем и такой объект в хранилище есть - то совершенно точно это тот объект, который нам нужен.
Ну или я не очень понял вашу идею, что там может произойти с файлом, да еще и не отразитсья в его версии?
Евгений Хлебников, да, описанный Вами скрипт - это первый вариант, который я рассматривал. Данные из приложения для него, по сути, и не нужны - вся необходимая информация о датах существования объектов и так есть в S3. Сам скрипт на питоне получается строк на 20 и написать него не проблема. Смущает именно то, что в том же s3cmd, minio-mc и т.п. нет готовой команды для этого. Нет готовых популярных утилит (хотя их просто написать, они получаются достаточно универсальными для данной задачи). Именно это и вызывает сомнения, потому что я привык исходить из предположения, что "если в Черногории не продается черный хлеб, так это потому что он там никому не нужен, а не потому что ты - единственный гений, кто придумал такой шикарный бизнес-план" :)
Да, полученные ответы и комментарии укрепили меня в мысли, что приложение, хранящее статический контент в S3 - не типовая история. Настолько не типовая, что большинство комментаторов даже не сразу понимают, что я хочу хранить в S3 не бекапы, а рабочие экземпляры данных.
Но мне остается не понятным - почему?
Схема "база + файлы" - это типовой паттерн. Так работает не только Moodle, но и большинство веб-приложений, которые я видел. При перемещении приложения в облако, вся архитектура Docker Swarm или K8S кричит нам: не храни файлы локально. А S3, вроде бы, специально создан для такого применения (хранить статические, не изменяемые файлы, которые приложение изредка добавляет, часто запрашивает только для того, чтобы сразу же отдать клиенту по http и никогда не изменяет). Но если бы это было так, то было бы и готовое решение для консистентного бекапа. Но его нет. Значит никто S3 не применяет для такой задачи. Не понятно только почему.
Из Вашего ответа выходит, что правильный паттерн - поправить драйвер s3 в приложении так, чтобы при извлечении он не обращал внимания на статус удаления, а если приложение запросило файл, просто извлекать его, не зависимо от статуса. Плюс написать сборщик мусора, который окончательно удаляет файлы, которые были удалены больше месяца назад (к примеру).
Это хоть и требует большой работы, но хотя бы выглядит логичным решением.
Однако, все-равно странно, почему при наличии такого большого количества унаследованных приложений (практически любые веб-приложения - ownCloud, Redmine, Drupal, Moodle, Bitrix, osTicket, Mediawiki - да вообще что ни возьми), хранят файлы таким образом. И многие умеют класть их в S3. Казалось бы, давно должно быть готовое и универсальное решение, которое позволяло бы не переписывать драйверы и не колхозить скрипт бекапа.
rPman,
> вы храните только все что относится к moodle?а операционная система и другой софт? его дети не ломают?
Это проблема других людей :) Я занимаюсь только веб-приложениями
> p.s. сущность целиком можно было бы хранить в инкрементальных бакапах файловой системы, особенно если у вас есть возможность сервер баз данных останавливать на время бакапа (точнее создания снапшота - это секунды)
Для варианта, когда файлы хранятся в файловой системе эта задача давно решена. И для нее есть удобные решения. Можно хранить бекапы хоть локально, хоть в s3, хоть в специальном сервере бекапов, доступном по REST.
Но если мигрировать на S3, чтобы там лежали не бекапы, а сами файлы приложения (это нужно, например, если мы хотим кластеризовать наше приложение или если у нас облачный хостинг, где хостятся тысячи независимых экземпляров приложений с горячим резервированием и автоматической миграцией), то встает вопрос, как консистентно бекапировать и восстанавливать бакеты s3. Как я написал выше, я нашел 3 решения, но все они в равной степени неудобные и костыльные. И вопрос не в том, как это можно было бы сделать вообще, а в том, почему для этого нет готовых решений: неужели никто не хранит в s3 сами данные приложения (не бекапы, а именно рабочие копии) и не сталкивается с задачей резервного копирования не от общего сбоя хранения, а от порчи данных в отдельном экземпляре приложения.
Для понимания масштаба - один экземпляр Moodle среднего университета может запросто содержать террабайт данных, разбросанным по файлам, размером от пары килобайт до нескольких гигабайт. На этих масштабах "просто выкачать все файлы локально, чтобы потом сбекапить" выглядит довольно дорогостоящей и длительной операцией. А если каждый экземпляр нужно бекапить минимум ежедневно и хранить копии хотя бы за неделю, а лучше за месяц, то это становится вообще не реалистично.
Вариант, откатить единовременно все данные всех экземпляров, восстановив файлы сервера s3 из резервной копии тоже не годится, потому что редко когда бывает нужно восстановить больше одного экземпляра за раз.
Поэтому единственный жизнеспособный вариант - это либо инкрементно бекапить один бакет в другой, с дедубликацией и скачиванием только изменений, либо положиться на версионирования самих Bucket, с откатом на нужную дату. Но ни для того, ни для другого нет готовых решений и на это, очевидно, есть веская причина (раз задача есть, а стандартного решения нет). Вот эту причину я и пытаюсь понять.
Да, Вы правы, но этот вариант годится только если у нас отдельный экземпляр Minio для каждого экземпляра приложения. Если S3 предоставляется как сервис облачным провайдером, который дает интерфейс только для создания новых пользователей с квотами, а работа с бакетами выполняется по протоколу s3, то воспользоваться бекапом самого сервера S3 не выйдет. Тем более, что каждый бакет привязан к отдельному приложению и его может понадобится откатить отдельно от остальных бакетов.
ky0, так у меня в бакетах не бекапы и не одиночный объекты. Там файлы одной инсталляции Moodle (грубо, это все файлы, которые загружены преподавателями и учителями в среду электронного обучения). Каждый файл - это отдельный объект. Консистентный набор данных включает в себя дамп SQL и весь набор загруженных в систему файлов сразу.
Например, преподаватель создает учебный материал и крепит к нему 3 картинки. Текст и параметры материала пойдут в SQL, а картинки в бакет (каждая - как отдельный объект).
Соответственно, мне нужно не один объект откатить, мне нужно чтобы бакет содержал ровно те объекты, о наличии которых "помнит" sql-дамп - ни одним файлом больше и ни одним файлом меньше.
Такая архитектура - это данность. Чтобы докеризировать это приложение, один из вариантов - переместить файлы из локального хранилища в бакет, но для этого надо решить проблему с бекапами. Ну либо не перемещать хранилище в бакет, а использовать тот же CephFS или NFS, но S3 выглядит привлекательным вариантом.
Неужели это такая не типичная задача? Казалось бы, любое приложение (сайт, crm и т.п.) которое хранит данные в S3 хранит не одтельные объекты, а сразу набор таких объектов и при восстановлении из бекапа надо восстановить не просто один объект, а весь их набор. Или нет?
ky0, да, я накопал три варианта:
1. Написать скрипт, который, опираясь на штатное версионирование s3 откатит состояние бакета на нужную дату.
2. Монтировать бакет с помощь того же rclone в качестве раздела, а потом бекапировать этот раздел тем же самым restic.
3. Выкачать Bucket с помощью rclone, а потом сбекапить его через Restic или Borg
Они описаны в исходном вопросе.
Но все эти варианты выглядят костыльно и инородно. Это наводит на подозрение, что сама постановка задачи неверная. Иначе бы в Restic просто была бы опция "сбекапить Bucket напрямую из источника" (без примонтирования его к файловой системе, что для S3 само по себе не стандартное применение). Или в api S3 была бы не только команда "включить версионирование", но и "восстановить состояние Бакета на заданную дату". Но раз таких опций нет, значит это не типовая задача, что кажется мне странным.
Собственно, об этом и был вопрос
rPman, p.s. посмотрел ссылку - там та самая опция версионирования, которую я смотрел первой. Но вот для отката на предыдущий момент времени я не нашел никаких готовых решений, кроме как колхозить скрипт на питоне, который будет перебирать версии и давать команды на восстановление или удаление. Это меня и смущает: раз нет готовой команды, значит что-то я планирую использовать не так, как задумано разработчиками s3
rPman, какого, AWS?
В рамках стандарта S3 я нашел только возможность включить версионирование, но возможности сделать слепки или просто откатить состояние бакета на дату не видел. По крайней мере через консольные утилиты, такие как s3cmd и т.п.
Возможно эта опция есть в недрах веб-интерфейса AWS, но это не удобно (бекапы надо делать по крону) и не у всех "родной* AWS.
Я рассматриваю вот такой пример:
есть среда электронного обучения Moodle, каждый экземпляр системы имеет свою базу данных (MySQL или postgresql) и свой набор статических файлов (картинки, видео, загруженные в систему документы). Чтобы откатить состояние системы на прошлую дату (например, отменить неудачное обновление или если ученики подсмотрели пароль преподавателя и устроили вандализм в его курсах), нам нужно восстановить базу из дампа и вернуть файлы из бекапа.
Система умеет хранить файлы в S3, но встаёт вопрос, как решать задачу с бекапами и откатами, причем автоматизировано (то есть, чтобы бекап выполнялся скриптом по крону).
Заходить в админку AWS и делать бекапы и восстановление не вариант, тем более, если у нас не AWS, а какой-нибудь Minio или Ceph, поднятый провайдером хостинга, где мы получаем только реквизиты пользователя с правом создавать бакеты через api. Добавлять в скрипт бекапа команду, которая бы приказывала бы AWS сделать бекап бакета - тоже такое себе, если эта команда не входит в стандарт S3 и не поддерживается утилитами, такими как s3cmd или даже штатной от Амазона.
В общем, как не крути, везде получается много самописного кода, по сравнению с хранением файлов на диске. Это настолько экзотическая задача, что так и не возникло универсальных решений?
Everything_is_bad, потому что почтовые порты часто закрывают, чтобы вирусы не рассылали спам, а https закрыть - равноценно совсем пользователей без сети оставить. Поэтому проще протокол сменить, чем каждый раз все пользователи будут со служебками на поклон к адмсну бегать, чтобы порты открыл. Не все внедрения проходят сверху, бывает так, что на удобство пользователей всем плевать и они сами находят себе софт, а потом пробивают через бюрократию себе возможность им пользоваться.
Василий Банников, так мне и не требуется децентрализованное, нужно только чтобы там, где админ порезал все, кроме https оно работало. Потому что там, где порезал ещё и https это приложение все-равно не пригодится.
Производительность и оперативность тоже не особо нужны в моей задаче.
По сути, можно было бы написать свой асинхронный сервер и клиент, который по rest тянет сообщения с сервера и отправляет ответы, но жаль времени на весь этот стандартный транспорт тратить.
Даня Джен, так проблема с авторизацией по ключам?
Они периодически меняют настройки ключей, чтобы закрыть доступ слабым ключам. Например, не так давно были заблокированы все ключи dsa. Рекомендуют пользоваться rsa достаточной длины. Если авторизация по ключу не работает, проверьте, какой у вас ключ.
Это можно настроить в /etc/ssh/sshd_config, но лучше сделать нормальный ключ.
У ssh есть опция -v, которая отображает детали поключения для отладки.
По ссылке, похоже, проблема в правах доступа на файл.
Boris Korobkov, ну там не пара строчек получается, надо работать с вложенностью, обрабатывать ситуации отсутствия данных в источнике, добавлять разные правила для простановки констант, пересчетов, рекурсивного изменения структуры и пр. Прорабатывать кидаемые исключения, писать примеры, документацию, покрывать автоматическими тестами. Это получается отдельный проект, который нужно писать и поддерживать.
Я, конечно, написал свою простенькую библиотеку на самые первоочередные задачи, но хочется нормальный инструмент.
Вопрос же не в том, как это реализовать, а в том, чтобы найти готовую библиотеку, на вход которой можно было бы подавать правила вида:
$rules[]=array('cmd'=>copy,'source'=>'contacts/email','destinee'=>'email');
и не писать свой велосипед, если есть готовое :)
АртемЪ, похоже. Мы с Вами друг-друга не понимаем.
Поле "integer" от страны не зависит.
То, что есть справочник, с некоторым количеством полей, часть из которых нужно отобразить в списке, включив по ним поиск и сортировку, а другую часть - на странице отображения, которая видна пользователям с такой-то ролью и т.п. тоже мало зависит от "местных условий".
Я спрашивал, есть ли другие приложения, в которых можно делать то же самое. Желательно OpenSource.
Я не спрашивал про бухучет.
Стандарты документооборота и бизнес-процессов я привел в качестве примера абстрактных стандартов, которые задают не саму бизнес-логику, а правила ее описания.
