KF

Скорее, для оживления раздела Софт. Ну и поскольку пришлось делать внеплановую ревизию системы резервного копирования.
Кто какие средства предпочитает для этого?
Во-первых, софт для платформы майкрософт - стандартные инструменты MS Windows Server, либо же обеспечение сторонних разработчиков.
Во-вторых, куда сливать и на чем хранить.

Любимым архиватором по планировщику, если нужно периодическое сохранение. Сохранять лучше на выделенный для этой цели жёсткий диск или флешку. На CD/DVD болванки тоже можно, если срок хранения не большой. Там намного больше риск потом не считать данные. Ни в коем случае не писать болванки средствами самой Винды. Имели место быть многократные случаи нечитабельности записанных таким образом дисков.

если данных немного и это обычная файловая помойка, то можно штатными средствами: плнировщик, скрипты, power shell.
Если у тебя есть какой-нибудь exchange , базы данных то тут надо смотреть какой объем данных, есть ли коридор, как будешь проверять целостность бэкапа, за какой период надо хранить. В последнем эксе например обещают встроенные средства, а так у семантека есть софт, например. Для баз тоже варианты есть. В общем как всегда - уточни какая задача.

ну как то болванки неинтересно, лучше выделить отдельную машину (можно убогую), поставить туда хард побольше и лить туда, но это совсем бюджетный вариант.

Проще купить ЮСБ коробку для винта. У меня такая лежит, подключённая к компу. Хранится на нём информация, которая нужна далеко не каждый день. Щёлкнул выключателем, он подсоединился, слил с него что надо или залил на него, выключил. И дальше лежит.

Присоединюсь к варианту хранения бэкапа на винте.

Для дома пользуюсь такой схемой - внешний винт + штатная архивация всего системного диска.

Cobian Backup 10
Free
Best

http://www.areca-backup.org/

Для дома, для семьи варианты не рассматриваем. Там все достаточно просто.
Более интересны варианты, когда надо делать бэкапы в сетке с нескольких серверов. Пара файловых, несколько баз данных (там, естественно, сливать резервные копии, сделанные средствами самой БД) и еще что-нибудь по мелочи.

скрипты + архиватор по шедулятору
все валмтся на рэйд, с которого по необходимости пишутся болванки

т.е. стандартные средства майкрософт, без ненужных наворотов.
Подерживаю.

именно так
простота - залог надежности
а чему ломаться в vbs непонятно, он же тупой как валенок
плюс грамотная политика, чтобы во время бэкапа к примету антивирь не свирепствовал, а то можно сильно удивиться

у меня rsync раз в 12 часов проходится и сливает изменения на резервную машину

Акронис

А слабо сразу зеркальный RAID поставить? Для дома будет даже с избытком надёжности.

для дома нафик не надо

ну или вот такой если очень хочется
http://flashcom.ru/market/product.php?ELEMENT_ID=85845&SECTION_ID=1739

Ну это если только для дома, для семьи. Ящик красивый.

Cobian Backup
simply The Best
free

т.е. в итоге у тебя получаются файлы? СУБД какие? Какие бэкапы они делают (холодные, горячие), как их проверять на валидность?

1. говорят не про дом
2. зеркальный рэйд не спасает от сбоев контроллера, был в практике случай когда дурил контроллер и на зеркало лил фигню, хотя диски были в порядке
Рэйд и резервное копирование это разные технологии обеспечения сохранности данных, в идеале на предприятии лучше использовать обе: на сервере где хрянятся данные RAID 5 например, а на сервере резервного копирования большие диски

Короче если все заканчивается файлами, то смотри какой объем данных надо забэкапить, прикинь свои финансовые ресурсы, прикинь временной коридор для копирования и спроси у начальства время на восстановление которое тебе дают. После этого строишь стратегию резервного копирования. Из железа я бы взял простенький сервак с большими и дешевыми дисками, если есть возможность - объединяй их в raid 0 так проще будет. Самый бюджетный вариант по софту - скрипты и планировщик (варианты с никсами мы разумеется не рассматриваем)

Т.е. на болванки лить не будем?

Заблуждение, кстати. Сколько вырванных волос пришлось наблюдать. Думали, что единожды настроенный комп это навечно.
Скажем так, если самостоятельное выполнение процедур по резервному копированию доставляет проблемы (а этол 99% домашних пользователей), то зеркалирование очень неплохой способ избежать проблем.

Угу. На домашнем компе, где в 90% случаев половину дискового пространства занимают игрушки, остальное музыка и фильмы, зеркалирование очень актуальная вещь.

Именно так. Ибо при переустановке в усмерть убитой системы, начинаются главные проблемы... А вот у меня тут игрушечка стояла, а теперь её нет, а мне она так нужна.

Ниче... Погорюет, перестанет.

Дома не делаю, просто важную инфу дублирую на флешку. На продакшн системах - специально написанные bash скрипты, выбирающие только измененные за некоторый период файлы и складывающие на специальную машину по ftp / sftp, плюс самопальный на bash-е же опять инструментарий позволяющий на основании инкрементального снапшота получить состояние файловой системы на любую  дату.

Да нет. В бытность, когда я ещё подрабатывал восстановлением упавших систем, иногда приходилось такого наслушаться.
Интересная позиция. Почему?

...вот потому:

вопрос в объемах. Оно тебе надо плодить болванки? Думать о том как разбить данные на порции по 4гига? постоянно их закупать? Еще вопрос  - есть требования по срокам хранения бэкапов? Если тебе надо хранить 3 года (иногде и такое бывает) и понадобится они могут только в очень радких случаях и разовый бэкап лезет на болванку, то да, пойдет, а иначе не вижу смысла.
Решение кроется в постановке задачи. И еще - мой опыт позволил сделать одно важно открытие и им я хочу поделиться:
Не надо зарабатывать себе геморрой за чужой счет
В данном случае все очень просто: ты специалист, директор компании наверняка не знает что такое бэкапы нахрен они нужны и как их делать, он платит тебе зарплату именно за то, что ты решаешь эти проблемы. Для него важно то, что он в любое время сможет получить свои файлики. Поэтому он тебе в данном случае доверяет. Ты приходишь к нему и говоришь: - Я предлагаю следующий вариант (дальше расписываешь, главное тут не показать ему какой красивый сервер мы покупаем, а какие затраты понесет компания и чего она в результате получит). Если его не устроит вариант, предлагаей более дешевый, но четко указывай на то чего он потеряет (время восстановления например/т.е. читай - время простоя работников), лучше чтобы это было зафиксировано как то. Зачем это нужно? Если случится косяк - ты будешь виноват, в том, что данные потерялись, именно тебе скажут - а нахрена ты копировал на болванки и потерял самы важные, или что то наподобие. Именно в такие моменты вспоминают во сколько обходится простой фирмы, потеря базы клиентов, которую надо восстанавливать, или базы 1С. Если ты предложишь руководству несколько вариантов (с точки зрения бюджета) и они выберут один не самый удачный, то ты им сможешь потом сказать, что это был их выбор и желание сэкономить 30т.р. вот пусть теперь мучаются, ты же сделал все что мог.
Резюме: деньги ты экономишь чужие , а вот проблемы будешь разгребать потом сам.

Потому, что если бы он был никсовым админам, то такие вопросы не задавал бы

разницы нет большой, что ты напишешь на PS , что напишешь на bash. Кстати второй проще.

ну и кстати для дома я бы себе не стал, щас есть более интересные коробочки с LAN и возможностью собирать raid, а так ты получишь usb диск по очень серьезной цене и тормоза USB

Интересная позиция... Мерседес ездит хорошо, поэтому мы на нём не поедем? Кстати, это касается толлько файлового архивирования. Базы данных методом копирования их файлов просто так не сохранишь. Только средствами самой БД. Хотя, всё равно, конечным результатом будет файл, который надо просто куда-то забросить. Стоимость гигабайта пространства самая низкая у жёстких дисков. Наиболее высокая надёжность тоже у них. Поэтому и делать ставку надо на них. А уж как организовать это - подключаемым ли диском, файловым ли сервером, самописными скриптами или встроенными в системы инструментами - всё зависит от ситуации.
Жёсткий диск и ничего более. Эра дискет, ленточек и лазерных дисков прошла.

Чиво, чиво?

Цом, не смотри на меня так. ..... Я женщин люблю.

все зависит от СУБД. И от размеров БД. Если у тебя база 1-2 гига, то сделать бэкап несложно, а вот если у вас база 300-400 гиг (хотя бы) и коридор на копирование 1-2 часа, то задача становиться не совсем тревиальной.

Тогда однозначно нужно не бэкапирование а репликация, и думать гадать нечего.

тут возникают следующие проблемы:
1. не все базы поддерживают подобные схемы работы
2. ПО для таких манипуляций обычно не входит в стандартную поставку СУБД и дорого
3. администрирование такой системы требует определенных навыков
4. вырастает время на саму репликацию, что снижает общую скорость работы
ну и вообще это отдельная тема разговора, достаточно сложная.

Согласен - тема сложная. Но при таких объёмах баз репликация это практически единственное
решение в плане резервного копирования.

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

и на серверах не сложнее
ибо
http://ru.wikipedia.org/wiki/BackupPC
http://ru.wikipedia.org/wiki/Advanced_Maryland_Automatic_Network_Disk_Archiver
http://ru.wikipedia.org/wiki/Bacula
и никаких самописных скриптов

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

сначала надо определиться что надо
дешево или надежно

ну оно как бы про разное
не заменяет одно другого
мне хорошо, у меня базы в 30 гигов, с ними легко
главное по времени разнести

то что мне надо я бэкаплю вообще все
системные диски бэкапят одмины, как - мне неинтересно, даже вникать не хочу

Уверен, они их не бэкапят...

именно поэтому я и не вникаю

боян, ага :)

большие юниксячьи системы уж сто лет как бекапят со снепшотов
принудительно сбрасываеш БДшный (где можно) и дисковый кеш, делаеш снепшот и спокойно сливаеш уже чем захочеш и когда захочеш
ибо забекапить например базу размером в 20 теров это нада окно бекапа в неделю
винда тоже доросла до снепшотов недавно, даж есть бекаполка мелкософтовская DPM называется, глюкало редкое, ничего кроме мелкософта не умеет бекапить. акроникс для дома - мелкого сервера вещь. я пользую простенькие скриптики реализующие логику хранения изменяемых данных и акроникс для виндузячьих разделов целиком, а юниксы tar\dump -ом бекаплю, но лучьше конешно бекапит централизовано. например очень понравился brightstor arcserve. под любую платформу и БД  (хоть под БСД)  есть агенты,  которые точно знают что как нада бекапить и востанавливать, мегалулезная софтина все что заявлено в доках работает как часы. сама выстраивает уже неплохую логику хранения и гибко настраивается если что-то не устраивает.

Иван, а чем гене бакап не устраивает? Или всё таки на виндус сервер запихнуть хотите?

Вып, дарагой и любезный офомилеп чо пачом  :)

Для мелких, крупных и тех шта по воле ветров стебаюцца...

А я говорю- Акронис.

Рабочая база на Раиде, бэкапится инкрементально Акронисом на большой винт
и потом ночью с него копия льётся на внешний ФТП.

1. ему нужно не только БД бэкапить
2. помимо инкремента нужно еще и фул переодически делать
3. нужно составить стратегию восстановления и периодически проверять в каком состоянии бэкапы
4. акронис денег стоит, и если там 1-2 сервера и базенка маленькая может оказаться избыточным решением
5. на фтп лить не стоит - лить ты будешь файл акрониса большой, при сбоях в сети он может приехать поломанным

адназначна акронис!
сам с ним не работал но справа от меня сидят 4 программиста его разрабатывающих, я им доверяю :)

ну если с нами саппорт... ;D

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

блиин, пошел флейм, тему можно закрывать