Как сделать резервную копию Ubuntu 12.04 lts? Должен быть в состоянии восстановить в течение 2 дней или меньше

Question

Я запускаю несколько сайтов электронной коммерции на своем домашнем сервере (свой, члена семьи и клиента). Это более старый Dell Dimension 4600, который у меня работает под управлением Ubuntu 12.04 lts. Компьютер не показывает никаких признаков скорого сбоя, но, поскольку он старый, я хочу иметь хорошую резервную копию на случай, если что-нибудь случится. Мне нужно было бы иметь возможность восстановить данные на новом сервере в течение нескольких дней после того, как сервер выйдет из строя. Это лучший способ использовать что-то вроде Clonezilla? Или должен ли быть лучший способ сделать это?

Обновить

Мне не нужно, чтобы сайт работал, пока я делаю это, и в настоящее время у меня есть около 8 ГБ данных. Битовая копия кажется хорошей идеей для того, что я хочу, а именно для создания резервной копии, а затем, если что-то случится, сможет подключить резервный диск и начать работу. Расположение диска - только один диск, один большой раздел на 80 ГБ. Да, я знаю, что это не самое лучшее, я был новичком во всем мире Linux, Ubuntu, веб-серверов, почти во всем, когда я установил ОС и изначально настроил ее. Так что ЛВМ тоже нет

Answer 1

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

Если сайт должен быть активным во время копирования, проблема более сложная. Хороший способ обработки резервных копий в Linux - это планирование инкрементных резервных копий с использованием чего-то вроде rsnapshot (но rsync может быть проще в вашем случае). Если вам нужно восстановить, хотя вам нужно будет начать с восстановления сервера, а затем скопировать последний снимок.

Вы не указали количество резервируемых данных, частоту их изменения или структуру дисков. Обе эти вещи полезны при создании решения для резервного копирования. Если вы строите новую систему (или у вас была дальновидность при сборке исходной системы), часто бывает полезно создать файловую систему на LVM, а затем сделать снимок LVM и выполнить его резервное копирование. Это означает отсутствие простоев, и вы можете сделать точную копию [большей части] файловой системы в определенный момент времени. Конечно, предполагается, что вы используете LVM.

Точно так же, если у вас хорошее разделение между вашей ОС и приложением, вы можете начать с базовой установки Ubuntu 12.04, а затем постепенно создавать резервные копии только приложений. Возможно, вы захотите обрабатывать базы данных иначе, чем веб-файлы, создавая дамп базы данных. Точно так же tar (иногда на блочных устройствах) может быть полезен для полных, сжатых резервных копий, но при резервном копировании блочных устройств следует помнить, что изменения файлов во время резервного копирования блочного устройства могут довольно сильно вернуться к работе без особой осторожности.

К сожалению, сложно получить более конкретную информацию, потому что резервные копии в некоторой степени зависят от системы.

Answer 2

В такой ситуации, вероятно, лучше всего использовать другой сервер, на котором вы можете синхронизировать свои данные. Купите VPS и синхронизируйте ваш код, базы данных и настройки. Я только что проверил поставщика, которого я использую, и вы можете получить VPS с 20 ГБ пространства, 512 МБ ОЗУ, 1,5 ТБ передачи и 2 IP-адреса за 20 долларов в год. Удвойте спецификации, и это 40 долларов в год. Арахис. Если вам не нравятся мальчики со скидкой, вы можете использовать Amazon Cloud или Slicehost, но я думаю, вы тратите впустую свои деньги.

Когда вы вносите изменения в код, используйте Dreamweaver (или то, что вы используете), чтобы внести изменения в свой "тестовый" сайт. Затем продвигайте свои данные на "производственный" сайт. Большинство IDE для веб-разработки имеют возможность иметь "тестовый" сервер и сервер "prod". Вы выбираете, что есть что. Если бы это был я (и у меня почти такая же ситуация с некоторыми клиентами), я бы установил VPS в качестве рабочего сайта и использовал бы домашний сервер в качестве резервного сайта.

Начальная настройка этого проста. Вы можете сбросить все ваши установленные пакеты из apt-get в текстовый файл и использовать его для установки тех же пакетов на вашем VPS. Настраивая веб-файлы, дампы базы данных, и вы можете использовать SCP, чтобы скопировать их прямо на ваш другой сервер. (Вероятно, сделать все это с помощью короткого сценария оболочки.) Вы, вероятно, захотите скопировать большую часть ваших / и т.д. Тоже. Как только начальная настройка завершена, синхронизировать все становится тривиально.

Это имеет много преимуществ.

1. Во-первых, в вашем доме отключается электричество, а сервер не отключается.
2. Во-вторых, изменения кода тестируются и разрабатываются в вашей локальной сети, поэтому они бывают быстрыми, и вы не ожидаете передачи данных через медленное соединение (YMMV).
3. У вас аппаратный сбой, и вам нужна часть, на получение которой уходит неделя - ваша производственная площадка остается в рабочем состоянии.
4. Вы можете подключиться к своему серверу тестирования из любого места, внести изменения, протестировать их, а затем отправить их на свой сервер с минимальными перебоями.
5. Вы можете разрабатывать в той же конфигурации, что и производственный станок. Таким образом, вам не нужно использовать XAMPP или какую-либо другую среду разработки и беспокоиться о зависимостях, структуре или всех других нюансах разработки.
6. Совместное расположение. Если по какой-либо причине произойдет сбой вашей рабочей машины (VPS), переназначьте DNS на домашний сервер. Держите свой DNS TTL на 30 минут, и время простоя минимально.

Итак, это моя рекомендация.

И да, я беру с людей 1000 долларов в год за VPS, который стоит мне около 40 долларов в год ... Я также продаю им услуги совместного размещения, это просто другой VPS от другого провайдера или в моей домашней стойке. Ты должен стоять на плечах гигантов, если хочешь заработать в веб-игре. Разработка кода это хорошо, но остаточный доход там, где он есть, брат. Купить по низкой цене. Продать дорого.