2011-12-13 4 views
1

Это может быть применимо и к любой электронной коммерции, такой как Magento.Magento: Резервное копирование

У меня есть новая установка Magento, и я хочу быть готовым к тому, когда клиент спросит меня о резервных копиях. Я знаю о всех (или большинстве) методах получения резервных копий, а также о различных битах, которые защищены каждым типом, однако я имею отношение к открытым заказам. Что происходит с заказами, размещенными после самой последней резервной копии БД в случае восстановления? Я предполагаю, что резервная копия БД хранит открытые ордера в системе, но, очевидно, я не могу брать и хранить резервные копии каждую секунду дня.

Итак, что происходит с заказами, сделанными после последней резервной копии, если база данных повреждена и ее необходимо восстановить? Я предполагаю, что будет хоть какой-то шанс, что некоторые приказы могут быть потеряны. Я ошибаюсь? Если нет, то для чего это стандартная практика? Товары, которые продает мой клиент, не так дешевы, поэтому типичные заказы, по крайней мере, составляют сотни (в евро).

+0

Magento работает на MySQL. –

+0

Я полностью неправильно понял, что и думал, что это магнито ... – UnhandledExcepSean

+1

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

ответ

3

Есть 2 вещи, которые я могу думать прямо сейчас:

1) репликации установки. Это гарантирует, что ваша резервная копия всегда актуальна и что вы можете быстро переключиться на подчиненный, если что-то произойдет с мастером.

2) Экспортируйте заказ автоматически, как только заказ будет завершен. Вы можете использовать реализацию события/наблюдателя magento для экспорта заказов в другие системы или просто отправлять простые копии на какой-либо адрес электронной почты, в зависимости от того, что именно вы хотите сделать резервным.

+0

Спасибо - это настройка репликации, то же самое, что и избыточность базы данных - была быстрая версия Google, и похоже похоже – byronyasgur

+0

Reeplication не является резервной копией. Мне нравится ваш второй вариант, однако я думаю, что необходимо наблюдать за многими событиями, а не только этим. – jrosell

4

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

Я предпочитаю ночные резервные копии для пурпурного. Это не для ведения записей, но для дерьмо попадает в крышу типа сенария. Если что-то действительно идет вразрез, вам лучше получить магазин и запустить ASAP и беспокоиться об открытых заказах и потерять информацию о продажах после того, как магазин будет вверх.

Сценарий резервного копирования является грубым, но он делает gziped копию базы данных и каталога файлов в каталоге, который вы можете сделать для резервного копирования. Он добавляет месяц и день в файлы. Вы должны убедиться, что у пользователя есть правильные разрешения для tar файловой структуры magento.

!/bin/sh 
m_user='databaseusername' 
m_pass='databasepasswd' 
db_name='databasename' 
od='/home/user/backups/website/' #output directory of the backups 
id='/var/www/html/' #the location of the site 
name=$od$db_name 
name+="_" 
mysqldump --opt -u $m_user -p$m_pass $db_name | gzip -c | cat > $name$(date +%m-%d).sql.gz; tar -zcvf $name$(date +%m-%d).tar.gz $id 

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

Смежные вопросы