[HEDG]

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

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

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

 

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 .

 

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

Изменено 19 августа, 2011 пользователем HEDG

[SSTS]

bacula

[vlad11]

bacula

 

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

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

[s.lobanov]

bacula

 

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

 

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

 

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

[ilia_2s]

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

[s.lobanov]

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

 

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

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

[ilia_2s]

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

 

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

[littlesavage]

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

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

 

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

[st_re]

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

 

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

[NiTr0]

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

lvm snapshot - не?

[s.lobanov]

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

lvm snapshot - не?

 

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

 

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

 

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

[Ilya Evseev]

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

Изменено 23 августа, 2011 пользователем Ilya Evseev

[lan-viper]

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

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

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

[vlad11]

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

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

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

 

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

Изменено 23 августа, 2011 пользователем vlad11

[s.lobanov]

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

 

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

[Andrei]

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

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

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

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

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

[Ilya Evseev]

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

 

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

 

 

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

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

 

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

 

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

 

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

[littlesavage]

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

[Andrei]

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

 

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 как раз делается для того, чтобы не было блокировок.

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

[andriko]

у меня по 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"

Изменено 25 августа, 2011 пользователем andriko

[diesels]

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

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

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

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

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

Изменено 13 апреля, 2015 пользователем diesels

[Megas]

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

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

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

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

[diesels]

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. система стоит на отдельных дисках?

[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х клиентских машин.

Изменено 14 апреля, 2015 пользователем Megas

[diesels]

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

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

/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 шт?