Это если руки кривые. А так за 14 лет. А местами у клиентов "сервера" были еще те.  "Криво" ни когда не случалось.

Я не сисадмин - мне это вообще нафиг не надо. Да и давать советы не зная деталей - вредно (для того кому адресовано)

И правильно сделаете. Вы не сможете этого сделать, поскольку есть решение взвешенное со всех сторон.
Вам все ни как не понять:  ситуации бывают не только такие в какие попадаете вы. Если вам кто-то вбил в голову, что репликация это тру. Это не значит, что ее есть смысл пихать куда ни попадя...  Ну или вы не совсем догоняете смысл репликации.

нет. Просто я по опыту знаю, что копировать каталог с СУБД == грабли. А делать дамп -- тормозить всю СУБД, т.е. тоже не очень хорошо.

Есть ещё варианты?

я вас обидел, да? Ну вы в следующий раз по делу пишите.

Попробуем еще раз. Начнем с зародыша ваших мыслей на тему топика:
1. Копировать каталог  - чем не вариант. Что у вас за грабли за такие с этим? Вы конкретную СУБД имеете ввиду?
2. Дамп базы == тормоза СУБД. Вы считает любая система использующая ту или иную систему 24 часа в сутки нагружена? А те которые, например, используются только 8 уже и не серьезные системы  вовсе?
3. По вашему репликация это некая фишка не дающая абсолютно ни каких "накладных расходов"?
4. Чем бэкап отличается от резервного копирования, по вашему?
5. Вы считаете, что автоматической поднятие из бэкапа приемлимо во всех случаях использования БД?
6. В прочем, даже при условии "копирования каталога" вовсе не означает поднятие руками - вполне все автоматизируется. Даже если сервер под виндой.

За 14 лет работы с разными БД. Было копирование и фалами, и СУБДшным бэкапом, было и двунаправленная репликация и репликация в одну сторону, но базы работали параллельно. (СУБД сама не умела при этом) И ни разу не было ни каких косяков.

Любое решение сделанное с умом рабочее. И каждого есть свой набор плюсов и минусов.

Это вопрос знания. Оба слова есть один и тот же термин (синоним), но первый есть корявая калька с английского, а второй - нормальный перевод на русский язык.

все 14 лет "нафиг не надо"? 

завтра гляну - там много буков

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

Ни какой "профилактики" среди бела дня. А вот ночью, ночью выполняется ряд сервисных функций по обслуживанию БД. Включая на центральный. Но весь рабочий день как часы. При этом вменяемая связь появилась не больше года назад. Залить базу на сервер проблематично. Уже началься новый день, а копия еще докачивается и одно другому ни как не мешает. При этом с репликацией или без оной база нативными средствами бэкапилась/разбэкапилась каждую ночь. И такая схема (описана естественно не полностью) показала себя очень надежной вне зависимости от качества связи и мощности серверов/компьютеров.

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

Приехали. Это было на вашу фразу

Да велика. Но и этот вопрос решаем. Вы верите, что репликация дает 100% гарантию? Не фига. Не если техника супер, связь супер то наверное. Наделе же и модемное соединение далеко не прошлое... И "сервера"  с мощностью слабее современного телефона. И еще овер 100500 условий из реальной жизни.

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

что, пенсию не дадут? Ничего страшного, им не привыкать к былокодерам и быдлоадминам. Как сказала моя матушка(пенсионерка) — "там компьютер, а это очень долго".

я не про профилактику. А если HDD посыпется?

какая "такая"? "С репликацией ИЛИ без"? Что за бред вы написали?

за всё надо платить. Надёжность бесплатной не бывает.

вы забыли процитировать саму фразу. Откуда я знаю, на какой из моих Over9000 постов вы отвечаете? Я так думаю, это демагогия — проще потом съехать, если поймёшь, что был неправ.

демагогия. У решения тоже есть цена. И цена часто безумно большая. Вот в той ссылке которую вам лень читать никакой репликации нет. Но годно это только для одинокого нетбука(даже для десктопа не годно).

опять демагогия. Скучно, сударь…

И что? Тут хоть репликация хоть копирование. Как от этого спасет репликация?

Без репликации.

Естественно. Только та цена оправдана если есть в ней толк.

Ууу. И вы мне втираете про репликацию? Да у вас довольно однобокое ее понимание. Ну да сейчас не об этом. Пусть в данном конкретном случае вы предлагаете ее использовать только в этих целях ок.

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

Ну да ладно. Суть то не в этом. А в том, что нагрузки для целей  бэкапа в рабочее время ни какой не было. В случае с репликацией она будет. И зачем оно? Вы можете пояснить? Что она мне такого даст? Особенно если учесть, что ночью база прогоняется через бэкап, фикс, разбекап, отправку на архивный сервер и на зеркало с которой гоняют отчеты менеджеры вышестоящего звена.

Итак: архив нам нужен точно, обработать базу полезно точно. что даст в такой ситуации репликация?

Так я и сравниваю..  Я ж вам сказал, если связь хреновая бэкап качается пока не закачается....  На работу сервера в рабочее время это уже ни как не влияет.

А вот что будет с репликацией если связь фиговая?

Это плохо, что вы в этой фразе увидели только резюме.

Мне абсолютно плевать, что вы думаете обо мне. Целью было только показать, что это мнение основано не на куцых теоретических знаниях. А на знаниях подкрепленных практикой.
И я, в отличии от вас, ни кого не поучаю. Только рассказал о своем опыте.  Пытался показать, что ситуации на которые предлагаемые вами штампы не наложить. И, согласитесь, одно дело если бы я был человеком, который просто чего то там где то проситал, это было бы одно. И другое дело, если я работал вплотную. Ну, а уж верите вы или нет в это мне фиолетово.

Хватит уже мерять людей по себе.  Не было у меня целью показать свой скил.

В прочем походу вам это не надо. От вас ни одного аргумента по теме так и нет. Только пустая демагогия и обсуждение моей персоны.

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

нет никакого "обсуждения" всё подчистили. Вы ангел. 

и меня тоже нет 

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

Я ни где и никогда не говорил иного. Между тем бэкап (специально для вас выделяю) И на локальный диск (и, даже, на тот же) тоже полезная функция. Возьмем опять все тех же клиентов. За время сотрудничества по разным причинам (электричество,  "глупые" действия местного "админа" и т.д) были случаи убийства базы. Восстановить из локальной копии быстрее практически всегда. Удаленная копия это больше резерв, чем основная копия. Винты гораздо реже дохнут, чем чьи то безалаберные действия нарушают функционирование системы. На практике локальная копия единственная технически возможная (правда последнее время цивилизация в нашей области достаточно распространилась ). Хотя и локальная копия не на один комп. (Правда бывали случаи когда ноги вырастали у всех компов). Было копирование и на компакт диски (где размер базы позволял).

Но, как бы то ни было, локальная копия на том же компе всегда была. И это нормально, восстановится с нее быстрее.

Аргументы будут или это ваше личное мнение?

Ну, если вы начнете приводить аргументы - почему бы и нет.

1. Дело не в системе, а том, что чем меньше город тем легче стать "системным администратором Windows".  А от "админа" спасения нет.
2. Это не важно в данном обсуждении.