Облачное хранилище для отчётов и бэкапов (Яндекс.Диск/WebDAV/S3) без установки сторонних клиентов

Здравствуйте! Хочу попросить добавить в ЛЭРС экспорт отчётов и резервных копий в облако напрямую из ЛЭРС, без установки на сервер клиента Яндекс.Диска и без промежуточной синхронизации.

Почему прошу:

  1. Отчёты и бэкапы накапливаются и занимают диск сервера → риск, что сервер/службы начнут падать из-за нехватки места.
  2. Бэкап должен храниться в другом месте, иначе при сбое/вирусе/переустановке он теряется вместе с сервером.
  3. Не хочется ставить и обслуживать клиент Яндекс.Диска на сервере (обновления/зависания/синхронизация/права).

Как вижу реализацию:

  • добавить “Назначение хранения” = Облачное хранилище
  • варианты:
    • WebDAV (и сделать пресет для Яндекс.Диска)
    • или S3-совместимое (универсально для разных облаков)
  • выгрузка через фоновую очередь: “создали файл → загрузили → отметили успех”
  • настройки: путь в облаке, расписание/триггер, удаление локально после успешной загрузки, ретеншн (N дней), лимит места/файлов
  • логирование и статусы (успешно/ошибка/повтор)

Важно: именно “прямая отправка”, как с почтой: один раз настроил доступ (токен/ключ), дальше ЛЭРС сам выгружает.

Резервное копирование в ЛЭРС - это “аварийный” механизм в случае если его не получается настроить через другие механизмы, специализированные для БД. И, например, с Postgres наш внутренний механизм пока не работает. Кроме того в общем случае, когда сервер ЛЭРС и сервер БД находятся на разных компьютерах, ЛЭРС в принципе не имеет доступа к созданной резервной копии, и никуда загрузить её не сможет.

Поэтому получится сложный в реализации, но очень куцый механизм с кучей ограничений.

Тут точно можем порекомендовать создавать резервные копии через сторонние механизмы. Для SQL Server есть встроенный механизм резервного копирования на S3.

Для postgres есть сторонние решения по резервному копированию, которые так же поддерживают s3. Например, postgresus.

Исходя из ваших задач я вижу, что лучше использовать не яндекс-диск и webdav, а специализирование объектное хранилище с интерфейсом S3. Yandex Cloud такое хранилище точно предоставляет, и политики retention, storage limits, lifecycle можно настроить там. Это не задача ЛЭРС, этим должно заниматься само хранилище.

Вот по поводу экспорта отчётов хочется остановится подробнее. Если я правильно понял, вы автоматически формируете отчёты и храните их в папке на сервере, верно? И вы хотите сохранять их в объектном хранилище, таком как S3? Если так, то это как раз и должно быть реализовано у нас, в ЛЭРС.

Спасибо за ответ :raising_hands:
Про бэкапы БД поняла — это отдельная история, будем решать штатными средствами СУБД.

Но наш основной запрос был именно про отчёты ЛЭРС :slightly_smiling_face:

Хочется, чтобы ЛЭРС умел выгружать сформированные отчёты прямо в Яндекс.Диск, без установки клиента Яндекс.Диска на сервер и без схемы “локальная папка → синхронизация → облако”. Сейчас отчёты копятся на диске сервера, место постепенно съедается, а поддерживать клиент синхронизации на сервере не хочется (обновления/зависания/права/конфликты).

Как вижу реализацию — достаточно даже простого варианта:

  • в экспорте отчётов добавить “Назначение хранения: Облачное
  • вариант подключения: WebDAV (с готовым пресетом под Яндекс.Диск)
    • https://webdav.yandex.ru
    • логин + пароль приложения/токен
    • путь в облаке типа /Отчеты/2026/Февраль/...

И очень хотелось бы пару опций:

  • загрузка в фоне с очередью/повторами и понятными статусами (успех/ошибка)
  • удалять локально после успешной загрузки”, чтобы сервер не забивался

Скажите, пожалуйста, реально ли рассмотреть именно выгрузку отчётов в Яндекс.Диск по WebDAV как официальный способ? Нам даже WebDAV хватит, главное — чтобы это было “настроила один раз и забыла”, а ЛЭРС сам всё складывал в облако.

Почему вы рассматриваете именно яндекс.диск, а не более подходящее и гибкое объектное хранилище? Это полноценный интерфейс с политиками, а не просто папка, где могут храниться файлы.

Это не опция, это единственный нормальный способ работать с хранилищами. Однако, на первом этапе интерфейса для просмотра этой очереди не будет, она будет обрабатываться сервером автоматически.

Я, может, чего-то в задаче не до конца понял? Я вижу сценарий следующий.

Есть задание автоматического формирования отчёта, результат которого сейчас вы сохраняете в папку на диске сервера.

После реализации объектного хранилища появится ещё один пункт - сохранять в объектном хранилище. Там вы выбираете заранее настроенное хранилище.

Далее есть два варианта. Если файл сохраняется и на сервере и в хранилище, он пишется на диск и в фоне загружается в облако. После этого файл не удаляется.

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

Я не вижу зачем здесь нужна какая-то настройка. Может, что-то не так понял?

Объектное хранилище действительно “правильнее” технически.

Мы смотрим именно Яндекс.Диск по очень приземлённой причине: у нас вся операционка уже живёт в Яндекс 360/Диске (папки по годам/месяцам, доступы сотрудникам, быстрые ссылки клиентам/УК, просмотр/скачивание “как папка” без отдельного ПО). Отчёты — это не только “где хранить”, это ещё как ими пользуются: открыли папку → нашли PDF/Excel → отправили ссылку/скачали. Для этого Диск идеально ложится и не требует отдельной админки/инструментов/обучения.

S3 для нас сейчас:

  • сложнее в доступе для не-IT (это уже не “папка”, нужен интерфейс/права/инструменты),
  • отдельные процессы/регламенты, иногда отдельный аккаунт/биллинг,
  • и по функционалу хранения для отчётов часто “оверкилл”.

При этом мы не против S3 вообще — если у вас уже в планах “S3-совместимое хранилище” как универсальный вариант, это ок. Просто очень хочется, чтобы был ещё человеческий вариант “папкой” — например:

  • либо пресет WebDAV для Яндекс.Диска (как самый простой “папочный” кейс),
  • либо хотя бы понятный “S3-совместимый” + рекомендация “для папочного доступа используйте Яндекс.Диск/аналог”.

Наша цель простая: ЛЭРС сформировал отчёт → сразу выгрузил в облако → локально не копим, и чтобы этим могли пользоваться обычные сотрудники без плясок :slightly_smiling_face:

да, вы сценарий в целом правильно поняли :slightly_smiling_face: Спасибо, что расписали логику