Перейти к содержимому
Калькуляторы

Обсуждение Backup систем Создание "правильного" backup сервера. Делимся опытом.

Добрый день всем Наговцам :)!

Хочу перейти в ряды "тех кто делает бекапы".

Прошу помочь определиться с системой бекапа, которая больше соответствует требованиям:

 

1. Собственно сама система бекапа, должна бекапить.

2. Уметь делать разные типы бекапов - Бекап всего диска(создание его образа) и бекап отдельных файлов;

полные, инкриментные, дифф, в идеале еще и "на лету" как Box Backup.

3. Возможность восстановления "в течение получаса". Вижу схему следующим образом:

- загрузка с флешки на любом компе с чистым HDD (если не чистый, то удаляются все разделы).

- подтыкаем в сеть (запускаем скрипт для настройки сети)

- Указываем с откуда и какой сервер восстанавливать + использование пароля или ключа для доступа.

- После чего заливается и раскатывется последний снапшот системы и автоматом накатываются все

последние изменения.

Т.е. по факту система аналогичная как в acronis.

 

4. Простота использования при любом типе восстановления бекапов.

5. Надежность самой системы, отсутствие "узких мест" или хотябы уменьшения их влияния.

6. Возможность мониторинга системы бекапа. успех/крах/ошибки

7. Минимизировать занимаемое место, но практически без ущерба для скорости работы и восстановления

8. Система ротации бекапов. Уметь удалять старые данные после определенного периода (6-12мес.)

9. Правильное поведение системы при переполнении места в хранилище(ротация бекапов)

10. Безопасность передачи данных по сети.

11. Безопасное хранение данных. Шифрование или что-то подобное. Понятно, что это потенциальное узкое место.

12. Добавлять информацию о бекапах: откуда, тип бекапа, размер, дата создания и др. полезная инфа

13. Желательна какая-то веб морда для мониторинга и управления.

14. Основные ОС - FreeBSD. Неплохо также и кросспратформенность - возможность работы с Linux и Windows

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

17. Возможность создания бекапа "по требованию", а не только по расписанию

18. Желательно отдельно уметь бекапить БД (Mysql, Postgresql), либо возможность "прикрутить" разные скрипы для этого.

 

А ну и конечно OpenSource .

 

Буду очень признателен, если Вы поделетесь своим мнением и опытом использования и внедрения подобных систем.

Изменено пользователем HEDG

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

bacula

 

Поделитесь практическим опытом копирования блобов, которые загружены в памяти. Например Mysql (таблицы innodb), memcache, различные java приложения.

Как бакула сможет бэкапить ZFS (снапшоты, клоны, копии)?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

bacula

 

Поделитесь практическим опытом копирования блобов, которые загружены в памяти. Например Mysql (таблицы innodb), memcache, различные java приложения.

 

Баловство. Все важные данные должны быть восстанавливаемыми из бинарного лога транзакций.

 

А вообще, проще и дешевле будет сделать кластер(хотя бы БД), чем предъявлять ТАКИЕ требования к бэкапу.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

+1 за кластер, все остальное можно сделать скриптами на dd

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

все остальное можно сделать скриптами на dd

 

Я один раз восстанавливал систему из образа, сделанного dd "наживую". На этот аттракцион потратил часа 2 и это ещё повезло, что дисковая активность во время бэкапа была минимальной.

Для dd надо выключать сервер, иногда есть смысл это сделать перед вводом в экплуатацию, но в некоторых случаях и это не имеет смысла, если применяется LVM и на ходу добавляются scsi-полка или LUN по SAN-сети

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

естественно!

 

Заморозил ноду, образ сслил и дальше работаешь...

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Поделитесь практическим опытом копирования блобов, которые загружены в памяти. Например Mysql (таблицы innodb), memcache, различные java приложения.

Как бакула сможет бэкапить ZFS (снапшоты, клоны, копии)?

 

С mysql InnoDB там, наверно, только репликация и дампы с реплики. А вот memcache зачем?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

кластер и раид не панацея ни разу. rm -Rf / или DROP DATABASE Billing может произойти как умышленно так и не умышленно. Кроме того бывают наводнения, пожары и цунами, грабители, ошибки персонала и прочие "доброжелатели". Бакап должен быть. очень желательно чтобы вне основного здания. (а лучше 2 бакапа, 1 в основном здании для бысторго доступа, второй выносной.). Даже если у Вас комания "Пупкин and Сыны, сэмачки и орешки", всеравно рано или поздно вы будете кричать в конторе по востановлениям HDD, что "там же 1С была!!!!"

 

Сам бакаплю самописно. наверное не самое оптимальное решение, но свои ф-ции выполняет.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Я один раз восстанавливал систему из образа, сделанного dd "наживую".

lvm snapshot - не?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Я один раз восстанавливал систему из образа, сделанного dd "наживую".

lvm snapshot - не?

 

Бэкап делал не я, я только восстанавливал.

 

кластер и раид не панацея ни разу. rm -Rf / или DROP DATABASE Billing может произойти как умышленно так и не умышленно.

 

никто и не спорит. кластер и raid это лекарство против чрезвычайно высоких требований к бэкап-системе.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

rdiff-backup для развесистых файловых деревьев, picobackup+ls4sweep для всего остального.

Изменено пользователем Ilya Evseev

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

rsnapshot для файлов конфигов и прочих файлов и каталогов, которые не ставятся из пакетов дистрибутива.

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

С mysql InnoDB там, наверно, только репликация и дампы с реплики. А вот memcache зачем?

Выше посоветовали бакулу как универсальное средство бэкапов.

А я указал случаи, в которых она не поможет.

 

P.S. некоторые в мемкеше хранят не только сессии, но и данные :)

Изменено пользователем vlad11

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

P.S. некоторые в мемкеше хранят не только сессии, но и данные :)

 

И если даже найти систему бэкапа, которая умеет бэкапить мемкеш, то всё равно это не сильно поможет, т.к. бэкап так или иначе периодический, а не непрерывный. Храните полезные данные в памяти - флаг вам в руки. ОЗУ создан не для хранения, а для обработки данных и кеширования более медленной постоянной памяти.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

С mysql InnoDB там, наверно, только репликация и дампы с реплики. А вот memcache зачем?

Выше посоветовали бакулу как универсальное средство бэкапов.

Что-то типа такого:

mysqldump -u ххх -pххх --create-options --routines --databases billing | gzip > /usr/local/billing/backup/backup_bill.sql.gz

почему плохо?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Что-то типа такого:

 

mysqldump -u ххх -pххх ... /billing/backup/backup_bill.sql.gz

 

 

почему плохо?

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

 

2) старые версии надо прореживать. Ищите в Гугле ls4sweep

 

3) если сбой произойдёт в момент создания резервной копии, не будет ни резервной копии, ни базы.

 

4) неразумно хранить резервную копию только в том же помещении на том же компьютере и на том же физическом носителе. Ищите в Гугле up2rshare :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

SQL дампы mysqldump восстанавливаются _очень_ долго. А дамп с основного сервера без --single-transaction еще и блокирует базу. Больше вреда, чем пользы.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Что-то типа такого:

 

mysqldump -u ххх -pххх ... /billing/backup/backup_bill.sql.gz

 

 

почему плохо?

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

 

2) старые версии надо прореживать. Ищите в Гугле ls4sweep

 

3) если сбой произойдёт в момент создания резервной копии, не будет ни резервной копии, ни базы.

 

4) неразумно хранить резервную копию только в том же помещении на том же компьютере и на том же физическом носителе. Ищите в Гугле up2rshare :)

1-2. для этого есть системы типа а-ля logrotate

3. почему? не вижу логики

4. кто сказал, что бэкап хранится тут же? по окончании mysqldump все сливается на другой сервер по ftp.

 

SQL дампы mysqldump восстанавливаются _очень_ долго. А дамп с основного сервера без --single-transaction еще и блокирует базу. Больше вреда, чем пользы.

Сорри. Не совсем понял о чем речь. --single-transaction как раз делается для того, чтобы не было блокировок.

Долго/быстро зависит от объема базы и производительности системы. У меня это делается за неск.минут.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

у меня по sql примерно так:

5 5 * * *       /usr/local/bin/mysqldump --ignore-table=radius.radacct --ignore-table=radius.radpostauth \
--ignore-table=radius.totacct --skip-extended-insert radius | \
tee /home/backup/XXX/`date +\%Y\%m`/radius.`date +\%s`.sql | \
ssh backup@YYY "cat > /home/backup/XXX/`date +\%Y\%m`/radius.`date +\%s`.sql"

Изменено пользователем andriko

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Подскажите по акрониксу.

на столько применимо это решение для расширения рейд массива.

хочу расширить свой рейд 10 на 2 терра. вот думаю сделать копию системы через акроникс. пересобрать рейд и залить все обратно.

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

система у меня Proxmox виртуальные машины. рейд железный

Изменено пользователем diesels

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

1. сколько у вас сейчас дисков в массиве.

2. какой контроллер.

3. данные клиента хранятся в виде lvm или в виде файлов?

4. система стоит на отдельных дисках?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

1. сейчас 4, 2 по 1 тер. 2 по 500 гб. хочу сделать 6шт по 1 тер

2. Точно не знаю. сервер dell 2950 из мануала написано что может стоять два варианта Optional PERC 5/i integrated SAS/SATA daughtercard controller with 256MB cache, PERC 4e/DC, PERC 5

3. lvm нет точно. данные клиентов лежат в виртуальных машинах. формат этих машин qcow2

4. система не на отдельных дисках. раньше до этого не додумался если честно.

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

1. сколько у вас сейчас дисков в массиве.

2. какой контроллер.

3. данные клиента хранятся в виде lvm или в виде файлов?

4. система стоит на отдельных дисках?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Кластер из двух нод?

собственно все легко переподнимается.

/etc тарите и на другую машину.

образы машин можно просто скопировать в другое место ничего с ними не будет, /etc/pve/qumu находится описание машин можно потом просто подкинуть образы и конфиги и все заведется, главное чтобы пути были правильные.

 

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

 

в общем просто все сносите, делаете как вам надо и заливаете образы машин и конфиги, настройки сети и стартуете, если надо то вводите ноду обратно в кластер.

 

6 дисков в 10ом не правильно, должно быть 8мь + 1 в hotspare, иначе теряется смысл.

 

бэкапы это просто каталог, в настройках кластера раздел storadge и там есть пути, просто у каталога выставлены права backup.

 

 

root@cluster-1-2:~# pvecm nodes
Node  Sts   Inc   Joined               Name
  1   M   4324   2015-02-05 01:40:36  cluster-1-1
  2   M   4296   2015-02-05 01:40:21  cluster-1-2
  3   M   4328   2015-02-05 01:40:40  cluster-1-3
  4   M   4308   2015-02-05 01:40:23  cluster-1-4
  5   M   4312   2015-02-05 01:40:25  cluster-1-5
  6   M   4336   2015-02-25 11:27:03  cluster-1-6
  7   M   4376   2015-03-23 18:01:21  cluster-1-7
  8   M   4316   2015-02-05 01:40:27  cluster-1-8
  9   M   4304   2015-02-05 01:40:23  cluster-1-9
 10   M   4296   2015-02-05 01:40:21  cluster-1-10
 11   M   4296   2015-02-05 01:40:21  cluster-1-11
root@cluster-1-2:~# 

сейчас, больше 300х клиентских машин.

Изменено пользователем Megas

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Кластер из двух нод?

собственно все легко переподнимается.

/etc тарите и на другую машину.

образы машин можно просто скопировать в другое место ничего с ними не будет, /etc/pve/qumu находится описание машин можно потом просто подкинуть образы и конфиги и все заведется, главное чтобы пути были правильные.

 

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

 

в общем просто все сносите, делаете как вам надо и заливаете образы машин и конфиги, настройки сети и стартуете, если надо то вводите ноду обратно в кластер.

 

6 дисков в 10ом не правильно, должно быть 8мь + 1 в hotspare, иначе теряется смысл.

 

бэкапы это просто каталог, в настройках кластера раздел storadge и там есть пути, просто у каталога выставлены права backup.

 

 

root@cluster-1-2:~# pvecm nodes
Node  Sts   Inc   Joined               Name
  1   M   4324   2015-02-05 01:40:36  cluster-1-1
  2   M   4296   2015-02-05 01:40:21  cluster-1-2
  3   M   4328   2015-02-05 01:40:40  cluster-1-3
  4   M   4308   2015-02-05 01:40:23  cluster-1-4
  5   M   4312   2015-02-05 01:40:25  cluster-1-5
  6   M   4336   2015-02-25 11:27:03  cluster-1-6
  7   M   4376   2015-03-23 18:01:21  cluster-1-7
  8   M   4316   2015-02-05 01:40:27  cluster-1-8
  9   M   4304   2015-02-05 01:40:23  cluster-1-9
 10   M   4296   2015-02-05 01:40:21  cluster-1-10
 11   M   4296   2015-02-05 01:40:21  cluster-1-11
root@cluster-1-2:~# 

сейчас, больше 300х клиентских машин.

 

У меня есть возможность только 6 дисков установить.

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

там же пара собираться в рейд один 1 и вторая пара с рейд 1 собираться в 0. в чем тогда необходимость 8 шт?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.