Да, встроенный бэкап - Гавно! И именно с большой буквы! У меня каждое восстановление восстанавливает по разному. Одно - не все заказы, второе - забыл макеты, третье - доставка рухнула и т.д.
Хорошо бы, разработчики обратили внимание на эту критику... Получается, что функционал бэкапа в движке есть, но пользоваться им просто опасно.
После таких бэкапов приходится обращаться в ТП и платить кредитами, а это не есть хорошо.
Вот бы услышать комментарий представителя разработчиков относительно этой претензии.
Получается, что функционал бэкапа в движке есть, но пользоваться им просто опасно.
Встроенный бэкап и обновления - это функционал с генератором случайного результата. Может получится, может нет, может с первого раза, может с третьего.
Я заметил, что при восстановлении БД размером около 22Мб, таблицы какие успеют восстановится, те и будут. Причем кол-во таблиц при каждом восстановлении - разное. Ну чем не функционал с генератором случайного результата?
Встроенный бэкап и обновления - это функционал с генератором случайного результата. Может получится, может нет, может с первого раза, может с третьего.
Я заметил, что при восстановлении БД размером около 22Мб, таблицы какие успеют восстановится, те и будут. Причем кол-во таблиц при каждом восстановлении - разное. Ну чем не функционал с генератором случайного результата?
База в сто с лишним мегабайт. Вы посмотрите на настройки сервера, php и mysql - раз у вас так срабатывает. Я вас скажу, почему делаю три бэкапа - из phpmyadmin, supexdumper и встроенный бэкап. потому как supexdumper работает быстро, phpmyadmin я полностью настраиваю процесс и контролирую... но пару раз было что обратно и там и там у меня процесс восстановления зависал из за коллизий в самих таблицах (типа задвоения записей или ключей, потом вручную выискивал) - так вот в этом случае именно встроенный бэкап вставал на место без каких либо проблем и спасал меня от краха :)
База в сто с лишним мегабайт. Вы посмотрите на настройки сервера, php и mysql - раз у вас так срабатывает. Я вас скажу, почему делаю три бэкапа - из phpmyadmin, supexdumper и встроенный бэкап. потому как supexdumper работает быстро, phpmyadmin я полностью настраиваю процесс и контролирую... но пару раз было что обратно и там и там у меня процесс восстановления зависал из за коллизий в самих таблицах (типа задвоения записей или ключей, потом вручную выискивал) - так вот в этом случае именно встроенный бэкап вставал на место без каких либо проблем и спасал меня от краха :)
Я, конечно, не программист, но уверен, что в процесс бэкапа штатными средствами можно и нужно встроить процесс проверки До/После. Т.е. сверять то, что фактически в базе с тем, что вошло в резервную копию и то же самое при восстановлении из резервной копии и в зависимости от результата предложить переделать копию/перезалить бэкап.
Как-то так... Иначе какой смысл в процессе, результат которого никто не может гарантировать?...
Я, конечно, не программист, но уверен, что в процесс бэкапа штатными средствами можно и нужно встроить процесс проверки До/После. Т.е. сверять то, что фактически в базе с тем, что вошло в резервную копию и то же самое при восстановлении из резервной копии и в зависимости от результата предложить переделать копию/перезалить бэкап.
Как-то так... Иначе какой смысл в процессе, результат которого никто не может гарантировать?...
смысл встроенного бэкапа - создать полную копию бд (по желанию с файловой системой) и в случае непредвиденных результатов откатиться обратно: drop table - cteate table - insert, то есть очистить базу и залить в нее данные из бэкапа, что логично и достаточно. То, что вы хотите, конечно круто... Но это отдельный инструмент, сам по себе полагаю такой аддон будет в разработке по объему и стоимости мало отличим от движка магазина ))
смысл встроенного бэкапа - создать полную копию бд (по желанию с файловой системой) и в случае непредвиденных результатов откатиться обратно: drop table - cteate table - insert, то есть очистить базу и залить в нее данные из бэкапа, что логично и достаточно. То, что вы хотите, конечно круто... Но это отдельный инструмент, сам по себе полагаю такой аддон будет в разработке по объему и стоимости мало отличим от движка магазина ))
На самом деле почти любая индивидуальная разработка для CS-CART соизмерима по стоимости со стоимостью движка... А вот "допиливание" такого функционала докинуло бы нехилый плюс в карму разработчикам.... Ну и инструмент такого уровня был бы серьезным конкурентным преимуществом.
сверять то, что фактически в базе с тем, что вошло в резервную копию
скачиваете файл бэкапа до и файл бэкапа после, любая программа сравнения файлов покажет различия. Даже Тотал Коммандер (Файл - Сравнить по содержимому). Или WinMerge
В linux с этим ещё проще и красивее - Meld например
скачиваете файл бэкапа до и файл бэкапа после, любая программа сравнения файлов покажет различия. Даже Тотал Коммандер (Файл - Сравнить по содержимому). Или WinMerge
В linux с этим ещё проще и красивее - Meld например
Только сравнивать надо не только 2 файла, а еще и файл бэкапа с содержимым базы. Только так будет реально найти косяки...
Я так понял, что поля в базе в результате таких операций частенько "теряются".
Ну или (при невозможности такого сравнения) разворачивать полученный бэкап в отдельную (резервную) базу и как-то автоматически сверять с последующим выводом результатов сравнения или заменой полей...
В любом случае, это фантазия... Я так понял, что пока бэкап средствами хостинга всё же в разы надежнее, чем штатный бэкап CMS. Как бы нам не хотелось иного...
Надежнее в том плане, что я, как привыкший всё трогать ручками (видать с младенчества привычка осталась :) ) доверяю только тому, что сам ощупал. Во встроенном бэкапе мне только приходится доверять, что всё сделано правильно. Через терминал я же что укажу - то и забэкаплю. И так, как я захочу и посчитаю правильным )) Здесь вопрос только в этом ))
Надежнее в том плане, что я, как привыкший всё трогать ручками (видать с младенчества привычка осталась :) ) доверяю только тому, что сам ощупал. Во встроенном бэкапе мне только приходится доверять, что всё сделано правильно. Через терминал я же что укажу - то и забэкаплю. И так, как я захочу и посчитаю правильным )) Здесь вопрос только в этом ))
Я как раз не силен в матчасти (и особой правильностью заточки рук похвастаться не могу) и наличие встроенного инструмента бэкапа в том числе повлияло на покупку лицензии.
Но, как выяснилось, в полной мере положиться на него нельзя. Жаль... Жаль, что узнал об этом, пробежавшись по граблям... Как обычно...
Всё хвалю да хвалю, что нормально бэкап устроен. А вот вам: сейчас экспортировал товары из магазина, и импортировал их в чистую базу на 4.5.1 SP1
Повторюсь - база пустая!
Импорт сообщил, что шесть с лишним тысяч товаров создано и один (!) обновлен!
При этом все категории были созданы, а один товар (который в рабочем магазине имеет основную и притом одну категорию, назовем "категория") в новом эта категория встала как дополнительная, а сам товар помещен в категорию "Products", что автоматом создается для товаров без категорий. У части товаров вместо выключенного статуса проставился включенный. Далее. При экспорте выгрузил товары в директорию exim/backup/images/1/
При импорте тоже стоит поле, откуда брать изображения...... но зачем оно? я перенес в новую установку изображения в папку exim/backup/images/ и оставил это значение (что и стоит по умолчанию) но вне зависимости от этого значения, скрипт ищет именно в exim/backup/images/1/ - так как этот путь полностью пишется в файле
Мелочи, на которые со временем перестаешь обращать внимание, но когда сталкиваешься впервые - вводят в замешательство...
PS
Бог с ней, с админкой, дай бог, чтоб с лица не глючило )))
Новая таблица характеристик, где всё скопом... И прпи этом даже сортировки по группем нет. Ну не знаю... Старая таблица, где визуально сразу всё по группам было разделено, и когда не надо было входить в каждую характеристику, а прямо в таблице расставить позиции - моё имхо - было гораздо удобнее
вот кстати у меня тоже этих блоков накопилось прилично, самое неприятное непонятно как их отличать и угадывать какой из них рабочий. Как Вы решили эту проблему?
Ну вот, кстати, у меня времечко появилось, и я начал чистить базу. Алгоритм удаления лишних блоков. (На моем примере блока "Строка навигации", коих у меня уже 19 :) )
1. Надо узнать ИД блока, который показывается на сайте. Два пути
а) открываем лицо сайта и смотрим в коде (ПКМ по строке навигации, Посмотреть код):
б) открываем макеты, правой кнопкой по нужному блоку и в Просмотре кода ищем ИД блока:
2. Открываем блоки, ПКМ по нужному блоку, Просмотр кода, и ищем блок с найденным ИД (у меня это оказался 26). Все остальные могу смело удалять.
PS: На всякий случай можно пролистать все локации и посмотреть, нет ли там этого блока с другим ИД, У меня например в локации блога Главное содержимое с другим ИД образовалось
Ну и бэкап базы на всякий случай. Если случайно не тот блок удалите.
Встроенный бэкап и обновления - это функционал с генератором случайного результата. Может получится, может нет, может с первого раза, может с третьего.
Я заметил, что при восстановлении БД размером около 22Мб, таблицы какие успеют восстановится, те и будут. Причем кол-во таблиц при каждом восстановлении - разное. Ну чем не функционал с генератором случайного результата?
Хорошо бы, разработчики обратили внимание на эту критику... Получается, что функционал бэкапа в движке есть, но пользоваться им просто опасно.
После таких бэкапов приходится обращаться в ТП и платить кредитами, а это не есть хорошо.
Вот бы услышать комментарий представителя разработчиков относительно этой претензии.
Привет,
Я сначала постараюсь описать зачем нужен бекап по задумке разработчиков, а потому как мы можем улучшить.
Итак, средства автоматического бекапа предназначены для решения двух основных задач:
- слепок текущего состояния системы, для того чтобы в любой момент его можно было восстановить. Обычно используется при апгрейде, либо перед применением серьезных модификаций.
- копия текущего магазина, для того чтобы перенести его на другой хостинг
Львиная часть проблем с бекапом вызывается серверными настройками, обычное это тайм лимит.
Я хочу сделать так чтобы бекап работал корректно, и был удобен в использовании. Если вы готовы помочь мне в этом, то пожалуйста напишите о своих проблемах, с детализацией следующих моментов:
- с какой целью делался бекап
- какой хостинг вы используете
- какой получился результат (какие возникли проблемы, какая разница в данных, потеряли ли что-то и т.д. - т.е. детальное описание самой проблемы)
Буду благодарен за подробный ответ. Либо можем лично пообщаться по этому поводу в скайпе например, или в slack.
Еще раз напишу, что пользуюсь для бэкапа БД тем же supexdumper - потому что он на порядок если не на два быстрее, плюс задание на крон позволяет вешать, да ещё и с ротацией. ОДНАКО. Никогда не забываю делать бэкап из админки, потому как пару раз у меня отказались восстанавливать базу из бэкапа и phpmyadmin, и SD. И только Резервное копирование в админке без вопросов развернуло обратно сделанный бэкап.
Ничего нового не появилось. Выискивать по id жутко муторно, особенно если блок на разных макетах. Наверняка есть один запрос к БД, чтобы, хотя бы вывести номера неиспользуемых. Кто состряпает?
Ну или по хорошему. запретить удалять блоки, если они есть в макете. Мол, сначала удалите в макете.