Разностное копирование на Google Drive

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

Не хочу хвалить гугл, но для них паттерн "проектирования" "тяп-ляп" - не характерен.

Кто запрещает периодически делать контроль целостности данных?

А здесь дело не конкретно в посещаемости ресурса.

Но посещаемость = повышенная нагрузка на сам ресурс + каждая новая "фича" - это один из дополнительных вариантов отказа.

Поэтому я за то, чтобы система работала как можно проще.

Т.е. лучше меньше наворотов и всё максимально просто, чем куча резервирования, которое работает по сложной схеме и может отказать. (больше точек отказа и их резервирование само по себе ещё больше усложнит саму схему работы)

На своём VDS/Сервере можно круглосуточно мониторить состояние системы, дисков и т.п. Когда работа облака для вас остаётся загадкой.

Зачем сразу пару тер, можно и 200 тер, было бы $$ на реализацию.... тут разговор не за дорого или дешево....

Кстати, пару терабайт это вам зачем? Я вполне спокойно храню около 200 бекапов от cPanel 4-5 копий (каждого, т.е их около 1k) на массиве размером 750 GB.... конечно если у вас видео архив а 2 TRB то его бекапть будет сложно, но по моему бекапить его на google будет еще сложнее :D

---------- Добавлено 13.08.2012 в 16:32 ----------

Я не говорю что гугл делает фигню, просто у конечного пользователя нет шансов понять когда может прийти каюк, скажем так. А насчет посещаемости и отказа, Химико верно довел мою мысль, сегодня google решит добавить что-то новое в этот Disk свой, все начнут тыкать, возрастает нагрузка, а с ней вместе возрастает и шанс отказа, по моему вполне логично...

Ни кто, только толку в этом, если вы сегодня сделали контроль, все зашибись, а завтра гугл написал "упс у нас тут 200 серверов вылетело куда-то, простите...." грубо говоря конечно. В этом случае контроль целостности даст вам только понимание того что ваши данные целиком померли :D а не частично :D

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

если хранить их по такой схеме : предыдущий месяц - все ( 4*100=400 гиг) + один за каждый месяц до года (11*100=1100гиг)...

А ещё по будним делаются инкременты....

Дык мне проще 2*2 терра поставить на колокейшен, и пусть rsync работает :)

Даже "фича", которая устраняет один из вариантов отказа? 😂

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

Если бы ваша "логика" работала - фарманы были бы надежнее современных авиалайнеров.

Думаю, что даже конкретно вам можно рассказать пару новых вещей о том что нужно "мониторить", чтобы гарантировать себя от потерь данных при локальном хранении. Вас не затруднит предложить *конкретный* и *полный* список действий, который вы бы предложили ТС для сего "мониторинга"?

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

Как и при локальном хранении. От необходимости регулярно проверять целостность бекапа вас не избавит ничего. Других вариантов убедиться, что все в порядке - нет.

Это "логично" на уровне "я щитаю" (с). А вот "я щитаю", что при добавлении новой фичи они учтут потенциальный рост нагрузки - и ничего подобного не произойдет. Это вопрос проектирования системы - только и всего.

Тоже вполне логично. Не логичным - выглядит ваше заявление, особенно если "новая фича" связана с увеличением отказоустоичивости хранилища.

Короче, главного вы не раскрыли:

1) добавление фичи

2) увеличение нагрузки

3) ???

4) profit!возрастание шанса отказа

Ну замените гугл на внезапно умерший жесткий диск. Или появившийся бед на самом интересном месте. Вы такое спрогнозируете?

ну чего спорить? какая разница где хранить копию, главное что бы она была, была доступна и т.д.

И да, вероятность отказа основной инфы и бакапной какова?

Бакапы используются для чего? что бы восстановить основное. А если основное целое, то пофиг на то, что случилось с бакапом, толи винт умер, то ли 200 серваков. Просто сделаете новый бакап....

Интересно, и какова же?

А вы наверное каким-то образом знаете на каком месте у гугла появится бед? Весьма интересно...

По крайней мере на своих винтах я вижу что появился бед , я пошел винт заменил и все в порядке, или наверное нет, для вас этого мало у меня на двух винтах в одном месте бед появился сразу? так что ли ? А если Raid-5 ? то в 10 местах одновременно?

Я не буду спорить, выражаю всегда свое IMHO. И его я выразил выше, google ни чем не лучше а то и хуже чем обычный RAid-1 если не рассматривать его глобально как компанию, а посмотреть с точки зрения конкретного пользователя и его данных. Вы же не будете отрицать того, что нагрузка общая на систему google disk в разы выше чем на VPS в который раз в неделю заливается пару сотен гиг? То что они проектируют и все продумывают это понятно , иначе бы они не были магнатами, но зачем это все знать конечному клиенту, а темболее быть участником этих апгрейдов рискуя своими данными? Вы же не решаете и не проектируете для google ? Вот случилось так что человек занимающийся проектированием там ощибся и умерли ваши данные (или это тоже не возможно), гугл пожалуй только извинения напишет ;) А в случае VPS у вас может стоять древний и дырявый FTP сервер который файрволами закрыт и он будет 200 лет стоять, пока позволит железо, и апгрейдов там не будет и планировать ничего не надо и вообще думать о нем мало надо..... поставил себе smartctl , настроил пару нотификейшонов и для штатного использования больше чем достаточно, я думаю по такому принципу работает множество провайдеров и даже полагаю , что вы не исключение (не как провайдер, а просто как человек, я не верю что у вас для бекапов собственное распределенное хранилище по всему миру, а так же каждый винт мониторится по 200 параметрам)!!! Приземлитесь :D Тут обычные люди пишут :D

---------- Добавлено 13.08.2012 в 20:29 ----------

В данном контексте 50/50.

Ежели информация *уже* убита - только ленивый или тупой не заметит.

Не обязательно "сразу". Чаще новый всплывает в процессе ребилда. Привет прогресс и терабайтники!

Ну а использующие raid-5 на больших современных дисках - имеют еще больше шансов сказать прощай своим данным.

И еще есть куча сценариев потери данных на одиночных дисках или в raid. Тема большая, сложная - и наивно полагать что вася пупкин сумеет лучше обеспечить сохранность данных чем профессиональный сервис, ориентированный на соответствующее применение.

Мой совет ТС - не полагаться на местных "гуру" и бекапить на облачные сервисы. Лучше, на то что хорошо и давно поддерживается duplicity. Обратите внимание, что в 0.6.18 *нет* gdocs бакенда (в статье, вероятно, использовалась ubuntu с патчем). ТС, какая у вас версия?

Я и не отрицал этого. Просто не вижу прямой связи между нагрузкой и высокой вероятностью отказа.

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

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

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

"Локальный" бекап предпочтителен при больших объемах и/или необходимости быстрого восстановления больших объемов данных. И в этом случае - лучше перебдеть и забекапить часть на облако.

Если упускать из виду существенные факты, которые не ложатся в ваше "мнение" = можно обосновать что угодно и как угодно.

Я подожду "оценки" от Rimlyanin, прежде чем смеяться над вашей.

myhand, у меня складывается впечатление что у вас мания величия....

1. "По крайней мере на своих винтах я вижу что появился бед"

Ваш ответ: "Ежели информация *уже* убита - только ленивый или тупой не заметит."

Причинно следственная связь не нарушена? Если все погибло то все погибло, причем тут ваша реплика вообще ? У меня рейд, на 1м винте что-то умирает со вторым все ок.

2. '"Не обязательно "сразу". Чаще новый всплывает в процессе ребилда. Привет прогресс и терабайтники!"

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

3. "Ну а использующие raid-5 на больших современных дисках - имеют еще больше шансов сказать прощай своим данным."

Давайте свои пруфы, использую Raid 5 и 6 вполне отлично все, не знаю о чем это вы, вспышка фантазий ночная?

4. "И еще есть куча сценариев потери данных на одиночных дисках или в raid. Тема большая, сложная - и наивно полагать что вася пупкин сумеет лучше обеспечить сохранность данных чем профессиональный сервис, ориентированный на соответствующее применение."

Линки давайте, линки, а то выглядит как будто вы просто "умный". Вася пупкин не настроит, а админ настроит и настраивают по всему миру как-то, может только у вас проблемы?

5. "К вам вопрос тот же, что и к Himiko - предложите конкретые пункты, которые нужно выполнить ТС, чтобы создать и поддерживать хранилище. Я готов поспорить, что найду пример того, что вы при этом упустите из виду."

А давайте сделаем наоборот, послушаем вас как умного, жду вашу реализацию, посмотрю на нее пофыркаю и тоже думаю что найду то, что вы упустите ... lets Go!

6. "я не верю что у вас для бекапов собственное распределенное хранилище по всему миру"

Вырываете фразу из контекста, верните обратно , там написано что я рассматриваю не как хостера вас.... а как человека... але але ?

7. "Если упускать из виду существенные факты, которые не ложатся в ваше "мнение" = можно обосновать что угодно и как угодно."

Ровно как и ваша вся писанина написанная тут. Не находите ? :) Разница лишь в том, что я сразу говорю, что это IMHO (мнение),а вы что-то пытаетесь доказывать, причем пока без аругментов... И кстати о каких фактах речь?

8. "Я подожду "оценки" от Rimlyanin, прежде чем смеяться над вашей."

Начните с себя. Посмеемся вместе.

Резюмирую: ты кто такой? давай досвидания?