adminius:Шарапов, самый просто - это ntbackup по шедулеру + rar полученного вайла =)
это дольше будет. да и выковырять нужное файло тоже дольше. а так я имею всегда 2 идентичные копии своего барахла. поэтому и про@б ноутбука мне пофигу.
adminius:Шарапов, самый просто - это ntbackup по шедулеру + rar полученного вайла =)
это дольше будет. да и выковырять нужное файло тоже дольше. а так я имею всегда 2 идентичные копии своего барахла. поэтому и про@б ноутбука мне пофигу.
Gonger,
SVN - это в первую очередь система хранения версий текстовых документов и разделения работы в рабочих группах
это цвс был для текстовых. свн неплохо и бинарники кушает. да и совет мой был для Артёмка.
adminius, я считаю Ваш пост приступом немотивированного хамства. Общение с хамами не входит в список моих интересов ![]()
badguy, SVN кушает бинарники, но есть проблемка - заводим Word doc с картинками в мегабайт и редактируем его по несколько раз каждый день - и svn commit после каждого исправления - сколько метров будет кушать база SVN через месяц? А если у вас сотни таких файлов? Всё таки тестовые файлы он хранит гораздо получше, с диффами.
Gonger,
у subversion команда diff в отличие от CVS работает и с бинарными файлами, поэтому передаются по сети только изменения относительно предыдущей ревизии.
это раз. второе - если вы делаете коммит апосля каждого чиха раз в 5 минут - то ССЗБ. зато свн позволяет вам откатится к каждому этому вашему чиху. не хотите гигабайтной базы - коммитьте только важные точки.
badguy:Gonger, Цитата: у subversion команда diff в отличие от CVS работает и с бинарными файлами, поэтому передаются по сети только изменения относительно предыдущей ревизии.
К сожалению бинарные файлы часто изменяются настолько сильно, что дифф будет по объему хуже полной замены.
badguy:второе - если вы делаете коммит апосля каждого чиха раз в 5 минут - то ССЗБ. зато свн позволяет вам откатится к каждому этому вашему чиху. не хотите гигабайтной базы - коммитьте только важные точки.
Зачем в пять минут? Сделал таск - сделал коммит - такое правило обычно. Если маленький таск то и коммит будет раз в в два часа.
зато свн позволяет вам откатится к каждому этому вашему чиху.
а оно надо? опять MS Shadow Copy каГ вариант
я считаю Ваш пост приступом немотивированного хамства.
считайте как хотите. просто не надо из себя принцессу строить когда все не так. резервное копирование как и любая система автоматизации - это почти всегда компромисс между функционалом/надежность/ценой.
Удачи.
Поднимаю тему. Посоветуйте:
Нужно архивация папки каждые 2 часа. Архивы (к примеру .zip) должны хранится неделю, потом самоуничтожаться. 2003 server.
Нужно архивация папки каждые 2 часа. Архивы (к примеру .zip) должны хранится неделю, потом самоуничтожаться. 2003 server.
понадобиться 2 скрипта: первый, который помещает все содержимое папки в архив и складывает в папку для бэкапа, второй - который сносит все файлы, дата создания которых >7 суток. запуск по шедулеру обоих скриптов раз в два часа. Итого имеем ровно неделю и ничего лишнего.
Вариант 2: нумеровать архивы и сносить по номеру архива. Но ИМХО вариант 1 в разы проще. Если че - скрипты в нете есть. На сисадминс в частности видел
|
офлайн
Неизвестный кот
Neophyte Poster
|
|
|
0 |
Город:
|
Small Moock:Поднимаю тему. Посоветуйте:
Нужно архивация папки каждые 2 часа. Архивы (к примеру .zip) должны хранится неделю, потом самоуничтожаться. 2003 server.
Попробовать можно, к примеру, AutoIt - язык скриптового управления всем подряд ![]()
У меня такая дилемма. Есть будующий комп-сервер. В нем два одинаковых веника по 500 гигов. Вот и думаю - сделать зеркальный рейд, или просто использовать один из драйвов для бекапа второго? Загвоздка с рейдом для меня вот в чем - как происходит процесс восстановления инфы в случае краха одного из веников?
Какой бы способ использовали Вы?
the_ghost:У меня такая дилемма. Есть будующий комп-сервер. В нем два одинаковых веника по 500 гигов. Вот и думаю - сделать зеркальный рейд, или просто использовать один из драйвов для бекапа второго? Загвоздка с рейдом для меня вот в чем - как происходит процесс восстановления инфы в случае краха одного из веников?
Какой бы способ использовали Вы?
всё в принципе просто - когда одному из веников приходет конец(SMART кричит или просто конец), то проблемный достаётся, новый ставится на его место(причём не обязательно такой же, можно и больше размером - сталкивался сейчас когда восстанавливал зеркала на старых 20-40G винтах), затем из раидовской утилиты зеркало старое разбивается, создаётся новое на основе старого винта, и проводится синхронизация(обычно автоматически после создания зеркала). после этого зеркало работает в прежнем режиме. если нового винта нету, то просто зеркало разбивается - получается обычный винт.
зеркало хорошо когда серверу важна надёжность - допустим нельзя допустить его простоя днём, а допустим в какое-то время можно будет при крахе его отключить. в таком случае при крахе одного из винтов сервер сможет продолжать работать(но уже без прежней надёжности). если же крякнется рабочий винт при варианте с архивом - то придётся сразу же серв останавливать и восстанавливать файл нужный из резервной копии. однако тут есть приемущество в виде того, что в архиве можно хранить несколько снимков важных данных и откатываться на них по мере необходимости.
the_ghost,
Какой бы способ использовали Вы?
RAID и регулярный BackUP
Загвоздка с рейдом для меня вот в чем - как происходит процесс восстановления инфы в случае краха одного из веников?
при зеркальном рейде в случае краха одного из винтов - восстановление информации не требуется. Требуется восстановление Raid массива и переписывания на новый массив данных. В случае простых рейдов и намека нет на горячую замену винтов ![]()
Hood, ASM, наверное все-таки будет проще зеркалить разделы первого веника на втором и в случае сбоя загрузиться в acronis cd и восстановить разделы. Меньше телодвижений, как я понял, можно будет совершать только при наличии более серьезного RAID'a, цена которому огого. Верный ход?
the_ghost, почему огого?.. любая современная материнка умеет своими средствами реализовывать raid 1+0 на sata дисках (диск зеркалируется на аппаратном уровне и чтение происходит параллельно с обоих, повышая быстродействие при чтении теоретически в 2 раза), то есть при вылете одного из дисков достаточно будет физически удалить повреждённый диск и из биоса размонтировать этот raid - комп загрузится так, как будто бы ничего и не произошло.