В функционал создания резервной копии добавить поле "Комментарий", чтобы при создании можно было оставить заметку что это за бекап. Бывает тестируешь какую-нибудь фичу и нужно сделать бекап перед её внедрением. Было бы круто иметь возможность прямо в админке оставить коммент что это за копия, например "Перед установкой модуля X..."  или "Перед импортом таких-то данных..." и т.д.

Сейчас подобные комментарии с именем бекапа приходиться хранить отдельно.  

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

Облачное хранение В2 Backblaze работает аналогично Amazon S3, но при этом стоит в разы дешевле. Отлично подойдет для резервного копирования.

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



Добавить возможность восстановления только базы данных.

Есть такой инструмент "Расписание резервирования" в CMS Bitrix, но там нет времени следующего запуска (при включенном автобэкапе)!  

TL;DR
Сухая вижимка предложений:

1. Сделать профили резервного копирования. Каждый со своей точечной настройкой
   
2. Упростить UI для страницы настроек. Сделать их более понятными, добавив описание.
   
3. Разработать возможность загрузки бекапа на внешний сервер по ftp/ssh.
   

Полный текст:

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

Я вижу несколько проблем в работе инструмента:
1) Невозможность бекапа на сторонние ftp/ssh средства.
Бекап можно положить в системную папку, в облако 1С-Битрикс и в облачное хранилище.
Хранить данные подключения ssh/ftp в Битриксе не безопасно? Круто, но почему-то для хранения учетки супер-пользователя Microsoft Exchange Вас это не останавливает.
2) Страница настроек бекапов слишком сложна.
Как сделать так, чтобы при создании бекапа, хранилось 2 копии и они загружались в облако после создания? Шаманство
3) Нужны профили резервного копирования.
Типовой кейс: предприятие среднего размера, но с большими бюджетами, все файлы в облачном хранилище
Необходимо делать:
- Ежемесячный полный бекап (для целостного восстановления и актуализации версии для разработчиков) - 1 бекап
- Еженедельный бекап портала без upload'а (хранить 2 актуальных копии)
- Ежедневную копию базы данных (хранить 3 последних дня)

Как решить типовой кейс штатными средствами? Никак. Только ssh, только tar+mysqldump (или же другие инструменты), только хардкор.
Ну окей, давайте упростим кейс и будем каждый день делать полный бекап. Думаете это решение проблемы? А вот и нет.
Давайте предположим, что мы храним на сервере 2 бекапа (при создании 3-го, первый будет удален и останется 2 бекапа). И вот у нас уже 2 бекапа, а нам нужно чтобы в текущий бекап больше не попадала папка, ну скажем temp. Заходим, вносим изменения и все. Через 3-4 дня (в зависимости от размеров бекапа и места) - сервер падает из-за недостака места, но почему? Мы ведь исключили папки. А все потому, что он начинает отчсчет заново, т.е. он сохраняет те 2 бекапа и считает что их снова 0. Таким образом можно увидеть что бекапов не 2, а 3-4-5-6-7 и т.п. А это проблема!

Местоположения до уровня улиц занимают очень большой объем. Бэкапить их в ежедневных резервных копиях необходимости никакой нет, а время выполнения бэкапа и восстановления из бэкапа из-за таблиц местоположений значительно увеличивается, а на маломощных виртуальных машинах иногда этот процесс становится вовсе невозможным.
Конечно, эта проблема решается другими средствами, но почему бы не добавить в параметры резервного копирования опцию "Исключить из базы данных местоположения" чтобы облегчить резервное копирование и восстановление стандартными средствами?

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

Хочу перейти в Битрикс 24 и максимально уйти от других инструментов, в первую очередь с Evernote (где экспорт данных есть и в тарифе free).
Платить 5 500 руб. за возможность, которая должна работать по умолчанию в таком серьезном инструменте, как Битрикс24, это не позволительная роскошь

p. s. Возможно установить ограничение на периодичность создания бэкапов в бесплатном тарифе, например раз в неделю.

Добрый день!

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

На наших Битрикс-проектах, мы достаточно часто им пользуемся, как и наши клиенты - перед объемными изменениями на сайтах. К сожалению, не всегда просто уследить за количеством этих резервных копий, что может приводить к переполнению хостинга. Это очень печалит. Добавьте, пожалуйста, возможность ограничивать количество резервных копий при ручном запуске.

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

Идея возникла из ТЗ одного из наших клиентов:
"Резервное копирование

Администратор должен иметь возможность создания резервной копии БД (далее РК). В момент создания РК, все остальные пользователи должны быть отключены от системы, для этого, перед созданием РК, реализовать проверку активных сессий и обеспечить возможность их принудительного отключения.

Администратор должен иметь возможность восстановления БД из резервной копии. В момент восстановления БД из РК, все остальные пользователи должны быть отключены от системы, для этого, перед восстановлением, реализовать проверку активных сессий и обеспечить возможность их принудительного отключения"

Признаться, меня удивило, что подобное не очевидно и не реализовано в настоящей версии.
ТП 1С-Битрикс предложили создать идею - создаю.

Резервное копирование может завершиться с ошибкой "Таблица b_xml_tree повреждена", если в этот момент идет обмен с 1С.

Надо добавить опцию, чтобы не делать копию таблицы. Или вообще не делать копию этой временной таблицы.

Предлагаю добавить настройку "дни недели" резервного копирования.  Выбрав эту настройку можно было бы указать по каким дням недели делается резервное копирование.

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

На данный момент у Битрикс24 есть:
- услуга по выгрузке бэкапа из облака для переноса в коробку;
- восстановление облака из резервной копии за определённую дату;
- услуга переименования портала (абв.битрикс24.ру в абв2.битрикс24.ру).

А вот услуги "скопировать весь портал абв.битрикс24.ру на абв2.битрикс24.ру" (с сохранением первого) - нет. А иногда может очень сильно пригодиться.

Кейс:

Предприятие с несколькими подразделениями продолжительное время и достаточно активно живёт в облачном Битрикс24. Соответственно накапливаются данные и история (переписка, Живая Лента, задачи, информация в группах и история сделок в CRM...).

В определённый момент предприятие разделяется на несколько отдельных, каждое из которых:
- хочет продолжать жить в облачном Битрикс24;
- имеет свой собственный бюджет (в том числе на Битрикс24, телефонию и т.д.);
- отдельную АТС;
- отдельный айти-отдел (администраторы, программисты);
- должно быть изолировано информационно (то есть, никакие пользователи одного предприятия, включая администраторов портала, не должны иметь доступа к информации "соседнего" предприятия);
- в рамках портала Битрикс24 иметь в своих руках полный контроль над настройками (то есть, административные привилегии);
- должно сохранить всю уже накопленную по своему направлению в рамках Битрикс24 историю и информацию;
- и сохранить всех своих пользователей (плюс остальных - для истории).

Это в рамках одного портала Битрикс24 реализовать невозможно, так как требования "иметь полный контроль" и "не иметь возможности доступа к данным соседей" взаимоисключающие.

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

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

Здравствуйте!

Хотел предложить несколько идей относительно резервного копирования:

1. Уведомления об успешном или неудачном бекапе по почте или СМС. Т.к. сейчас приходится каждое утро проверять вручную успешность выполнения резервного окпирования, что очень неудобно.
2. Создание резерных копий не только в облако и на сервер с системой Bitrix 24, но и на другой локальный сервер по FTP/sFTP или SMB. Хранить бекапы в облаке не позволяет политика безопасности компании, а размещать данные резервного копирования на том же сервере, что и сама система, как по мне, очень опрометчиво.

Очень досадно видеть у такой серьезной системы такие недочёты. Очень надеюсь, что исправите

Сейчас прогресс сохранения базы данных выводится так: "Сохранено таблиц: 10 из 100"

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

Предлагаю сделать параметр "Удалять локальные резервные копии" не radio, а checkbox.
Зачем нужно:
Если стоит опция "после успешной передачи в облако", то при проблемах с передачей в облако, архив остается лежать на сервере клиента. Через некоторое время забивается весь диск и сервер падает.

Проблему легко решить, если совместить условия:
Удалять локальные резервные копии
- после успешной передачи в облако
ИЛИ
- если общее число копий больше N