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

167 пользователей проголосовало

  1. 1. Какие системы резевного копирования Вы используете?

    • Backula
    • Amanda
    • dump/restore + ssh/scp/sftp
    • rsync
    • BackupPC
    • DIBS
      0
    • cp, tar + ssh/scp/sftp
    • rdiff-backup
    • dar
      0
    • duplicity
    • Я ЕЩЕ не делаю бэкап
    • ZFS tools
    • CVS tools (git/subversion/etc)


Система резервного копирования Что используем?

rsync+tar, бекапить надо на ссд накопители, планирую так сделать в идеале

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


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

бекапить надо на ссд накопители

Чтобы если сдохло, то уж с концами и невосстановимо даже за большие деньги? :)

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


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

если выбирать между Backula и рсинком какой больше подойдет? (бекап баз дынных, конфигов, логи)

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


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

я из тех кто уже делает бэкапы :)

важные серваки 3ware raid1 + хард 2TB на sata материнки, куда сливаются образы виртуалок раз в 3-7 дней, образы инкрементятся 3-5 раз.

отдельно бекап сервер, на который сливается скриптами дампы БД раз в сутки.

вот думаю воткнуть ещё один бекап сервер, который с первого rsinc-ом будет стасткивать файло.

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


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

я из тех кто уже делает бэкапы :)

Гром грянул и молния наполовину ослепила?

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


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

Хорошая тема... Есть какое-то красивое решение для бакапа виртуальных серверов в ESXi?

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


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

Отвечу себе сам :) красивое решение есть - называется Acronis vmProtect. Только кряков на него нету :))

Еще якобы Acronis Backup & Recovery умеет бакапить виртуальные машины (без агентов в системах), но... чего-то я не нашел как это сделать. В мануалах говорят что при установке нужно извлечь AcronisVirtualApplience.msi, только вот во всех дистрибутивах что мне попадались нет этого компонента. Есть у кого-нибудь такой опыт?

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


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

Для конфигов юзаем OpsCode Chef(рецепты по необходимости пишем).

Рецепты храним в git репозитории.

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


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

Понекрофилю немного...

 

А чем нонче модно-удобно бакапить большие объемы мало изменяющихся, в основном добавляющихся больших файлов, как то видео и прочее фото и pdf.

 

объемы десятки, может сотня терабайт, видео вплоть до 4к, тоесть тяжелое. делать 2 копии и копировать через день, конечно здорово, но размер *2 с глубиной 2 дня не спасёт от покоцаных данных в пятницу, к понедельнику обе копии будут аналлогично покоцаны.

 

ну понятно что одна полная копия сделанная 1 раз и дальше ежедневно mkdir <DATE> и копирование туда только новых или измененных файлов + положение списка файлов решит 90% хотелок. но если будет какаято rsync подобная автоматизация, да чтобы просто найти "был файл aaa.avi и пропал", понятно что никто не помнит в каком веке он появился и где точно лежал или восстановить папку на дату, причем неплохо бы, чтобы без бывших там когдато, но пропавших до указанной даты файлов..

 

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


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

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

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

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


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

1 hour ago, st_re said:

А чем нонче модно-удобно бакапить большие объемы мало изменяющихся, в основном добавляющихся больших файлов, как то видео и прочее фото и pdf.

 

объемы десятки, может сотня терабайт, видео вплоть до 4к, тоесть тяжелое. делать 2 копии и копировать через день, конечно здорово, но размер *2 с глубиной 2 дня не спасёт от покоцаных данных в пятницу, к понедельнику обе копии будут аналлогично покоцаны.

 

ну понятно что одна полная копия сделанная 1 раз и дальше ежедневно mkdir <DATE> и копирование туда только новых или измененных файлов + положение списка файлов решит 90% хотелок. но если будет какаято rsync подобная автоматизация, да чтобы просто найти "был файл aaa.avi и пропал", понятно что никто не помнит в каком веке он появился и где точно лежал или восстановить папку на дату, причем неплохо бы, чтобы без бывших там когдато, но пропавших до указанной даты файлов..

  

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

 

"большие объемы" - в общем случае, чем примитивнее инструмент, тем лучше. Меньше тормозить будет и более предсказуемо. Я бы начал тупо с tar.

"мало изменяющихся, в основном добавляющихся больших файлов" - полная копия, допустим, раз в месяц, и инкрементальная ежеденвно. Хранить текущий и предыдущий месяц со всеми инкременталами, из более ранних месяцев только полную копию.

"видео и прочее фото и pdf" - если уже пожато, то можно tar-ом без сжатия. Надо попробовать так и так, посмотреть как дополнительное сжатие влияет на размер и время.

"никто не помнит в каком веке он появился и где точно лежал" - помогает, кроме бакапа, проводить частую инвентаризацию. Банально "find /wherever -type f -print | sort | gzip > inventory_wherever_$(date +%FT%H%M%S).txt.gz". В инвентаре искать grep-ом. Если вычислительных ресурсов хватает, то по тому-же инвентарю можно генерировать и хранить контрольнные суммы для каждого файла.

Ещё инвентарь помагает как-то независимо отслеживать, что там вообще происходит. Ответственное лицо может периодически пробегать глазами diff между самым свежим инвентарём и предыдущим просмотренным, по ходу делая пометки кому дать по рукам.

 

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

 

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

 

 

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


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

7 часов назад, st_re сказал:

объемы десятки, может сотня терабайт, видео вплоть до 4к, тоесть тяжелое. делать 2 копии и копировать через день, конечно здорово, но размер *2 с глубиной 2 дня не спасёт от покоцаных данных в пятницу, к понедельнику обе копии будут аналлогично покоцаны.

rsync на большое хранилище с zfs, а там снапшоты?

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


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

1 hour ago, st_re said:

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

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

Предположу, что подводные камни, даже в готовом решении, будут спецефичны для конкретно вашего use-кейса.

Судя по тому что вы расказали, ИМХО rsync вполне подходит, с оговоркой что придётся как-то следить за реплицированием delete и перезаписи файлов. Иначе будет риск в один прекрасный момент догнать изменение типа "стёрто всё". Tar, в хорошей мере, от этого защищает.

 

 

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


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

7 минут назад, lugoblin сказал:

придётся как-то следить за реплицированием delete и перезаписи файлов

rsync -ai --delete будет удалять файлы и в более-менее вменяемом виде писать об этом в stdout (соответственно можно сохранить и грепать потом, ну или по-модному в elk класть )))

 

8 минут назад, lugoblin сказал:

Иначе будет риск в один прекрасный момент догнать изменение типа "стёрто всё"

потому и написал про снапшоты на приёмнике. они практически ничего не стоят, и отлично решают эту проблему.

 

и вот эту задачу тоже:

8 часов назад, st_re сказал:

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

 

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


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

23 minutes ago, edo said:

rsync -ai --delete будет удалять файлы и в более-менее вменяемом виде писать об этом в stdout

Хорошо, но мало. Ну вот, допустим, потеряли мы файл, нашли грепом в логах rsync-а как его стирание ушло на реплику, которав вроде как бэкап. Нам от того лучше стало? Инкрементальный tar, при всех его недостатках, этот кейс покрывает.

 

31 minutes ago, edo said:
1 hour ago, lugoblin said:

Иначе будет риск в один прекрасный момент догнать изменение типа "стёрто всё"

потому и написал про снапшоты на приёмнике. они практически ничего не стоят, и отлично решают эту проблему.

Согласен, но просветите, почему на приёмнике? Я бы это интерпретировал как рекомендацию st_re, паралельно с бэкапами подумать в сторону снапшотов, которые и на основном хранилище не зазорно сделать, тем более если они ничего не стоят. А н априёмнике пусть будет бэкап, простой как кирпич, который и в оффлайн унести можно, и на NAS по CIFS скинуть.

 

 

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


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

29 минут назад, lugoblin сказал:

Ну вот, допустим, потеряли мы файл, нашли грепом в логах rsync-а как его стирание ушло на реплику, которав вроде как бэкап. Нам от того лучше стало?

конечно. взяли файл из снапшота за предыдущую дату.

 

29 минут назад, lugoblin сказал:

Я бы это интерпретировал как рекомендацию st_re, паралельно с бэкапами подумать в сторону снапшотов, которые и на основном хранилище не зазорно сделать, тем более если они ничего не стоят

снапшоты (если мы говорим про linux) есть:

 - в zfs;

 - в btrfs;

 - в lvm.

 

btrfs таки не production-ready, в lvm снапшоты совсем не бесплатные.

 

zfs можно рассмотреть, но:

 - я так понимаю, сервер с десятками терабайт данных уже есть, смена файловой системы — это, возможно, целая история;

 - zfs (а точнее raidz) не любит многопоточную линейную нагрузку, если этот сервер отдаёт контент — это может быть критично.

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


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

5 minutes ago, edo said:

btrfs таки не production-ready, в lvm снапшоты совсем не бесплатные.

 

zfs можно рассмотреть, но:

 - я так понимаю, сервер с десятками терабайт данных уже есть, смена файловой системы — это, возможно, целая история;

 - zfs (а точнее raidz) не любит многопоточную линейную нагрузку, если этот сервер отдаёт контент — это может быть критично.

Спасибо за пояснение.

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


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

ок, понятно, ничего более менее готового, всем спасибо :)

 

еще можно каждый день рсинк в новую диру с --link-dest от вчерашней.. если изменений не много, а в основном добавления, то каждый новый бакап будет общее место увеличивать на размер добавленных или измененных файлов после вчерашнего бакапа.. только вот файлуха должна иметь МНОГО инодов, чтобы не хрястнуло.. зато каждый бакап полный, на указанную дату, можно прореживать по мере старения, как нравится..

 

файлуха КУДА мы будем бакапить пока не важна, это по любому отдельный сервер, локальные сапшоты на том же сервере это не бакап, в общем то, так для упрощения быстро восстановить только что стертый или попорченый файл, не более.. насколько я понимаю пока по условию задачи, права там всем одинаковые, их можно не копировать вообще..

 

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

 

еще както пробовал дедуп на фре и zfs. пока копий 1-2 вроде все ок, место не растет почти., а как написал сотню копий почти одного и тогоже, так запись стала мееееедддддддлллллленннооооой и печальной. Но тогда интерес был академический больше.

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


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

5 часов назад, st_re сказал:

еще както пробовал дедуп на фре и zfs. пока копий 1-2 вроде все ок, место не растет почти., а как написал сотню копий почти одного и тогоже, так запись стала мееееедддддддлллллленннооооой и печальной. Но тогда интерес был академический больше.

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

 

у меня на большом пуле отдельная фс, где ежедневные бэкапы виртуалок лежат, они ото дня ко дню не особо меняются, коэффициент дедупликации получается больше, чем 4:1. вместе со сжатием zfs общая экономия примерно 1:10 (10 ежедневных копий виртуалок, занимающих на vmware в thin provisioning 6 Тб, занимают по отчёту zfs чуть меньше тех же 6 Тб на бэкап-сервере).

 

5 часов назад, st_re сказал:

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

снапшоты и cow хорошо сочетаются друг с другом. есть проблема с фрагментацией, но не фатальная.

на упоминвашийся выше массив бэкап стабильно идёт со скоростью больше 500 МБ/с, видел и гигабайт в секунду на хорошо сжимаемых данных.

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


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

@st_re https://www.fsarchiver.org/quickstart/ видели?

 

В 22.10.2020 в 18:22, st_re сказал:

еще както пробовал дедуп на фре и zfs. пока копий 1-2 вроде все ок, место не растет почти., а как написал сотню копий почти одного и тогоже, так запись стала мееееедддддддлллллленннооооой и печальной.

В районе 10 завезли многопоточность в дедуп ZFS на фре, все значительно улучшилось.

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


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

12 часов назад, jffulcrum сказал:

ну сохранять разделы целиком , явно не мой текущий случай...

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


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

Join the conversation

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

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

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

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

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

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

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