Народ, поделитесь опытом.
Сегодня мне задали интересный вопрос и я оказывается никогда не думал в эту сторону.
Бэкап данных в Salesforce.
По этому запросу мне выдало вот такие замечательные страницы:
Exporting Backup Data
How to backup and restore your Salesforce data?
Deciding on A Method for Importing and Exporting Data
В общем все сводится к Data Export/Import в ручном и получусном режиме. Ну это как-то не серьезно. Я понимаю что Salesforce гарантирует сохранность данных но все-таки бизнес данные важнее всех обещаний.
Так вот народ хотел бы обратиться к вашему опыту, как на ваших проектах была организована работа с резервным копированием и восстановлением данных?
Я конечно склоняюсь к самописному решению с внемним сервисом куда данные периодически будут сливаться по API и восстанавливаться собственно с помощью хитрого скрипта по кастомному алгоритму.
А чего ты заморачиваешься. Есть специальные софтины которые по расписанию могут делать тебе бакап чего угодно. С восстановлением задача по сложнее, но тоже решаемо.
Самое простое что предлагает салесфорс это сделать бакап всей даты через визард. Решение чуть по сложнее s2s connection.
Да чуть не забыл. Эти глукавые индусы почему-то не додумались сделать поддержку кастом сеттингов ни в одном из своих визардов.
Сбэкапить это понятно, плевое дело. Слил визардом и радуйся что у тебя csv на руках.
А вот с восстановлением начинается жопа (понятно что если надо то решаемая)
Вот как заказчику объяснить - заказчик хочет простое решение - нажал кнопку -> получил бэкап орга ("всех" данных), нажал другую кнопку -> восстановил базу по состоянию на "такое-то" число.
На простых платформах эта тема изъезжена, к любой базе данных целый зоопарк решений.
Ну если с лукапами особенно возиться не нужно, то задача не очень сложная.
Решил поднять тему) Дима, у тебя что-нибудь получилось сделать? Сейчас встаёт вопрос о полном и ежедневном (только новые и изменённые записи) бекапе данных из SF в Amazon. Есть у кого-нибудь опыт такого use case?
Пока "красиво" не доводилось делать у клиентов.
Но если бы я делал, то замутил сервис класс, который можно использовать для sObject и дергал бы его из триггера на нужных объектах. Понятно что можно по желанию добавлять/убирать объекты которые необходимо синхронизировать.
А вот теперь самое интересное - что должен делать сервис класс. Он должен сериализировать объект добавлять какую нибудь служебную информацию и складывать все это дело в своеобразную очередь. А дальше замутить sсheduler который будет запускать по расписанию (раз в день или раз в минуту, кому как нравится) и отправлять очередь во внешнее хранилище. Или вообще замутить Webservice в который будет приходить внешний сервис и сам забирать данные из очереди. PROFIT 
Вариант с очередью собственно придуман затем чтобы не напрягать SF и внешнюю систему частыми запросами на каждый чих от DML операции.
Люблю я очереди очень (особенно на почте в дни расплаты по ЖКХ долгам )
Согласен, вариант с очередью очень хорош. Но это требует триггера на объекте. Вот бы как сделать что бы клиент мог ручками выбирать разные объекты для бекапа. Так же нужна логика по восстановлению данных, как bulk так и одной записи. Вопрос восстановления зависимых записей (лукапы) тоже открыт.
Видел как-то пакет, там был connected app (сама тулза вроде как на heroku висит), который подключался к API SF и ретривил данные (беда что API calls жрёт неимоверно). Но там была классная функция, на details page была кнопка, нажав на которую можно было видеть предыдущую версию записи и diff по филдам с возможностью полного или частичного восстановления.
На счет внешней системы - тут уже кто на что горазд.
Хотелось бы выслушать ваши мысли.
Я бы мутил на Python + Flask
После NA14 "зашевелилась" тема! :D
Всем привет, по поводу бэкапов и их востановления - на предыдущих проектах часто приходилось заниматься дописыавнием/допиливанием новой функциональности к уже используемым решениям и часто требованием заказчиков было использование для тестирования данных, которые ну прям настоящие, поэтому сталкивался с задачей сливания с их прода кучи связанных данных и заливания их на свой дев/тест орг. Для этого в большинстве случаев использовал софтину "Talend Open Studio for Data Integration".
Из преимуществ могу назвать огромный функционал (не ограничивающийся только работой с SF, бесплатность, кроссплатформенность и отсутствие лимитов по передаваемым данным). Хотя первое преимущество по начало пугает, т.к. сложновато разобраться, но потом понимаешь что это круто на самом деле (сделал такой вывод после того как я на практике сравнивал разные ETL тулы для работы с SF).
Я использовал Talend в ручном и полуавтоматическом режиме, хотя гугля информацию встречал статьи где люди описывали как они настраивали его для автоматической работы.
Из аналогов, которые я пробовал, могу перечислить:
- банально SF DataLoader (плюсы - бесплатно и "изкоробки", минусы - много "ручной" работы, играничения в 5 000 000 записей, платформа - Windows);
- SFXOrgData (плюсы - довольно удобный интуитивгый GUI, нет надобности ковыряться в структуре объектов, минусы - платное, бесплатная версия ограничена объёмом данных, всего 2 Мб, платформа - Windows/.NET Framework);
- Jitterbit (тоже платное решение, насколько я знаю сейчас принадлежит непосредственно Salesforce, для разработки скриптов миграции предоставляется студия, работающая под Windows, скрипты работают в клауде, много ограничений по форматам обрабатываемых данных и по их обработке);
- DreamFactory Monarch (платное решение, довольно удобное для целей которые мы ставили, но из-за платности выбрали не его, платформа - Windows).
Есть и другие решения (например, Pentaho Kettle), но я о них ничего сказать не могу.
В гитхабе Awesome Salesforce есть секция о ETL, но там всё то же, что я перечислил (собственно, я её туда и добавлял).
Также на текущем проекте заказчик выразил желание использовать для бэкапов сервис odaseva, но пока я о нём ничего сказать не могу.
Если речь идет о бээкапе, то пока проще выглядят специализированные решения от партнеров.
Как Дима уже упомянул, у большинства из них есть проблемы с непосредственным восстановлением данных, но какие-то типа OwnBackup поддерживают.
В любом случае, не стоит ожидать что восстановление будет таким же моментальным как с традиционными решениями, предоставляющими прямой доступ к БД. SFDC предоставляет доступ только через API как почти все другие SaaS Enterprise решения.
Вариант с ETL тоже возможен, но синхронизировать модели будет затратно, а делать полноценный compare и восстановление - тем более.
мне тоже Talend понравился, хотя пользовался им буквально один раз.
сделать бек-ап - это одно.
а вот "откатить" на "такое-то" число - гораздо сложнее, а главное, если даже сделать такую "кнопку" - ее никогда не нажмут, так как ее действие "затрет" все что было после дня или часа Х, а это никому не надо: обычно клиенту нужно любовно сохранить каждую Продовую запись...
Но можно предложить заказчику "живой" беккап - пусть купит full-copy sandbox и рефрешит его пару раз в месяц или с каждым приступом паранои или тревожности. думаю, это вполне может успокоить заказчика, что и требовалось доказать
Решение с full-copy sandbox теряет смысл бекапа так данные остаются в SF :)
А что из предложенных инструментов cloud tools? Просто хранить бекапы локально на компе/сервере тоже в наш век неприлично и требует локальных ресурсов, тот же сервер. Есть что-нибудь для бекапа в cloud databases например MS Azure или Amazon Redshift?
Если в фирме уже подключен через OData внешний ресурс (база данных), то проблему с резервным копирование данных можно решить если использовать следующую схему:
1) создаете во внешней Бд таблицы для объекто с филдами идентичными вашим в Salesforce
2) вешаете на объекты триггер который по экшенам (инсерт, дэлит, апдейт) делает запись в внешней БД и изменяет ее при изменении оригинальной запили
3) Для хисторикал дата можно написать батч - который сольет уже имеющиеся данные
Таким образом получаем слудующее:
- внешняя БД постоянно хранит актуальную информацию (если надо делать это по периодам времени - то можете создавать таймстап дополнительный который бы это позволял делать)
- простейшие триггеры на объектах
Каким образом потом востановить данные:
- это уже легко будет написать и на самом сале сделая для этого какую то пейджу и функционал который бы забирал с внешней БД записи (они доступны и в самом сале) и по выбранному тайм стампу апдейтить текущие записи.
Подытожим:
- вроде Profit - но слишком дорого для прода.
