[OFF]
По сути есть что?
когда ж от вас будет по сути больше, чем бреда....
[/OFF]
LinuxForum.Fans
Какой смысл бекапа на тот же диск?
Автор: kerogaz
120 сообщений
2830 просмотров
"негодным" я считаю ваше понимание. Самого метода я не видел.
Только, вы так и не пояснили в чем его негодность.выделение вам видно?
видно. только суть уже была. Вам нужны доскональные подробности?
Ну. ок. повторяю, чтоб было отдельно специально для вас.
0. Все действия происходят, когда к базе ни кто не обращается.
1. Останавливатся сервер. База копируется прямо живьем
2. Запускается сервер
===
3. Основная БД проверяется средствами СУБД
4. Основная БД бэкапится средствами БД
5. Основная БД востанавливается из бэкапа средствами БД
3-5. В случае ошибки на любом из этих этапов уведомления админов и копируем из копии (п1) назад
===
в случае успеха 5 пункта
6. Архивируем бэкап в локальное хранилище (по возможностям сервера на тот же или на второй диск). С обеспесением сохранения несокльких последних копий
7. Заливаем этот архив на фтп удаленного сервера
Что то требует пояснения?
В свою очередь мне интересно узнать как обеспечить оперативное восстановление БД. Если использовалась репликация на удаленный сервер, и связь этим сервером или утеряна или отвратительного качества (например скорость упала до уровня диалапа - а объем большой)
определение термина я ещё жду
Вместо того, чтобы отвечать за свои слова, вы чего-то требуете от меня. Смешно.
Я, по крайней мере, не ввожу в людей в заблуждение и не пишу статей, полных самодовольства и лишённых как логики, так и фактуры.
Про бэкап вы толком ничего не сказали, хотя вопрос ерундовый.
ещё раз: здесь не овуляшки.ру.Я, по крайней мере, не ввожу в людей в заблуждение и не пишу статей, полных самодовольства и лишённых как логики
потрудитесь объяснить, где именно я отступил от логики?
я не журнализд, мне пофиг.так и фактуры.
я сказал много, были ссылки на то, что я написал. Могу здесь скопипастить, если вам нужно tl;dr.Про бэкап вы толком ничего не сказали, хотя вопрос ерундовый.
вот только это не бекап. Если вы посмотрите в консоли, то увидите, что этот ваш "бекап", на самом деле тот же самый файл. Только под другим именем.
text
-sh-4.1$ touch test
-sh-4.1$ echo 111 > test
-sh-4.1$ cp test test1
-sh-4.1$ ls -li test*
6815757 -rw-rw-r-- 1 rhevadmin rhevadmin 4 Mar 25 15:44 test
6815758 -rw-rw-r-- 1 rhevadmin rhevadmin 4 Mar 25 15:44 test1
чяднт?
Пример: текстовый конфиг. Открываю ФМ. Делаю правка > копировать и потом правка > вставить. В ФМ у меня появляется копия файла. Я спокойно ковыряюсь
я на другое отвечал. А вы что мне доказываете?echo 111 > test
[quote="mvt"]Вывод. Бекап ТОЛЬКО на тот же физический диск - не имеет смысла. Нет?
имел смелость исправить вашу цитату. Ответ -- да.[/quote]
Согласен :)
ВП
Удобный выход когда нет аргументов.
Ну что ж, этого и следовало ожидать аргументов от вас так и не поступило.
Хотя жаль, что вашего варианта я так и не услышал (по крайней мере с конкретными условиями задачи: возможность оперативно восстановить без связи с внешним миром, ежедневная проверка базы и бэкап/разбекап)
я на другое отвечал. А вы что мне доказываете?
захожу в файл менеджер, создаю файл, копирую его рядом. получаются два файла. я просто сделал то же самое в командной строке, для наглядности. у вас же совсем иное описание результата, вот я и пытаюсь понять что я упускаю (или не я?)
[quote="yars"]Скупой платит дважды, а пожиратели маздайного кактуса -- трижды
Настоящие мужчины сидят под Windows[/quote]
Доктор, откуда вы такой умный, не из Одессы случаем?
захожу в файл менеджер, создаю файл, копирую его рядом. получаются два файла.
Вот и я о том же. Ничего мы не упускаем, разве что ведёмся на спор с троллем :)
аргументов против чего именно? Что вы предлагали-то? "Останавливать" или "живьём"? Определитесь.Удобный выход когда нет аргументов.
А доказать, что 2*2==5 не составляет труда, если допустить сокращения на ноль.
в данных условиях невозможно осуществить надёжный бекап. Смиритесь, что это (само)обман. HDD не вечные, люди ошибаются. Проблема в том, что и то и другое происходит ВНЕЗАПНО, а не тогда, когда вам этого хочется.Хотя жаль, что вашего варианта я так и не услышал (по крайней мере с конкретными условиями задачи: возможность оперативно восстановить без связи с внешним миром, ежедневная проверка базы и бэкап/разбекап)
ну говорю же: посмотрите, какой получится inode.захожу в файл менеджер, создаю файл, копирую его рядом. получаются два файла. я просто сделал то же самое в командной строке, для наглядности. у вас же совсем иное описание результата, вот я и пытаюсь понять что я упускаю (или не я?)
[console]$ ls -li
итого 0
691725 -rw-r--r-- 1 aranei users 0 мар 26 10:06 f1
691747 -rw-r--r-- 1 aranei users 0 мар 26 10:06 f2
$ cp --backup=simple f1 f2
$ ls -li
итого 0
691725 -rw-r--r-- 1 aranei users 0 мар 26 10:06 f1
691848 -rw-r--r-- 1 aranei users 0 мар 26 10:07 f2
691747 -rw-r--r-- 1 aranei users 0 мар 26 10:06 f2~
[/console]
если вы умеете читать и разумеете цифры, то вы видите, что "бекап" f2~ на самом деле никакая не копия, а старый файл f2, только с другим именем.
AlfaStriker, нет, я из Питера. А вы откуда?
вам больше сказать нечего, да? Ну промолчите. Глядишь, сойдёте за умного, а то я от вас кроме перехода на личности ничего не слышу.Вот и я о том же.
аргументов против чего именно? Что вы предлагали-то? "Останавливать" или "живьём"? Определитесь
Я давно уже определился. Но вам, похоже, религия не позволяет читать внимательно.
1. С самого начала я говорил, что в данной конкретной ситуации:
а. остановить базу не пробема
б. проверка базы бэкапом/разбекапом необходимое условие задачи, как следствие остановка тоже нужна. даже если бы у нас была репликация
2. СУБД позволяет делать бэкап без остановки базы. Т.е. если исключить необходимость "проверка/бэкап/разбэкап" можно и не останаливать
в данных условиях невозможно осуществить надёжный бекап.
В каких данных?
Где здесь помеха "надежному"?
При чем здесь жизнь HDD внезапно или нет? Ну умрет диск с бэкапом и что? у нас есть удаленная копия. В предлагаемом вам варианте - она единственная. Т.е. вы исходите из того, что связь сущность более надежная чем ХДД? Или она "внезапно" пропасть не может?
Вы где то вычитали, что локальная копия единственная?
Может вы о том, что репликация в реальном времени идет и пропадет меньше данных? Тут да. Это достоинство репликации. Но условное. Репликация должна уметь не потерять данные если связь разорвана. Она должна уметь на лету решать коллизии... И тут уже надо решать, что важнее: возможность потерять часть данных или постоянная дополнительная нагрузка на сервер.
Ну, а в случае идеальной связи и репликации только для целей создания точной копии. Тут даже и механизмов ни каких навороченных не надо, тот же фаерберд позволяет из одной базы в другую луюбой запрос отправить ((есть и у других СУБД, но в fb я с этим работал - правда с другими целями).
если вы умеете читать и разумеете цифры, то вы видите, что "бекап" f2~ на самом деле никакая не копия, а старый файл f2, только с другим именем.
смотрю, во первых у меня копи-пейст создает еще один файл, без тильды. во вторых цифры я как раз разумею, и в вашем примере, f2~ получил старый айнод, но копия уже на новом, так что в принципе никаких проблем с использованием этого файла как резервной копии на время изменения основного файла я не вижу.
какая и как?2. СУБД позволяет делать бэкап без остановки базы.
ответы были выше.В каких данных?
Где здесь помеха "надежному"?
При чем здесь жизнь HDD внезапно или нет? Ну умрет диск с бэкапом и что? у нас есть удаленная копия. В предлагаемом вам варианте - она единственная. Т.е. вы исходите из того, что связь сущность более надежная чем ХДД? Или она "внезапно" пропасть не может?
Вы где то вычитали, что локальная копия единственная?
в MySQL умеет, я проверял.Репликация должна уметь не потерять данные если связь разорвана.
умеет. Для того и нужна собственно.Она должна уметь на лету решать коллизии...
при чём тут репликация? Я всё больше убеждаюсь, что вы смутно понимаете, что это такое, но своё безусловно правильное мнение имеете. И спорить с вами бесполезно.Ну, а в случае идеальной связи и репликации только для целей создания точной копии. Тут даже и механизмов ни каких навороченных не надо, тот же фаерберд позволяет из одной базы в другую луюбой запрос отправить
а вам я рекомендую узнать значение слова «копия». Отвечать мне не нужно.смотрю, во первых у меня копи-пейст создает еще один файл, без тильды. во вторых цифры я как раз разумею, и в вашем примере, f2~ получил старый айнод, но копия уже на новом, так что в принципе никаких проблем с использованием этого файла как резервной копии на время изменения основного файла я не вижу.
а вам я рекомендую узнать значение слова «копия». Отвечать мне не нужно.
вы понимаете что ничего не говоря ничего и не доказываете? может хватит уже врать и делать из себя великого гуру?
а что тут доказывать? Вы понимаете, что "резервная копия" == "резервная не копия". Какой смысл с вами спорить? *NO*вы понимаете что ничего не говоря ничего и не доказываете?
какая и как?
Firebird. gbak
ответы были выше.
Да? На какие то другие вопросы может быть.
....в MySQL умеет, я проверял.
....умеет. Для того и нужна собственно.
Собственно я не говорил иного. Речь о том понимаете ли лично вы что это означает физически. И всегда ли это целесообразно.
при чём тут репликация?
Сами предложили репликацию для целей бекапа...
Зачем репликация если есть более простой метод. "Феншуй drBatty"?
И спорить с вами бесполезно.
До вас только начинает это доходить. Я вам давно сказал, у вас знаний много. Здесь у вас кучу поверхостных знаний и отсутствие практики. Точнее ваша практика узкоспециализирована.
Войдите или зарегистрируйтесь, чтобы ответить.
