форумы  помощь  поиск  регистрация  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Выпуск утилиты для резервного копирования rclone 1.35"	+/–
Сообщение от opennews on 03-Янв-17, 10:12
Состоялся (https://plus.google.com/+RcloneOrg/posts/j2CVbmckGLJ) выпуск утилиты rclone 1.35 (http://rclone.org/), которая представляет собой аналог rsync, предназначенный для копирования и синхронизации данных между локальной системой и различными облачными хранилищами, такими как Google Drive, Amazon Drive, S3, Dropbox, Backblaze B2, One Drive, Swift, Hubic, Cloudfiles, Google Cloud Storage и Yandex Files. Код проекта написан на языке Go и распространяется (https://github.com/ncw/rclone/) под лицензией MIT. Основные особенности: -  Контроль целостности передаваемых данных  при помощи хэшей MD5/SHA1; -  Сохранение исходного времени модификации и создания файлов; -  Поддержка режима частичной синхронизации, при которой копируются только изменившихся в файле данные; -  Режим копирования на целевую систему новых и изменившихся файлов; -  Режим синхронизации для обеспечения идентичного состояния двух директорий на разных системах; -  Режим проверки для сверки контрольных сумм; -  Возможность синхронизации между двумя облачными хранилищами; -  Поддержка шифрования передаваемых потоков данных; -  Режим "rclone mount", позволяющий примонтировать внешнее хранилище в качестве части локальной ФС при помощи FUSE; -  Из новых возможностей, добавленных в версии 1.35 можно отметить реализацию команд moveto и copyto для выбора системы назначения для операций перемещения и копирования, команду rmdirs для рекурсивного удаления диркторий, возможность повторного использования опций --include/--exclude/--filter при вызове команд. URL: https://plus.google.com/+RcloneOrg/posts/j2CVbmckGLJ Новость: http://www.opennet.dev/opennews/art.shtml?num=45808
Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "Выпуск утилиты для резервного копирования rclone 1.35"	+/–
Сообщение от Фанатик on 03-Янв-17, 10:12
А главное то, что написано оно на Go (распространяется одним бинарём) и под хорошей пермиссивной лицензией!
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	21. "Выпуск утилиты для резервного копирования rclone 1.35"	+6 +/–
	Сообщение от Аноним (??) on 03-Янв-17, 15:53
	И поэтому пермиссивно лочит любителей свободы на считанные единицы провайдеров облачного сервиса. Логично. Когда пермиссивные go'пники вещают про свободы - тут все понятно какая свобода имеется в виду.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

2. "Выпуск утилиты для резервного копирования rclone 1.35"	+/–
Сообщение от Аноним (??) on 03-Янв-17, 10:50
> распространяется одним бинарём И сколько он вешает в результате?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	4. "Выпуск утилиты для резервного копирования rclone 1.35"	–1 +/–
	Сообщение от Аноним (??) on 03-Янв-17, 11:10
	12568032, стрипнутый, амд64 в чем вопрос то ?
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	17. "Выпуск утилиты для резервного копирования rclone 1.35"	+5 +/–
	Сообщение от freehck (ok) on 03-Янв-17, 15:11
	> 12568032, стрипнутый, амд64 12М - это немало. Тот же rsync весит ~500K.
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	39. "Выпуск утилиты для резервного копирования rclone 1.35"	–3 +/–
	Сообщение от фыв (??) on 03-Янв-17, 20:36
	А ничего, что rsync зависит, как минимум, от libc, popt и еще чего-то?
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

	44. "Выпуск утилиты для резервного копирования rclone 1.35"	+1 +/–
	Сообщение от Mihail Zenkov (ok) on 04-Янв-17, 02:03
	Так он же не целиком их включает, а только используемые функции. В итоге весит 905.7K http://communities.vmware.com/servlet/JiveServlet/download/1...
	Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

	47. "Выпуск утилиты для резервного копирования rclone 1.35"	–1 +/–
	Сообщение от Аноним (??) on 04-Янв-17, 10:42
	> Так он же не целиком их включает, а только используемые функции. В > итоге весит 905.7K А его с LTO собрали? А то LTO может вышибить то что не используется и в случае типовой програмы она может еще примерно на четверть сдуться. Хотя от программы зависит.
	Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

	53. "Выпуск утилиты для резервного копирования rclone 1.35"	–1 +/–
	Сообщение от Mihail Zenkov (ok) on 04-Янв-17, 14:26
	> А его с LTO собрали? ./configure make CFLAGS="-static" EXEEXT="-static" strip rsync-static > А то LTO может вышибить то что не используется и в случае типовой програмы она может еще примерно на четверть сдуться. Хотя от программы зависит. Да, с LTO как повезет - может меньше стать, а может и больше - если компилятор inline активно использовать начнет.
	Ответить | Правка | ^ к родителю #47 | Наверх | Cообщить модератору

	56. "Выпуск утилиты для резервного копирования rclone 1.35"	–1 +/–
	Сообщение от Аноним (??) on 04-Янв-17, 15:59
	> make CFLAGS="-static" EXEEXT="-static" > strip rsync-static Это что, вообще без оптимизаций? oO А в чем пойнт? Он и большой и не оптимальный по скорости. Смысл в таком виде компилить - разве что злостный дебагбилд. В половине случаев можно отдебажить прямо оптимизированый btw :) > Да, с LTO как повезет - может меньше стать, а может и > больше - если компилятор inline активно использовать начнет. LTO на фазе линковки случается (link-time optimization же). И на генерацию кода стало быть не влияет. Как я понимаю, линкер делает отдельный pass при котором он агрессивно изучает какой код не используется и его можно убить. И все неиспользуемые функции и проч отправляются нафиг. Увеличить программу сие как я понимаю не может by design. Но вот время линковки заметно увеличивается + проход с анализом что можно выкинуть требует на финальной фазе линковки довольно много памяти, если программа большая. Случаев чтобы LTO _увеличил_ программу я вообще ни разу не встречал. Но вот насколько уменьшение бинаря vs увеличение времени линковки и потребления памяти порадует - может варьироваться для разных программ.
	Ответить | Правка | ^ к родителю #53 | Наверх | Cообщить модератору

	57. "Выпуск утилиты для резервного копирования rclone 1.35"	–2 +/–
	Сообщение от Mihail Zenkov (ok) on 04-Янв-17, 16:43
	> Это что, вообще без оптимизаций? Вообще-то обычно все исходники содержат оптимизацию в системах сборки. Обычно это -O2. > Как я понимаю, линкер делает отдельный pass при котором он агрессивно изучает какой код не используется и его можно убить. Это его побочное действие. Основное как раз inline и прочие подобные оптимизации. man gcc: Since both foo.o and bar.o are merged into a single image, this causes all the interprocedural analyses and optimizations in GCC to work across the two files as if they were a single one. This means, for example, that the inliner is able to inline functions in bar.o into functions in foo.o and vice-versa. > Случаев чтобы LTO _увеличил_ программу я вообще ни разу не встречал. Я специально не проверял, но думаю это вполне вероятно при агрессивной оптимизации и большом количестве мелких функций.
	Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

	61. "Выпуск утилиты для резервного копирования rclone 1.35"	–2 +/–
	Сообщение от Аноним (??) on 04-Янв-17, 20:51
	> Вообще-то обычно все исходники содержат оптимизацию в системах сборки. Но если кто вкатал свои CFLAGS то как они применятся в билдсистеме это отдельный вопрос. В результате пример какой-то не очень иллюстративный, чтоли: не видно что фактически получил компилер. > Обычно это -O2. Сейчас и -O3 в принципе попадается. Он быстрее, но более грабельный. > Это его побочное действие. Это "побочное" действие имеет свойство выносить туеву хучу кода. > Основное как раз inline и прочие подобные оптимизации. Я так понимаю что он может угрохать всякие сохранения регистров и проч которые как бы нужны, если это совсем независимый модуль вызываемый совсем без допущений. А тут появляется full view как оно вызывается и можно обрубить сохранение регистров которые caller'ам были пофиг. Оно в результате более уже не независимый модуль и как попало вызывать уже не того. Ну и да, инлайнить можно, более информированно чем ранее. А почему нет? > one. This means, for example, that the inliner is able to > inline functions in bar.o into functions in foo.o and vice-versa. Ну да. И как я понимаю перегрузки регистров можно глобально обкусить, т.к. известно кто и как вызывает. А если перегрузки обкусить - объем кода, очевидно, убавится. > Я специально не проверял, но думаю это вполне вероятно при агрессивной оптимизации > и большом количестве мелких функций. В мелких функциях по идее инлайнинг как раз хорошая штука? Экономия на всяких прологах-эпилогах, никаких сохранений регистров. Сэкономили на сохранениях-восстановлениях, растратили на коде. Выполняется быстрее и полезнее. Если код мелкий то хорошо работает: код не пухнет но ускоряется. И у gcc вроде есть анализы когда и что выгоднее. На больших функциях выгода от инлайна незначительна т.к. оверхед на сопутствующие приседания небольшой, а пухнет сильно. А для мелочи как раз критично - время служебных операций может стать сравнимо с временем в функции. И сишники такое по жизни костыляли #define'ами. Но у них читаемость и форматирование на любителя, и вообще костыль.
	Ответить | Правка | ^ к родителю #57 | Наверх | Cообщить модератору

	66. "Выпуск утилиты для резервного копирования rclone 1.35"	+/–
	Сообщение от Mihail Zenkov (ok) on 04-Янв-17, 22:29
	> Это "побочное" действие имеет свойство выносить туеву хучу кода. На самом деле не так уж много (если код адекватный) - отдельные части функций, которые не используются. Больше всего выбрасывает -ffunction-sections -fdata-sections + -Wl,--gc-sections так как выкидывает неиспользуемые функции и данные целиком. >> Я специально не проверял, но думаю это вполне вероятно при агрессивной оптимизации >> и большом количестве мелких функций. > Если код мелкий то хорошо работает: код не пухнет но ускоряется. Зависит от того какой код. Допустим 10% уходило на вызов + сохранение + восстановление регистров. Мы инлайним эту функцию  10-100 раз - код растет. > И у gcc вроде есть анализы когда и что выгоднее. AFAIK зависит от агрессивности оптимизации, сам он точно рассчитать и предсказать не может. Для этого нужно исполнить код с типичными данными на входе. У gcc есть и такой режим (забыл как он называется). > На больших функциях выгода от > инлайна незначительна т.к. оверхед на сопутствующие приседания небольшой, а пухнет сильно. Не всегда. Например большая функция на несколько страниц с switch на кучу case. Она может быть разбита и преобразована в десятки мелких функций.
	Ответить | Правка | ^ к родителю #61 | Наверх | Cообщить модератору

	69. "Выпуск утилиты для резервного копирования rclone 1.35"	+/–
	Сообщение от Led (ok) on 05-Янв-17, 20:58
	>> Это "побочное" действие имеет свойство выносить туеву хучу кода. > На самом деле не так уж много (если код адекватный) - отдельные > части функций, которые не используются. > Больше всего выбрасывает -ffunction-sections -fdata-sections + -Wl,--gc-sections так > как выкидывает неиспользуемые функции и данные целиком. Слушай, лучше не пиши ничего про LTO. Ты ж в этом... мягко говря - плаваешь... жалко выглядишь. Пиши лучше про roxbox, паяльник и работу под root'ом.
	Ответить | Правка | ^ к родителю #66 | Наверх | Cообщить модератору

	70. "Выпуск утилиты для резервного копирования rclone 1.35"	+/–
	Сообщение от Mihail Zenkov (ok) on 05-Янв-17, 21:51
	И в чем я не прав? Напиши конкретно, по пунктам, с ссылками и примерами. Будет полезно и мне и другим. А то только переходить на личности и ср*ть на форуме горазд. За последний год ни одного поста конструктивного от тебе не увидел.
	Ответить | Правка | ^ к родителю #69 | Наверх | Cообщить модератору

	80. "Выпуск утилиты для резервного копирования rclone 1.35"	+1 +/–
	Сообщение от Аноним (??) on 10-Янв-17, 20:50
	> части функций, которые не используются. Я проверял на разном софте. 1) Упомянутый мной tweetnacl-lite, с которым я развлекаюсь засовывая его в cortex-M. Если с LTO собрать, но нигде не вызвать, LTO его выносит целиком. Ну то-есть от него ничего не остается. Если другого кода не было - я получаю пустой бинарь, состоящий из дефолтных vectors. Как еще эффективнее код выносить я даже и не знаю :) 2) В большом сложном бинаре на плюсах LTO вырубил примерно четверть кода. Как по мне так там с -flto -fwhole-program (whole-program имеет некие особенности, ахтунг) dead code вырубается очень даже. > Больше всего выбрасывает -ffunction-sections -fdata-sections + -Wl,--gc-sections так > как выкидывает неиспользуемые функции и данные целиком. Упомянутое вроде бы вырубает неиспользуемые функции просто в ноль. И особенности особенностями, а в типовых случаях не вижу никаих проблем. Законы мерфи не отменяли. > Зависит от того какой код. Допустим 10% уходило на вызов + сохранение > + восстановление регистров. Мы инлайним эту функцию  10-100 раз - код растет. Если мы вместо 10% на сохранение потратим это на инлайн - какая, собственно, разница? Единственным достижением станет более шустрый код, где прологи-эпилоги заменятся на мелкую функцию. А так там эвристика есть, IIRC, на предмет что выгоднее. Все это если не указан явно инлайн или ноинлайн, конечно же, там компилер будет следовать указаниям програмера. >> И у gcc вроде есть анализы когда и что выгоднее. > AFAIK зависит от агрессивности оптимизации, сам он точно рассчитать и предсказать не может. Не знаю как насчет точности но при решении инлайнить или нет если не было явного хинта, оценивается размер кода функции vs экономия от отсутствия пролога-эпилога и принимается решение, инлайнить или нет. На первый взгляд вполне разумно сделано. Пардон не помню где читал описание уровней и lto. > Для этого нужно исполнить код с типичными данными на входе. > У gcc есть и такой режим (забыл как он называется). Вы про profile-guided optimization чтоли? Это несколько другое. Они как-то геморно делаются и настолько круто мне, имхо, не надо. > Не всегда. Например большая функция на несколько страниц с switch на кучу > case. Она может быть разбита и преобразована в десятки мелких функций. Вполне возможно, но я не знаю насколько анализатор это умеет. Он умеет настолько много что всех его умений я не знаю.
	Ответить | Правка | ^ к родителю #66 | Наверх | Cообщить модератору

	81. "Выпуск утилиты для резервного копирования rclone 1.35"	–1 +/–
	Сообщение от Mihail Zenkov (ok) on 11-Янв-17, 01:09
	>> части функций, которые не используются. > Я проверял на разном софте. > 1) Упомянутый мной tweetnacl-lite, с которым я развлекаюсь засовывая его в cortex-M. > Если с LTO собрать, но нигде не вызвать, LTO его выносит > целиком. OK, я не верно сказал. LTO может вынести и функции целиком. Просто затраты (как CPU, так и RAM) на это будут гораздо большими, чем с -ffunction-sections -fdata-sections + -Wl,--gc-sections. Точно не помню, сколько памяти надо для сборки FF с LTO, но за 4GB перевалило давно. Если цель уменьшить бинарник - то и gc-sections хватит. Если цель скорость исполнения - однозначно LTO, но бинарник из-за inline может стать и больше. > Как по мне так там с -flto -fwhole-program (whole-program имеет некие особенности, > ахтунг) dead code вырубается очень даже. Ну на AVR я как раз -fwhole-program и использую. Она несовместима с LTO - используется вместо LTO. >> Зависит от того какой код. Допустим 10% уходило на вызов + сохранение >> + восстановление регистров. Мы инлайним эту функцию  10-100 раз - код растет. > Если мы вместо 10% на сохранение потратим это на инлайн - какая, > собственно, разница? Выигрываем 10% по скорости, проигрываем 900% - 9000% по памяти/кэшу. > Единственным достижением станет более шустрый код, где прологи-эпилоги > заменятся на мелкую функцию. А так там эвристика есть, IIRC, на > предмет что выгоднее. ХЗ как оно может оценить пользу от inline, не имея на входе типичных данных. Может эта функция вызывается раз в году? А память будет расходоваться всегда. > Не знаю как насчет точности но при решении инлайнить или нет если > не было явного хинта, оценивается размер кода функции vs экономия от > отсутствия пролога-эпилога и принимается решение, инлайнить или нет. Если я правильно понял из мана - то в основном все сводится к длине функции (можно подрегулировать руками) - если функция больше определенной длинны - inline не используется. > Вы про profile-guided optimization чтоли? Да оно. > Это несколько другое. Они как-то геморно делаются > и настолько круто мне, имхо, не надо. Зависит от задачи. В теории - имея типичные входные данные компилятор значительно лучше сможет выполнить оптимизацию. > Вполне возможно, но я не знаю насколько анализатор это умеет. Он умеет > настолько много что всех его умений я не знаю. Да, и постоянно новые способы добавляют. С циклами он вообще много интересного умеет. При выходе новых версий gcc часто примеры кода показывают и как он его хорошо разбирает и перекомпоновывает.
	Ответить | Правка | ^ к родителю #80 | Наверх | Cообщить модератору

	82. "Выпуск утилиты для резервного копирования rclone 1.35"	+/–
	Сообщение от Аноним (??) on 13-Янв-17, 08:16
	> OK, я не верно сказал. LTO может вынести и функции целиком. Это его нормальное состояние, я бы сказал. > Просто затраты (как CPU, так и RAM) на это будут гораздо большими, > чем с -ffunction-sections -fdata-sections + -Wl,--gc-sections. А это другой вопрос. В свежих gcc, кстати, LTO основательно разогнали а потребление RAM убавили. > Точно не помню, сколько памяти надо для сборки FF с LTO, но за 4GB перевалило давно. Вот это не знаю, не пробовал такого монстра. На 5-меговой софтине на плюсах лопало около гига памяти, чтоли. Кстати LTO агрессивно оптимизировали по ресурсам в gcc 5.x/6.x, да и скорость компиляции прилично подтянули, особенно на уровнях с оптимизацией. > цель скорость исполнения - однозначно LTO, но бинарник из-за inline может > стать и больше. В среднем по больнице результат таков что прога сдувается по размеру а скорость такая же или чуть лучше. Т.е. я бы больше радовался уменьщению кода. > Ну на AVR я как раз -fwhole-program и использую. Она несовместима с LTO - используется вместо LTO. Насколько я помню -fwhole-program это какой-то хинт LTO-оптимизатору на самом деле, что надо полный анализ по всей программе и можно сделать небезопасные маневры, так что снаружи функции вызывать будет нельзя. Но я не знаю что там на авр сейчас. У убунтуев и дебиана для них почему-то gcc древний, 4.9 чтоли. Для ARM у меня такой же версии как и системный. > Выигрываем 10% по скорости, проигрываем 900% - 9000% по памяти/кэшу. Не вижу, опять же. Если проигрыш по кэшу - должны быть просадки скорости как раз? Да и раз кода меньше - то и кэш свободнее? Можно конечно perf-ом потыкаться если принципиально. А еще - у cortex M кэша нет, микроконтроллеры же. > ХЗ как оно может оценить пользу от inline, не имея на входе типичных данных. Прикинув как этот размер кода vs заскипаный на этом пролог/эпилог соотносится? > Может эта функция вызывается раз в году? А память будет расходоваться всегда. Опять же - не вижу раздувания кода от LTO. > к длине функции (можно подрегулировать руками) - если функция больше определенной > длинны - inline не используется. Значит мой склероз мне не врет, как-то так. >> Вы про profile-guided optimization чтоли? > Да оно. Вот с ним я не разбирался. > Зависит от задачи. В теории - имея типичные входные данные компилятор значительно > лучше сможет выполнить оптимизацию. Оно как бы да, но возни много. Ну его такое кроме крайних случаев. > Да, и постоянно новые способы добавляют. С циклами он вообще много интересного > умеет. При выходе новых версий gcc часто примеры кода показывают и > как он его хорошо разбирает и перекомпоновывает. У gcc нынче один только ман на командлайн читать можно устать :) зы мне надоели местные модеры, меня они потерли раза три а красования леда по жизни не трогают, давайте может куда-нибудь на ресурс с более комфортной атмосферой, а? я от такой модерации устал, она не способствует конструктивным дискуссиям, вообще совсем.
	Ответить | Правка | ^ к родителю #81 | Наверх | Cообщить модератору

	45. "Выпуск утилиты для резервного копирования rclone 1.35"	+/–
	Сообщение от Аноним (??) on 04-Янв-17, 07:42
	Ага, от BIOS с EFI ещё зависит.
	Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

	73. "Выпуск утилиты для резервного копирования rclone 1.35"	+/–
	Сообщение от anoni on 06-Янв-17, 00:24
	> А ничего, что rsync зависит, как минимум, от libc, popt и еще чего-то? О, а это Go-вно не зависит от libc? Т.е. оно у меня под BSD запустится?
	Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

	76. "Выпуск утилиты для резервного копирования rclone 1.35"	–1 +/–
	Сообщение от Nas_tradamus (ok) on 09-Янв-17, 18:31
	Что за BSD без libc? :)
	Ответить | Правка | ^ к родителю #73 | Наверх | Cообщить модератору

	22. "Выпуск утилиты для резервного копирования rclone 1.35"	+5 +/–
	Сообщение от Аноним (??) on 03-Янв-17, 15:55
	> 12568032, стрипнутый, амд64 > в чем вопрос то ? Лол, его самого такой в пору инкрементально синхронизировать. Скоро на сидюк помещаться перестанет :)
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	23. "Выпуск утилиты для резервного копирования rclone 1.35"	+/–
	Сообщение от Аноним (??) on 03-Янв-17, 16:31
	двоим-обоим сверху ничего что он статик ? собери гцц в динамике, а не родным и будет тебе счастье потому повторю > в чем вопрос то ?
	Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

	24. "Выпуск утилиты для резервного копирования rclone 1.35"	+/–
	Сообщение от freehck (ok) on 03-Янв-17, 16:48
	> двоим-обоим сверху > ничего что он статик ? Ммм, как своевременно. Нет, чтобы написать об этом сразу.
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	25. "Выпуск утилиты для резервного копирования rclone 1.35"	+/–
	Сообщение от Аноним (??) on 03-Янв-17, 16:54
	ути пути если влез в обсуждение то хотя бы знай особенности языка о котором рассуждаешь
	Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

	29. "Выпуск утилиты для резервного копирования rclone 1.35"	–2 +/–
	Сообщение от Аноним (??) on 03-Янв-17, 17:46
	А оно уже осилило динамическую линковку? Или как обычно "не работает - значит не нужно"?
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	33. "Выпуск утилиты для резервного копирования rclone 1.35"	+/–
	Сообщение от _ (??) on 03-Янв-17, 18:14
	Ручками - да. Обеща.т как нить сделать. Видимо из тех кто может сделать, а не ныть не нашлось таких кому вот прямо позарез ... :-)
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

	42. "Выпуск утилиты для резервного копирования rclone 1.35"	+/–
	Сообщение от Аноним (??) on 03-Янв-17, 22:41
	> Обещают как нить сделать. Видимо из тех кто может сделать, а не обещать не нашлось таких кому вот прямо позарез нужен go ... :-) fxd.
	Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

	46. "Выпуск утилиты для резервного копирования rclone 1.35"	+2 +/–
	Сообщение от Аноним (??) on 04-Янв-17, 10:40
	> ничего что он статик ? Бинарь на 12 метров даже статиком не каждый день увидишь. > собери гцц в динамике, а не родным и будет тебе счастье Да мне и с rsync хорошо, он даже на 8Мб флеху роутера умещается. Там в 8 мегах вся система живет. Ну и пакет с рсинком до кучи чтобы на usb-хард бэкапаться. Телефон, понимаешь, рсинком сливает нафотканое когда замечает нужную сеть.
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

3. "Выпуск утилиты для резервного копирования rclone 1.35"	–2 +/–
Сообщение от Аноним (??) on 03-Янв-17, 11:07
> Yandex Files Яндекс.Диск же
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

5. "Выпуск утилиты для резервного копирования rclone 1.35"	+2 +/–
Сообщение от Аноним (??) on 03-Янв-17, 12:55
Прикольная игрушка, но 1) где ownCloud? 2) все эти разношёрстные костыли не решают вопроса непосредственно резервного копирования, о чём написано в шапке. Кстати по резервному копированию, bacula (к тому же сильно тухлая открытая версия) и amanda решают его лишь частично. Например они не дают готовый инструмент для создания бекапа 3-2-1, с бекапом БД там беда, приходится костылить скрипты буквально под каждый проект. bacula не умеет VSS (в сети же разные ОС в наличии). И в конечном счёте из-за того что они заточены под ленты нельзя потом получить прямой доступ к файлам в бекапе, только средствами самих bacula/amanda можно что-то вытащить, тогда как иногда хочется некоторые файлы быстро сравнить по правкам, что сейчас есть и что было например неделю назад, или просто выборочно из файл-менеджера восстановить некоторые файлы. Да и вообще было бы удобно предоставить доступ к своим бекапам участникам каждого проекта напрямую, чтобы админа на каждый чих не дёргали. Может кто подскажет какое-нибудь более годное ПО из открытого для решения этих проблем?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	7. "Выпуск утилиты для резервного копирования rclone 1.35"	+/–
	Сообщение от Crazy Alex (ok) on 03-Янв-17, 13:05
	Самопальные скрипты на базе rsync решают обычно. Кстати, что ужасного в скриптах под проект? Не по паре в день же писать их, а специфику учесть - самое оно. Если не на шелле, то вполне живой вариант. А бакулы разные - больно уж вещь в себе.
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	12. "Выпуск утилиты для резервного копирования rclone 1.35"	–1 +/–
	Сообщение от Аноним (??) on 03-Янв-17, 14:20
	>> что ужасного в скриптах под проект? - Нужно время на разработку, тестирование и сопровождение, на каждый проект, на каждое изменение в инфраструктуре, плюс ошибки, которые часто всплывают уже когда всё пропало (из серии "упс, а бекап оказывается работал только первую неделю"); - Каждый проект лопатить, когда проектов становится много, становится весьма напряжно; - В сети машины с разными ОС, не везде rsync есть из коробки, т.е. нужно тащить ещё телегу софта, ломать мозг как защищать доступы, плюс портированный под win софт иногда весьма странно работает; - rsync опять же не умеет работать с VSS (ака Volume Snapshot Service); Опять же без шквала костылей не решает создание нескольких копий (3-2-1 в т.ч.), отдельно дописывать придётся отправку внятных уведомлений в почту, отдельно ротацию старых бекапов (если не неделю хранить, а по датам) И если не на шелле идущем с ОС, то на чём? Тягать с собой по всем машинам ещё кучу софта просто чтобы костыли хотябы запускались? Нужно что-то централизованно управляемое
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	16. "Выпуск утилиты для резервного копирования rclone 1.35"	–1 +/–
	Сообщение от Crazy Alex (ok) on 03-Янв-17, 15:02
	Я, конечно, с бакулой давненько дела не имел, но насколько я помню он по неудобству настройки скриптам сто очков форы даст. И настраивать при изменениях в инфраструктуре что угодно надо будет. rsync не ставится одной командой разве что на винде, и то не уверен. Её я обсуждать не готов - сто лет с ней дела не имел, но там по жизни была своя отдельная боль с бэкапом вроде. Крайне сомнительно, что её удастся в одну кучу с никсовыми решениями запихнуть. То, что в дальше упоминаете - не шквал костылей, а своя (довольно небольшая) библиотека, пишется один раз и потом подключается во все скрипты. Всё вместе в тысячу строк на перле или питоне. Которые есть на любых никсах, винда, как я говорил выше, всегда была "особенной". А вот мечты о централизованном управлении бэкапом (и не только) для кучи проектов (которые неизбежно получаются разнородными), собственно, порождают массу костылей, когда оказывается, что одно "универсальное" решение не годится ни для какого частного случая. Собственно, я даже более сильно сформулирую: все "админские" подходы к бэкапу данных приложения, не интегрированные в само приложение - это поиск проблем, от неконсистентности с чем-то внешним до забытых частей, которые надо было бы бэкапить. Если уж у вас "проекты", бэкап должен быть в их коде и учитываться с самого начала - с архитектуры.
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	26. "Выпуск утилиты для резервного копирования rclone 1.35"	+1 +/–
	Сообщение от Аноним (??) on 03-Янв-17, 17:02
	Поэтому всякие симантеки с своими backup exec и будут получать копеечку. Твоя наколенная самопальщина - подстава для компании если ты вдруг уволишься. Потому что могущих и желающих разбираться в твоих отрыжках на помеси гадюки с верблюдом скорее всего за разумное время и деньги не найдется вообще. А какой-нибудь backup exec таки все это умеет. И vss, и чуть ли не все типовые базы бывающие в энтерпрайзах, и пяток разных операционок. Без всего этого булшита про особенных и что там еще. Пардон, программа должна выполнять свою работу а не разводить вэйности и парадигмы. И централизованное управление там есть. И не надо его изобретать самому. И на 500 виндовых машин бэкапный агент вкидывать все-таки вручную не придется, в оличие от лабуды на go или каком там питоне, где ты еще и сетап-девом быренько поработаешь. Узнав много нового о том как круто устанавливать на винду бидон самому. Особенно парочке девов у которых уже была какая-то своя версия и все загнулось, потому что они особенные. Оно конечно в меру кривое и нифига не гибкое правда, но тут уж кому что. Многим корпорасам таки хватает. Такого софта есть несколько десятков наименований, backup exec просто как наименее кривой. А то какие-нибудь бимеры поучат вас до кучи DB2 админить, просто потому что не придумали ничего умнее как всучить его с своей софтиной. А то что ваши операторы бэкапов мечтали стать DBA под айбиэмовскую базу - вот это ну совсем не факт :)
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	38. "Выпуск утилиты для резервного копирования rclone 1.35"	+/–
	Сообщение от Crazy Alex (ok) on 03-Янв-17, 20:00
	Плюйся ядом меньше. Можно сколько угодно пытаться бэкапить раздел или  даже базу, но если ты не знаешь, что вот для таких-то сущностей должна быть синхронизация с тем-то внешним софтом, вот здесь особые процедуры, так как завязано на TPM, тут нужно предварительно пнуть систему чтобы всё засинхронизировалось, а здесь надо учесть шардинг - то урода ты получишь, а не бэкап. А на винде нынешний софт не держат - потому что она только на десктопах у юзеров живёт, а реальный софт - на никсах, и они его в браузерах видят. И так - как раз для того, чтобы не возиться с пятком платформ и особенностями питона на винде. Виртуалки там всякие, контейнеры - слышал о таком? Но если надо поддерживать кучу замшелой дряни - то да, всё как ты описал.
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

	50. "Выпуск утилиты для резервного копирования rclone 1.35"	+1 +/–
	Сообщение от Аноним (??) on 04-Янв-17, 11:46
	> Плюйся ядом меньше. Да какой это яд? Так, капитанинг и констатация того факта что благодаря такой ситуации бэкапэкзеки и ко - были, есть и будут есть. Ну и в окружении с теми же виндами фиг с два ты какую-нибудь активную директорию сбэкапишь например наколенщионй. А если AD завалится - вся контора кирпичами изорсется. Упомянутые то софтины умеют бэкапить хоть черта лысого, ну и это до кучи. > Можно сколько угодно пытаться бэкапить раздел или  даже базу, но если > ты не знаешь, что вот для таких-то сущностей должна быть синхронизация > с тем-то внешним софтом, вот здесь особые процедуры, так как завязано > на TPM, тут нужно предварительно пнуть систему чтобы всё засинхронизировалось, а > здесь надо учесть шардинг - то урода ты получишь, а не бэкап. В принципе то все так. Но попробуй вообще бэкапнуть питоноперловкой какую-нибудь AD и что там еще. И чтоб через VSS, ну вон народу нравится же. Нужность делать что-нибудь такое конечно сильно зависит от окружения, но если уж кто полез в бяку, слов из песни не выкинешь. И у них там всякие AD и Exchange бывают. Немного не то что можно забэкапить наколенным скриптом и чтобы потом еще и не пожалеть об этом. А еще - такие софтины придумали быстрые и эффективные способы сбора бэкапов. Какой-нибудь скрипт дергающий какой-нибудь интерфейс базы для выгрузки из нее дампа это круто, но его скорость работы полный швах. Можешь поинтересоваться сколько времени занимают вякие выгрузки википедий и прочих OSMщиков. Эти как-то живут да и требования у них не только бэкапные. Но вот корпоративщиков такое далеко не всегда прет а более нормальные технологии бэкапа отрабатывают в РАЗЫ быстрее. И таки не прикольно если пора запускать новый бэкап, а у тебя старый все еще вкалывает. > А на винде нынешний софт не держат - потому что она только > на десктопах у юзеров живёт, а реальный софт - на никсах, Ну это еще повезло с окружением что там всяких AD и прочих Exchange нету. Хотя как показывает пример OSMщиков и википедиков - на *никсах тоже можно have it hard. С выгрузкой из базы продолжительностью этак в НЕДЕЛЮ. Бэкап можно было бы сделать и за какие-нибудь часы, если на блочном уровне + ништяки. А если трекать отличия между блоками то еще и весило бы весьма умеренно. Но это уже не уровень хни на бидоноперле, извините. Там придется разобраться с внутренней механикой и понять как это делать правильно. На коленке такую логику по бырому не набросаешь. А если сдуру набросаешь то семь раз пожалеешь потом. И оно хорошо если у тебя там база размером с кошкин зад, две виртуалки и полтора компа. Там пофиг. А если рельсу? :) Да и даже просто винду сриптиком на питоне не сбэкапишь. Ну вон файлы реестра извините открыты все время и прочитать их стандартными методами вообще невозможно. А без реестра какой это бэкап? А при словах типа VSS скриптеры дружно делают ноги. На пингвинах на самом деле такая же фигня. По крайней мере, апи для freeze записи в файлуху в лине таки запилили. Угадай блин с трех раз зачем. > и они его в браузерах видят. И так - как раз для того, чтобы не возиться > с пятком платформ и особенностями питона на винде. Виртуалки там всякие, > контейнеры - слышал о таком? Ну да. И их бэкапирование правильно и эффективно - отдельное приключение. Особенно когда их становится дохрена и хочется чтобы сбор бэкапов не занимал неделю, а бэкапы не весили over 9000 терабайтов. Не в обиду наколенщикам, скриптик работает значительно хуже специализированных софтин где таки заморочились эффективностью операций, разобравшись в внутреннем устройстве того что бэкапят и как это эффективно и результативно окучивать. > Но если надо поддерживать кучу замшелой дряни - то да, всё как ты описал. А ты иди и покажи как базу размером с википедии твоим наколенным авангардом ворочать, если такой умный. А то был тут чувак - бедный буратино. Тоже, понимаешь, питонист. Ну и известен чувачок тем что цуко месяц таскал ноут обеспечивая бесперебойное питание. В надежде вгрузить дамп такого размера в мускул вообще не утруждая свой мозг. Через месяц у него вроде таки факапнулось, да :). Ну в общем этот ваш авангард обычно работает как-то вот так.
	Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

	43. "Выпуск утилиты для резервного копирования rclone 1.35"	–1 +/–
	Сообщение от Михрютка (ok) on 03-Янв-17, 22:47
	> Поэтому всякие симантеки с своими backup exec и будут получать копеечку. Твоя > наколенная самопальщина - подстава для компании если ты вдруг уволишься. Потому > что могущих и желающих разбираться в твоих отрыжках на помеси гадюки > с верблюдом скорее всего за разумное время и деньги не найдется > вообще. А какой-нибудь backup exec таки все это умеет. упырьте мел, коллега. в моих отрыжках на помеси гадюки с верблюдом, как вы поэтично выразились, не разобрался никто за семь лет, пока эти отрыжки обеспечивали продуктив. ну вот не повезло мне работать в вашей организации, коллега, где, видимо, без лишних вопросов насыпают денег на промышленные поддерживаемые решения. и где бы мне, без сомнения, обюджетили бы бы все мои жалкие несколько десятков разделов. просто, чтоб сделать вам приятно, сообщу - вернувшись через семь лет в эту организацию, и имея лицензию на проприетарное решение, я вывел мою отрыжку из эксплуатации и заменил ее на софт, который не требует всех этих адских обвязок на верблюде. после семи лет успешной эксплуатации, с регулярными восстановлениями, не требующими простоя,и с суммарным простоем продуктива на время восстановления 3 суток. неплохо для отрыжки уволенного автора, как на мой взгляд. а то, что в этом решении никто не стал разбираться - ну так в промышленном софте тоже желающих разбираться не нашлось, последний оператор после аппаратного отказа просто остановил сервер бэкапов, написал заявление и уволился. И vss, > и чуть ли не все типовые базы бывающие в энтерпрайзах, и > пяток разных операционок. пяток разных операционок в отношении к backup exec - это, наверное, Windows, Windows, Windows, Windows и Macos? (причем про macos я не уверен) потому что их агент для линуп^Hксь чо-то как-то не очень френдли оказался, развернули его аж на одном хосте, и то потом забили. про типовые базы в ынтерпрайзах - особое спасибо, то-то когда потребовалось из бэкапа mssql поднять копию на удаленной площадке, пришлось по старинке делать, без всяких vss и backup exec. это наверняка потому, что никто не хочет разбираться в гадюках и верблюдах, а backup exec интутивно понятно же и копеечка. > Такого софта есть несколько десятков наименований, backup exec просто как наименее кривой. > А то какие-нибудь бимеры поучат вас до кучи DB2 админить, просто > потому что не придумали ничего умнее как всучить его с своей > софтиной. А то что ваши операторы бэкапов мечтали стать DBA под > айбиэмовскую базу - вот это ну совсем не факт :) ну правильно backup exec небось свою базу в sqlite хранит, или еще лучче в текст файлах? а мы по старинке с dsmadmc и select мучаемсо. единственно у меня с select-то быстрее выходит сказать, какой там у клиентов тренд по объему данных на пулах, чем у админа backup exec с его html красивыми отчотами. а так да, select зло и базу бэкапа бэкапить приходится. пичаль, что.
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

	52. "Выпуск утилиты для резервного копирования rclone 1.35"	+/–
	Сообщение от Аноним (??) on 04-Янв-17, 14:18
	> организации, коллега, где, видимо, без лишних вопросов насыпают денег на промышленные > поддерживаемые решения. Таки более-менее крупные компании усвоили некоторые простые вещи. Кто по хорошему, кто после пары злых факапов. Самое смешное что бэкапный софт весьма умеренно пиратят. Саппорт не пиратится, а без саппорта такие вещи... > и где бы мне, без сомнения, обюджетили бы бы все мои жалкие несколько десятков разделов. С другой стороны вон тут буратино вгружал дамп мускуля месяц. Неуспешно. Питонисты - это вот так. > всех этих адских обвязок на верблюде. после семи лет успешной эксплуатации, > с регулярными восстановлениями, не требующими простоя, Если оно работает и устраивает - то и фиг с ним. Но вот бывает что попадаются тут бедные буратины, вгружающие от большого ума дамп вики месяц. И таки не осиливающие совсем. В этом случае наступает момент признать что технологии и подходы - EPIC FAIL. > на время восстановления 3 суток. неплохо для отрыжки уволенного автора, как на мой взгляд. Ну по крайней мере это не ББ с зафэйленной через месяц вгрузкой БД. > так в промышленном софте тоже желающих разбираться не нашлось, последний оператор > после аппаратного отказа просто остановил сервер бэкапов, написал заявление и уволился. В промышленном софте разбирающихся все-таки есть и не настолько уникальны. А еще у них саппорт есть. И это именно тот случай когда за саппорт может иметь смысл заплатить. Не круто если все упало, а чувак которые писал мегашнягу - умотал на Бали на месяц. > пяток разных операционок в отношении к backup exec - это, наверное, Windows, > Windows, Windows, Windows и Macos? (причем про macos я не уверен) Промышленный софт к пингвинам и макосям относительно нормально относится. Иной раз может быть и что-нибудь поэкзотичнее, типа aix'а и соляр каких. В общем что клиентура просит то и делают. Чем больше просят тем лучше делают. Логично. А как бэкапать хайку - разбирается кому приспичило. Тут уж без вариантов. > потому что их агент для линуп^Hксь чо-то как-то не очень френдли оказался, > развернули его аж на одном хосте, и то потом забили. На самом деле варьируется по вендорам и версиям. А что до френдельности так кусок питона или перла обладает нулевой, если не отрицательной френдельностью по отношению ко всем кроме своего автора. В нем заведомо не разбирается ни один человек на планете. И наверное если что-то пошло не так - последнее что людям в режиме аврала хочется это вдуплять в чей-то там среднего пошиба (в лучшем случае) код, эмулируя из себя вендыря бэкапного софта и их саппорт у себя in house. Это конечно от ситуации зависит - какие-нибудь девопсы могут сгородить вменяемое решение под вот конкретно эту свою мега-инсталляцию. Но они не будут заниматься бэкапами виндовых десктопов у дизайнеров до кучи. > про типовые базы в ынтерпрайзах - особое спасибо, то-то когда потребовалось из > бэкапа mssql поднять копию на удаленной площадке, пришлось по старинке делать, > без всяких vss и backup exec. это наверняка потому, что никто > не хочет разбираться в гадюках и верблюдах, А все просто: в backup exec и mssql для таких развлечений таки придется немного разобраться. И поэтому операторы бэкапов по нормальному отдельная профессия. А если у вас там был один эникей на все - вы и получаете то самое. И таки раскладывать сиквеля по файликам - вы там спросите DBA чем все это чревато и какие там заморочки с консистентностью и проч. Потому что "если вам кажется что дела идут хорошо - значит вы просто чего-то не заметили". Движки баз такая штука что вы или разбиретесь как они работают и как их правильно ресторить или вы таки курите на бочке с порохом и даже если у вас просто распихать файлы в диру прокатило - это еще не значит что это работоспособный и безопасный способ так делать и что не будет side effects. Базы данных забавные штуки. Особенно весело если база жирная и поэтому в ходу технологии типа дифф бэкапов - в этом случае без понимания работы движка можно серьезно залететь. В общем не эникейский это уже уровень и скриптиками там можно и не отделаться. Ну это так, если людей интересовали быстрые/компактные бэкапы, и восстановление все-таки не через месяц, как у буратины. > а backup exec интутивно понятно же и копеечка. Все познается в сравнении. А питоноперлоскрипты - это, извините, вообще из разряда "свое не пахнет". В этом разбирается 1 человек на планете - их автор. Ну или несколько человек в лучшем случае. > ну правильно backup exec небось свою базу в sqlite хранит, или еще > лучче в текст файлах? а мы по старинке с dsmadmc и select мучаемсо. Бимерская ета зарекомендовала себя склонной к издыханию и глюкам по поводу и без. А потом операторам бэкапов приходится осваивать несвойственные функции, если в энтерпрайзе не было DBA по db2. Наверное это сложно назвать достоинством. При том это только в относитльно новых версиях, где бимеров укусил майкрософт с скуль сервер компактом и они тоже подорвались втюхивать свои базы всем, по образу и подобию. Маркетинговый булшит, бессмысленный и беспощадный. Единственным достижением стали сотни ненависти от бэкапных операторов. Если кто думал что они резко станут бимерскими DBA - по-моему эти надежды совершенно не оправдались. Как и с компактом, где мс вообще в результате устроил всем сказочный кидок. > единственно у меня с select-то быстрее выходит сказать, какой > там у клиентов тренд по объему данных на пулах, Простите, в типичной бэкапной системе все это всем глубоко ПО-Ю. Настраивается шедулинг бэкапов, ротация и все такое, и система требует минимум внимания. Вспоминают про это в основном когда что-то навернулось или надо новых клиентов добавить. Откуда в принципе и следует возможность сгрузить на бэкап операторов какие-нибудь смежные административные функции по движкам или системам которые они знают. Но все-таки это не эникеи, "и упаси тебя перепутать хиппи с толкиенистом". > чем у админа backup exec с его html красивыми отчотами. а так да, > select зло и базу бэкапа бэкапить приходится. пичаль, что. ИМХО от бэкапного софта требутся все-таки не отчеты и даже не select прежде всего. Знаете, если у вас пожар - вас от пожарного крана интерсует наличие воды и шланга. А то что он видите ли не совсем правильно покрашен и надпись не по фэншую - может и хрен бы с ним в этом случае, а?
	Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

	68. "Выпуск утилиты для резервного копирования rclone 1.35"	–1 +/–
	Сообщение от Михрютка (ok) on 05-Янв-17, 00:34
	> Таки более-менее крупные компании усвоили некоторые простые вещи. Кто по хорошему, кто > после пары злых факапов. Самое смешное что бэкапный софт весьма умеренно > пиратят. Саппорт не пиратится, а без саппорта такие вещи... ...работают и хлеба не просят. в самом страшном случае их нельзя легально обновить на новый мажор, если вас парит compliance и аудит. если проблема не проявилась до истечения срока поддержки, изменение конфигурации, вызвавшее баг, быстренько откатывается и дальше решается по месту, так ли оно необходимо. > С другой стороны вон тут буратино вгружал дамп мускуля месяц. Неуспешно. Питонисты > - это вот так. у меня был сотрудник, который три месяца пытался восстановить базу oracle из резервной копии на удаленную площадку. так и не восстановил. я не стал делать из этого глобальные выводы про ПО оракл и dba оракла. >> так в промышленном софте тоже желающих разбираться не нашлось, последний оператор >> после аппаратного отказа просто остановил сервер бэкапов, написал заявление и уволился. > В промышленном софте разбирающихся все-таки есть и не настолько уникальны. А еще > у них саппорт есть. И это именно тот случай когда за > саппорт может иметь смысл заплатить. Не круто если все упало, а > чувак которые писал мегашнягу - умотал на Бали на месяц. коллега, не заблуждайтесь, случай не требовал сопровождения от слова совсем. требовалось просто прочитать РЭ. опять, мне оказалось заплатить дешевле. учитывая, что поддержка никогда не занимается проблемами класса PEBKAC, это скорее задачи аксентур и прочих пвх. мой пойнт в том, что брейнфак код можно писать на любом языке и конфигурации. мой пойнт, что никакая "промышленная" система не спасет от неквалифицированных и безответственных операторов. что толку, что я сдал СРК с РЭ, заботливо написанным по всем канонам СКД, если человек, у которого возникли вопросы по эксплуатации, даже не удосужился заглянуть ни в него, ни в документацию вендора, ни в конфигурацию системы? многабукав ниасилил, как раньше говорили. верно и обратное - никакое "самопальное" ПО не испортит хорошего инженера и не помешает ему спроектировать качественнное решение, закрывающее вопросы заказчика. HACMP полно адских скриптов на ksh чуть более чем наполовину, это не мешает ему быть а) проприетарным б) поддерживаемым и в) вполне работоспособным решением. > А все просто: в backup exec и mssql для таких развлечений таки > придется немного разобраться. И поэтому операторы бэкапов по нормальному отдельная профессия. > А если у вас там был один эникей на все - > вы и получаете то самое. И таки раскладывать сиквеля по файликам > - вы там спросите DBA чем все это чревато и какие > там заморочки с консистентностью и проч. Потому что "если вам кажется > что дела идут хорошо - значит вы просто чего-то не заметили". я не знаю, какие заморочки с консистентностью и т.п. в BE+MSSQL и не горю желанием разбираться, пока я не owner этих систем. я знаю, что на текущем месте работы через rman+tdpo я делаю бэкап своих систем в предсказуемое время и в предсказуемое время делаю восстановление. через вполне себе читаемый скрипт на перле, написанный моим коллегой. который прекрасно совмещается с промышленным и вполне себе ынтерпрайзным ПО. и база нормально стартует и не жалуется на неконсистентность. я только не совсем понимаю, почему не аникейщик, а именно что бэкап администратор на BE не в состоянии восстановить мне базу mssql без непредсказуемых задержек. видимо, у них там свой питон встроенный? или может, использование могучего проприетарного софта еще не залог успеха? может, кадры все-таки решают, как говорил вождь и учитель? > Бимерская ета зарекомендовала себя склонной к издыханию и глюкам по поводу и > без. А потом операторам бэкапов приходится осваивать несвойственные функции, если в > энтерпрайзе не было DBA по db2. Наверное это сложно назвать достоинством. вам это рабинович напел или вы на собственный опыт опираетесь? бо мой персональный опыт как раз говорит об обратном. единственные случаи, когда мне пришлось вспоминать о db2 при работе с tsm, в основном относились к наладке ha кластеров, и это не называлось "несвойственные функции", это называлось "обеспечить работу одного инстанса db2 на двух или более разных хостах". в остальном db2 ведет себя тихо и смирно. как и любая другая БД пока в нее не лезут шаловливые ручки локальных девелоперов. >> единственно у меня с select-то быстрее выходит сказать, какой >> там у клиентов тренд по объему данных на пулах, > Простите, в типичной бэкапной системе все это всем глубоко ПО-Ю. Настраивается шедулинг > бэкапов, ротация и все такое, и система требует минимум внимания. Вспоминают > про это в основном когда что-то навернулось или надо новых клиентов > добавить. Откуда в принципе и следует возможность сгрузить на бэкап операторов > какие-нибудь смежные административные функции по движкам или системам которые они знают. > Но все-таки это не эникеи, "и упаси тебя перепутать хиппи с > толкиенистом". в моих типичных СРК не ПО-Ю, как вы пишете, такие показатели, как RTO, например. если вы умеете это определять божьим духом с минимумом внимания, запишите меня на свой семинар плз. ротация как раз беспокоит меньше всего, при отстутствии требований комплаенса или конкретных требований клиента на это можно смело забить. добавление новых клиентов тем паче не моя задача, а задача провизионирования. моя задача, чтобы активные данные начали восстанавливаться в течение 10-15 минут с момента запроса на восстановление и восстановились в указанное мной время. > ИМХО от бэкапного софта требутся все-таки не отчеты и даже не select > прежде всего. Знаете, если у вас пожар - вас от пожарного > крана интерсует наличие воды и шланга. А то что он видите > ли не совсем правильно покрашен и надпись не по фэншую - > может и хрен бы с ним в этом случае, а? иногда от таких отчетов зависит вообще наличие пожарного крана. теперь, как на это влияет то, запускает диспетчер бэкапов бэкап на клиенте бэкап агентом по конфигурации или скриптъ какой нибудь на питоне/перле/портянкобаше/тикле/визуляр-барсике/жабаскрипте/систэмдэ/что-там-ненавидят-на-лоре-на-этой-неделе? мне что-то кажется, что никак. как влияет на RPO+RTO открытость/закрытость кода решения или его сопровождение красной/голубой-в-полосочку/бородатой-с-рогами конторой? мне что-то кажется, что никак. война окончилась, всем спасибо, все свободны.
	Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

	51. "Выпуск утилиты для резервного копирования rclone 1.35"	+/–
	Сообщение от commiethebeastie (ok) on 04-Янв-17, 14:08
	>rsync опять же не умеет работать с VSS (ака Volume Snapshot Service); Через vscsc зато умеет.
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	19. "Выпуск утилиты для резервного копирования rclone 1.35"	+/–
	Сообщение от Аноним (??) on 03-Янв-17, 15:21
	> Собственно bacula - лучшее, что есть Bareos?
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	30. "Выпуск утилиты для резервного копирования rclone 1.35"	+/–
	Сообщение от Аноним (??) on 03-Янв-17, 17:48
	То же самое, вид сбоку. С незначительными улучшениями в виде "пассиовного режима", который пока всё равно шибко экспериментален.
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	31. "Выпуск утилиты для резервного копирования rclone 1.35"	+/–
	Сообщение от Аноним (??) on 03-Янв-17, 17:50
	http://burp.grke.org
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	62. "Выпуск утилиты для резервного копирования rclone 1.35"	+/–
	Сообщение от Аноним (??) on 04-Янв-17, 20:55
	> http://burp.grke.org О, забавная штука. Кто-то решил таки запилить более-менее нормальную бэкапалку и еще и открытую к тому же. Самопальненько, но задатки у человека очень даже ничего.
	Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

	67. "Выпуск утилиты для резервного копирования rclone 1.35"	+/–
	Сообщение от bac on 04-Янв-17, 23:19
	> И в конечном счёте из-за того что они заточены под ленты нельзя потом получить прямой доступ к файлам в бекапе, только средствами самих bacula/amanda можно что-то вытащить, Частично враньё. Аманда это tar и все, что вокруг него вертится. Руками вытащить не проблема. Даже если зашифровано самой амандой.
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

8. "Выпуск утилиты для резервного копирования rclone 1.35"	+2 +/–
Сообщение от Crazy Alex (ok) on 03-Янв-17, 13:08
Так себе штуковина. Оно работает, да, но, как минимум, для Amazon Cloud там алгоритм детекта ошибок и реакции на них шибко странный, порождающий в некоторых случаях кучу ретрансмитов. Причём "красиво" пофиксить его малой кровью не вышло, только адским костылём (правда, я не знаток Go ни разу - но там скорее переписывать логику надо). И логирование на редкость гнусное. В общем же - чем этот "швейцарский нож" лучше  FUSE-based софт использовать. Его родная поддержка FUSE, кстати, печальна (опять же - как минимум, для Amazon Cloud) - попытки на любой чих заново выкачивать метаданные чуть ли не для всего хранилища оборачиваются адскими тормозами.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	11. "Выпуск утилиты для резервного копирования rclone 1.35"	–1 +/–
	Сообщение от Плохой Клоун on 03-Янв-17, 13:43
	https://minio.io/
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	20. "Выпуск утилиты для резервного копирования rclone 1.35"	+/–
	Сообщение от Crazy Alex (ok) on 03-Янв-17, 15:35
	И при чём здесь эта хрень?
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

9. "Выпуск утилиты для резервного копирования rclone 1.35"	+4 +/–
Сообщение от CHERTS (??) on 03-Янв-17, 13:15
1. Сливаем все что нужно с удалённых серверов с использованием rsync на центральный сервер бэкапов 2. На центральном сервере бэкапов ZFS 3. Делаем какой нужно алгоритм создания снапшотов на ZFS 4. Profit Что имеем: 1. В любой момент легко и без танцев с бубном можно вытащить любой файл, каталог исходного сервера 2. В любой момент легко можно сравнить различия между файлами или целыми каталогами между разными снапшотами 3. Минимум автоматизации и геморроя с настройкой - простота схемы - залог надежной работы Минусы: 1. Нет любимого всеми GUI и Web морды - а зачем они если есть ssh? 2. На сервере бэкапов нужно мнооооошо ОЗУ для норм. работы ZFS - не критичный минус, хотя если сервер HP и память регистровая с кор. ош. , то 32-64 Гбайт будут не дешовыми.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	10. "Выпуск утилиты для резервного копирования rclone 1.35"	+/–
	Сообщение от Crazy Alex (ok) on 03-Янв-17, 13:20
	Так оно примерно с теми же трудозатратами и самим rsync делается же с --link-dest
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	15. "Выпуск утилиты для резервного копирования rclone 1.35"	+1 +/–
	Сообщение от Аноним (??) on 03-Янв-17, 14:40
	> Так оно примерно с теми же трудозатратами и самим rsync делается же > с --link-dest Если файл в бекапе кто-то намеренно поправит, поплывут все залинкованные бекапы. Со снапшотом это не прокатит. Контрольные суммы бекапа придётся костылить отдельно (тогда как ZFS это сделает сама). Можно сжатие включить и дедупликацию без бубнов. Но в целом они хорошо работают в паре, rsync эффективно синхронизирует файлы с удалённой машиной, а ZFS обеспечивает хороший storage.
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	75. "Выпуск утилиты для резервного копирования rclone 1.35"	–1 +/–
	Сообщение от PnDx (ok) on 09-Янв-17, 11:43
	> Можно сжатие включить и дедупликацию без бубнов. Здесь чуть поправлю, т.к. сам эксплуатирую подобное на несколько ТБ. Онлайн-дедупликацию zfs трогать не надо, не имея "бесконечных" cpu|ram. Если таки нужен дедуп, используйте встроенное в rsync (rc4, увы, вероятность коллизии так себе). + "нюанс" rsync: он сначала на источнике/приёмнике делает *всю* карту КС для переливаемого файла. (Это "стреляет" начиная с десятков ГБ на файл.) Т.е. запасайтесь памятью, уже́ для rsync. Мельче блоки — больше памяти…
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	14. "Выпуск утилиты для резервного копирования rclone 1.35"	+/–
	Сообщение от Аноним (??) on 03-Янв-17, 14:30
	В целом солюшн самый адекватный, но пока не получится на него соскочить > 1. Нет любимого всеми GUI и Web морды - а зачем они > если есть ssh? Для неадминов нужен внятный доступ. Из разношёрстных ОС нужен внятный доступ. > 2. На сервере бэкапов нужно мнооооошо ОЗУ для норм. работы ZFS - > не критичный минус, хотя если сервер HP и память регистровая с > кор. ош. , то 32-64 Гбайт будут не дешовыми. Нужно докупать ОЗУ, выпиливать уже имеющуюся ФС, чтобы переразбить далеко не пустой диск, плюс есть нюансы в нормальной установке и работе ZFS на старых Debian (а обновление потянет за собой некоторый геморрой). Хорошо бы какой NAS с ZFS, но есть ли такие по доступной цене?
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	34. "Выпуск утилиты для резервного копирования rclone 1.35"	+1 +/–
	Сообщение от _ (??) on 03-Янв-17, 18:38
	>Для неадминов нужен внятный доступ. Из разношёрстных ОС нужен внятный доступ. Зачем? Кстати безопасность тоже будет против. А для списка авторизованных - ну и отдавай снапшоты как SAMBA shared RO dirs. Оно же снаружи вообще не знает что это - снапшот. >Хорошо бы какой NAS с ZFS, но есть ли такие по доступной цене? Есть :) Есть даже бесплатно ...
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	58. "Выпуск утилиты для резервного копирования rclone 1.35"	+/–
	Сообщение от Аноним (??) on 04-Янв-17, 20:09
	> Для неадминов нужен внятный доступ. У вас там любят раздавать гранаты обезьянам, чтобы посмотреть что получится? Нет, если это чисто айтишная компания такой номер может даже и прокатит но в остальных случаях это будет ад и израиль.
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	28. "Выпуск утилиты для резервного копирования rclone 1.35"	+/–
	Сообщение от Аноним (??) on 03-Янв-17, 17:15
	> 1. Сливаем все что нужно с удалённых серверов с использованием rsync на > центральный сервер бэкапов > 2. На центральном сервере бэкапов ZFS > 3. Делаем какой нужно алгоритм создания снапшотов на ZFS > 4. Profit > Что имеем: Имеем радость жизни. Когда под блоком который расшарен на все 100500 снапшотов каааааак вылезет BAD SECTOR! Ну или что там у кого. И внезапно окажется что вся стопка снпшотов при малейшем пофреждении - битая. Оппа-па. А снапшоты то внезапно не бэкапы! Совсем. Собственно похожая подстава с дифференциальнми бэкапами всех мастей, но там это подконтрольно админу в явном виде хотя-бы на предмет того что от чего зависит и где что шарится а где нет. А снапшоты несколько не для этого сами по себе.
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	40. "Выпуск утилиты для резервного копирования rclone 1.35"	–1 +/–
	Сообщение от Аноним (??) on 03-Янв-17, 20:37
	В случае с ZFS контрольная сумма не сойдётся и тебе напишет мол так и так - файл помер, поищи его в других бекапах. Как минимум ты хотябы узнаешь, какой файл повреждён. Для борьбы с этой фигнёй можно использовать резервирование по схеме 3-2-1 указанное выше, можно зеркало собрать, на худой конец можно сказать сколько уникальных копий каждого блока держать (ZFS такое вполне умеет). И разрулить это вполне подконтрольно админу, в отличие от ситуаций, когда админ даже не знает, что его файлы битые. Зато на диск в этом случае пишется гораздо меньше данных, что уменьшает его износ, и, как следствие, не так быстро происходит вылет всего диска, что куда критичнее одного сбойного файла.
	Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

	54. "Выпуск утилиты для резервного копирования rclone 1.35"	–2 +/–
	Сообщение от Аноним (??) on 04-Янв-17, 14:50
	> В случае с ZFS контрольная сумма не сойдётся и тебе напишет мол > так и так - файл помер, поищи его в других бекапах. Ага. Файл помер. Смотрим мы - а он такой дохлый разом во ВСЕХ снапшотах, например. Круто, да? CoW по изначальной задумке пишет в сторону только изменения. А "core set" блоков может в принципе быть один на всю толпу. И если там что-то порушится - завалиться может и вся цепочка. Это касается и дифференциальных бэкапов, но там параметры цепочки зависимостей явно вывешены админу. И можно настроить - допустим на каждые 5 бэкапов лепится полный, который зависит только от сам себя. Это некий баланс: с одной стороны быстрые и мелкие бэкапы, с другой - масштаб урона если на сервере(ах) с бэкапами ситуация оказалась отлична от идеала. И еще есть соображения консистентности. Если вы просто взяли состояние БД "здесь и сейчас" - ну это круто. Но ничего не говорит о том какие там транзакции были in-flight. И когда вы это вернете двиглу БД, для него это будет как минимум жесткий крах с некорректным шатдауном с его точки зрения. Звучит прикольно и многообещающе, правда? И хрен с два вы с него корректный снапшот снимете без таких сюрпризов. Для этого надо двиглу через какой-то апи сказать чтобы на время угомонилось, снять снапшот, и вот тогда... тогда у вас будет нормальный снапшот. Но это подразумевает или остановку базы или умение дергать какие-то сильно отдельные административные апи. И наверное это уже не про скриптики на питоне и вбаханые наобум снапшоты. И в этом месте мы начинаем догадываться чем нормальный бэкапный софт отличается от наколенщины. Он все это умеет худо-бедно :). > Как минимум ты хотябы узнаешь, какой файл повреждён. Я знаю что у меня факап. Это круто. А дальше, собственно, что? Бэкапные сервера знают не для того чтобы узнать какой файл поврежден. > Для борьбы с этой фигнёй можно использовать резервирование по схеме 3-2-1 указанное > выше, можно зеркало собрать, на худой конец можно сказать сколько уникальных > копий каждого блока держать И тем не менее, это довольно стремная схема в том плане что если в механике файлухи что-то порушится, масштаб урона может получиться очень не прикольный. А то что сановские маркетолухи рассказывают про should never happen не дружит с законами Мерфи, а на лисяре был вполне нормальный пример как never happen может выглядеть. > вполне подконтрольно админу, в отличие от ситуаций, когда админ даже не знает, что его файлы битые. Еще раз. Сервера с бэкапами ставят НЕ для того чтобы узнать что файлы побились. А для того чтобы вынуть с них исправные файлы когда они побились у юзерей по какой-то причине. > Зато на диск в этом случае пишется гораздо меньше данных, что уменьшает > его износ, и, как следствие, не так быстро происходит вылет всего > диска, что куда критичнее одного сбойного файла. И оно как бы круто, только когда вылетит вся стопа "бэкапов" - линчевать тебя будут всем офисом.
	Ответить | Правка | ^ к родителю #40 | Наверх | Cообщить модератору

	63. "Выпуск утилиты для резервного копирования rclone 1.35"	+1 +/–
	Сообщение от Аноним (??) on 04-Янв-17, 21:29
	От повреждения файла или чанка в диф. бэкапах спасает только полное его копирование, что в описанном решении с ZFS, что в твоем "нормальном бэкапном софте". С ZFS это тоже можно реализовать, простейший способ - копировать снапшоты в другой пул раз в неделю, либо архивировать в тот же пул. ZFS в целом дает непревзойденный пока практически нигде уровень достуности и надежности данных. Насчет консистентности, все вменямые БД умеют делать консистентный дамп по умолчанию, не будет никакого "жесткого краха" при восстановлении. Если нет, то как правило есть спец. режим для хот бэкапа, как в случае с ораклом. В общем, непонятно, чего ты развопился и о каком нормальном софте, который решает эти проблемы, ты говоришь.
	Ответить | Правка | ^ к родителю #54 | Наверх | Cообщить модератору

	83. "Выпуск утилиты для резервного копирования rclone 1.35"	+/–
	Сообщение от Аноним (??) on 13-Янв-17, 16:30
	> От повреждения файла или чанка в диф. бэкапах спасает только полное его > копирование, что в описанном решении с ZFS, что в твоем "нормальном > бэкапном софте". Просто нормальный бэкапный софт все это умеет вообще без приявзки к файлухе и каких либо допущений о меганадежных хранилках. Ну то-есть для хранения бэкапов не обязательно городить супернадежный (и поэтому архидорогой) стораж. Достаточно вменяемую схему бэкапов и хранение на нескольких разных серверах, в нескольких физических локациях. Например, на случай если какая там хранилка решит выгореть синим пламенем целиком. > С ZFS это тоже можно реализовать, простейший способ - > копировать снапшоты в другой пул раз в неделю, либо архивировать в тот же пул. Оно как бы можно, но это как бы закат солнца вручную. А в тот же пул - чревато тем что у вас случится catastrophic failure в вашей мегахранилке который будет запроектной аварией для ZFS и вам вынесет все бэкапы одним махом. Что наверное не здорово. У упомянутых вендырей нарулить бэкап на несколько физически разных серверов - совершенно не вопрос. > ZFS в целом дает непревзойденный пока практически нигде > уровень достуности и надежности данных. До тех пор пока хранилка не изволила выгореть синим пламенем целиком, ага. Поэтому те кто повменяемее - бэкапаются на несколько географически разделенных серверов. При этом им значительно менее страшен что маски-шоу что возгорания в серверной. А вот файлуха при этом уже намного менее принципиальна. Если у вас бэкапы на пяти разных серверах, парочка серверов даже может испортиться и даже выгореть совсем. > Насчет консистентности, все вменямые БД умеют делать консистентный дамп по умолчанию, Но для этого им надо отдельно сигналить. В результате одмин с зээфэсом и скриптиками займется переизобретением того что до него придумали цать контор, сделав это к тому же куда лучше. > не будет никакого "жесткого краха" при восстановлении. Если нет, то как правило > есть спец. режим для хот бэкапа, как в случае с ораклом. Ну да, все так. Вот только этот режим надо явно запрашивать и, пардон, бэкапный софт именно вот это и делает. А тут самому придется для каждой хрени разбираться как это делается. По сути начав изображать из себя вендора софта для бэкапов, только хреново и криво. > В общем, непонятно, чего ты развопился и о каком нормальном софте, который > решает эти проблемы, ты говоришь. А чтобы это стало понятно - надо в этой области немного повертеться. Так то понятно что свои костыли не пахнут.
	Ответить | Правка | ^ к родителю #63 | Наверх | Cообщить модератору

	64. "Выпуск утилиты для резервного копирования rclone 1.35"	+1 +/–
	Сообщение от Твой факапчик on 04-Янв-17, 21:49
	Очень интересно общаться с человеком, которому пишешь про схему 3-2-1 (которая подразумевает два бэкапа на другие машины, один из которых вообще в максимально удалённую часть планеты), а он тебе про то, как из-за одного сбойного сектора у тебя вся инфраструктура годами работающая прям обязана навернуться, вместе с ремоутными бэкапами и континентом на котором они хранились. Ты ему пишешь, что количество копий блоков настраивается, а он такой в пьяном угаре с пеной у рта продолжает, от праздников ещё не отошёл, дальше шпарит про то, что это якобы только дифференциальные бэкапы умеют, а всё остальное проделки коммуняк. Ты сразу напиши один раз, что ты тут продаёшь, маркетолух, и не дури людям голову. А то бреда ты накидал, а солюшн так и не предложил.
	Ответить | Правка | ^ к родителю #54 | Наверх | Cообщить модератору

	84. "Выпуск утилиты для резервного копирования rclone 1.35"	+/–
	Сообщение от Аноним (??) on 13-Янв-17, 16:36
	> Очень интересно общаться с человеком, которому пишешь про схему 3-2-1 (которая подразумевает > два бэкапа на другие машины, Хм, я как-то пропустил этот момен. > Ты сразу напиши один раз, что ты тут продаёшь, маркетолух, Да ничего я не продаю. Просто констатирую что полно коммерческих решений которые все это уже делают, без привязок к файлухе, с возможностью развернуть свой сервер бэкапа за какие-то минуты и как раз нарулить бэкапный план с раскидыванием на географиески разные сервера. А ZFS тут ни в п..., ни в красну армию. Делать отдельно взятый сервер бэкапов сверхнадежным нафиг надо, бэкапы места занимают немеряно и удорожать хранилище под них - сомнительная радость. Вот географически раскидать - очень хорошая идея. А от zfs единственная польза разве что проверка чексум.
	Ответить | Правка | ^ к родителю #64 | Наверх | Cообщить модератору

	74. "Выпуск утилиты для резервного копирования rclone 1.35"	+/–
	Сообщение от Аноним (??) on 06-Янв-17, 22:06
	Чувак, ты не прав ))) Если ZFS пулл собран админом на нескольких дисках, например в режиме raidz, BAD SECTOR абсолютно по барабану. Останавливаем сбойный диск, заменяем на новый, даем ZFS команду принять замену. Все! В зависимости от размера диска и загруженности пулла система придет в норму максимум через сутки ))) Куда страшнее "умные" дисковые контроллеры!!! Если накроется такой контроллер, пулл восстановить на новом контроллере, с вероятностью 99% не удастся. Для ZFS чем тупее контроллер, тем лучше.
	Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

	85. "Выпуск утилиты для резервного копирования rclone 1.35"	+/–
	Сообщение от Аноним (??) on 13-Янв-17, 16:57
	> Если ZFS пулл собран админом на нескольких дисках, например в режиме raidz, ...то мы вспоминаем что бэкапы нужны раз в сто лет а хоанилка начинает удорожаться. > BAD SECTOR абсолютно по барабану. Останавливаем сбойный диск, заменяем на новый, > даем ZFS команду принять замену. Все! Это в теории. А на практике случаи разные бывают. Вон на лисяре описан случай когда файлуха просто не смонтировалась. Хорошо если ты джеди и можешь вручную, хексэдитором, всех нае..., но это наверное не про обычного оператора бэкапов. > В зависимости от размера диска и загруженности пулла система придет в норму > максимум через сутки ))) А в течение этих суток на остальные диски будет повышенная нагрузка и спасибо если ничего новенького в результате не помрет. Ну и в целом супернадежные многодисковые хранилки стоят денег а проблему например пожара в серверной или иных катастрофических отказов - не решают. > Куда страшнее "умные" дисковые контроллеры!!! Вот это да - если уникум подохнет и у людей не было запаски, это полный попадец. Прошареный народ закупает запаски. На самом деле для бэкапов актуальнее не суперхранилки а просто настроенное раскидывание по разным серверам. Спасает от всего, начиная от маски шоу и заканчивая выгоранием или затоплением серверной. > Если накроется такой контроллер, пулл восстановить на новом контроллере, с вероятностью > 99% не удастся. Для ZFS чем тупее контроллер, тем лучше. Да там и ZFS не больно нужно. Нужно раскидать бэкапы на несколько серверов в раных локациях и горя не знать. Одна мегахранилка никак не решает проблему что она может утонуть, сгореть или ее унес ОМОН. Или вот например файлуха не смонтировалась, а по увещеваниям саней это should never happen, который быстро превращается в "что хотите, то и делайте!".
	Ответить | Правка | ^ к родителю #74 | Наверх | Cообщить модератору

	48. "Выпуск утилиты для резервного копирования rclone 1.35"	+/–
	Сообщение от XoRe (ok) on 04-Янв-17, 10:45
	> 1. Сливаем все что нужно с удалённых серверов с использованием rsync на > центральный сервер бэкапов Что будете делать, если центральный сервер поломается?
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	55. "Выпуск утилиты для резервного копирования rclone 1.35"	+/–
	Сообщение от Аноним (??) on 04-Янв-17, 15:07
	> Что будете делать, если центральный сервер поломается? А это как в анекдоте про поимку льва голыми руками. - А если это будет львица? - Ну тогда крутите свои. Они вам больше не понадобятся.
	Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

18. "Выпуск утилиты для резервного копирования rclone 1.35"	–1 +/–
Сообщение от ananim on 03-Янв-17, 15:18
Freenas, NEXENTA
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	27. "Выпуск утилиты для резервного копирования rclone 1.35"	+/–
	Сообщение от Аноним (??) on 03-Янв-17, 17:08
	> Freenas, NEXENTA В каком месте они - решения для бэкапа и синхронизации?
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	37. "Выпуск утилиты для резервного копирования rclone 1.35"	–1 +/–
	Сообщение от _ (??) on 03-Янв-17, 18:45
	Вон в том ^^^^ выше по топику. И не решение, конечно, а часть решения.
	Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

	41. "Выпуск утилиты для резервного копирования rclone 1.35"	+/–
	Сообщение от Михрютка (ok) on 03-Янв-17, 21:18
	> Freenas, NEXENTA doh! и еще экспортированные, как блочный девайс, чтобы усугубить ситуацию вконец.
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	65. "Выпуск утилиты для резервного копирования rclone 1.35"	+/–
	Сообщение от Твой факапчик on 04-Янв-17, 22:01
	NAS - это обычно железка размером меньше чем рабочее место бородача. Указанное вами на большинстве NAS'ов не взлетит
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема