Средства и способы бэкапа (вопросы и ответы)

[PLAstic]

Вопрос создания архивных копий системы и данных весьма важен в работе сисадмина.

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

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

Обсуждаются именно самодельные/нестандартные и иные способы. ПО для бэкапа обсуждается в разделе Архиваторы, системные и тест прог

Это значит, что посты на темы "я использую то-то или то-то для создания архивных копий" здесь не уместны.

[bellic]

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

Модераторам! - Я думаю вы не будете возражать, поместив эту тему в разделе ВАЖНО, закрепив это первое сообщение в шапке темы?!
А я буду по мере сил дополнять шапку на основе своего опыта, материалов в сети и мнений пользователей форума.. - Получится думаю не плохой FAQ по этому вопросу!!
Может ТЕМУ назвать как-то по другому? (предложите)
================================================== ================================================== ==========================
Вступления пока не будет - не хочется лить зря воду..

Параметры системы и Софта.
Имеем к примеру пару мощных Серверов с MS Windows 2008 Server EE R2 (..иль 2003 - это я думаю тут не важно..)
На 1-м установлена база MS SQL (под управлением MS SQL Server 2008) - в моём случае это пара баз 1С8 УСО (Реальная и Демо)
2-й будем использовать как Файл-Сервер для хранения Бэкапов SQL-баз.

Постановка задачи (общие намётки).
1. В назначенное время создать Бэкап SQL-базы;
2. Сжать (на примере WinRARa) полученный Бэкап;
3. Перекинуть Сжатый архив по сетке на Файл-Сервер
4. Подчистить за собой "следы"...

Маленькое отступление по поводу 1С-баз и способов их бэкапа:
Несомненно бэкап SQL 1С-баз можно выполнить несколькими способами, каждый из которых имеет свои ПЛЮСЫ и МИНУСЫ.

Попробую их озвучить (Если что - помидорами не кидать - а лучше вежливо подсказать...):

Вариант I - условно назову его БЭКАП ФАЙЛОВЫЙ...
Его суть - остановка SQL-сервера(?!) (иль может просто отсоединение базы? - уточню позже), затем обычное копирование файлов, и опять подключение Базы...
Данный вариант был подсказан по ссылке: http://www.onlinebackup.ru/index.php?chap=3&part=11
Минусы:
- необходимость "отсоединение" базы от SQL-Сервера (Самый пожалуй ЖИРНЫЙ минус);
- необходимо запускать, когда никто не работает с базой, а для пущей надежности - проверить и "кикнуть" зависших юзеров.(Минус чут по меньше верхнего)
- при написании скрипта (для автоматического выполнения бекапа) нужно мудрить с командами sql-сервера (хотя я думаю там ничего сложного нету)
- получаемый "простой"(бездействие) системы, вытекающий из двух первых "минусов"
...
Плюсы:
...


Вариант II - условно назову его БЭКАП СРЕДСТВАМИ 1С
Суть - на языке 1С пишется специальная процедура, которая запускается из под 1С, и выполняет необходимые действия...
Как правило данная процедура пишется самими админами или кодерами и готовых решений пожалуй нету..
Минусы (чисто моё мнение):
- необходимость проверки и "вышвыривания" зазевавшихся пользователей из базы...
- возможно трудности с написанием кода (если вы не кодер 1С)
- Нет Юзеров - нет Работы - значит система простаивает..
- ...
Плюсы:
- Небольшим плюсом является экономия места(по ВАШЕМУ мнению)
- писать код не обязательно. Есть так-называемые пакетные задания, на которые можно просто повесить выгрузку (на правах цитаты)
...

Вариант III - условно назову его БЭКАП СРЕДСТВАМИ SQL
Суть - выполнение спец.команд по Бэкапу, которые заложены уже в сам SQL-сервер...
Минусы:
- нет достаточной гибкости в языке управления (но это решаемо другими путями)
- ...
Плюсы (Имхо):
- Не надо никого выгонять из Базы... (бэкап можно выполнить "на лету" - не прерывая работу Основной системы и Юзеров)
- Бэкап выполняется достаточно быстро (Видно Заточены Инструменты хорошо под это..))))
- акромя самого Бэкапа можно выполнить дополнительные задания по обслуживанию базы (тут речь про те самые "встроенные бэкаперы" в MSSQL, о котором поведал "умный человек")
- ...

Если кто знает другие варианты - просьба подсказать

....

Предлагаю подробно рассмотреть Вариант III - БЭКАП СРЕДСТВАМИ SQL - по моему Имхо самый удачный...
Будут применяться:
- команда sqlcmd.exe (кому надо - смотрим по ней хелп)
- архиватор WinRar из консольного вызова

На данный момент архивация на моём SQL-сервере выполняется следующим образом:
- по Виндовому Шедуллеру запускается bat-скрипт примерной конфигурации:

Цитата: rem ======== Создаем Бэкап SQL-базы средствами sqlcmd ============= sqlcmd -E -S "localhost" -Q "BACKUP DATABASE [sql_base] TO DISK = N'D:\BackUp\BackUpSQL\sql_base_backup.bak' WITH NOFORMAT, NOINIT, NAME = N'sql_base_backup', SKIP, NOREWIND, NOUNLOAD, STATS = 10">D:\BackUp\BackUpSQL\backup_sqlbase.log rem ========== Сжимаем полученный Бэкап RAR-ом с присваиванием текущей Даты, кидаем на Файл-Сервер ============ C:\Bat_Scripts\Rar.exe a -m3 Z:\BACKUP_SQL_BASE\%date%_sql_base.rar D:\BackUp\BackUpSQL rem ========== Т.к. Архив с Бэкапом перенесён на Файл-Сервер, чистим папку ============= del /S /Q D:\BackUp\BackUpSQL\*.*

Пояснения:
1. Скрипт лежит в директории C:\Bat_Scripts\, туда же помещён Rar.exe
2. sql_base - имя SQL-базы
3. D:\BackUp\BackUpSQL\ - директория куда временно помещается ПОЛНЫЙ Бэкап с именем sql_base_backup.bak
4. Лог выполнения бэкапа помещается в эту же директорию с именем backup_sqlbase.log
5. Диском Z: на SQL-Сервере подключена Шара Файл-Сервера, для размещения "ужатого" Бэкапа
6. RAR-овскому архиву можно присвоить имя с учетом текущей системной даты

Предвижу ВОЗМУТИТЕЛЬНЫЕ возгласы по поводу запуска архивирования по сети!!!
Извиняйте братцы! - Конечно же очень желательно запустить Архивирование на самом SQL-Сервере, а уже потом перекинуть полученный архив на Файл-Сервер!!!
Будем исправлять это конечно!!!
Не сразу Москва строилась!

P.S. (она же ЗЫ):
Пометки на полях:
- по возможности не использовать Платные продукты;
- речь для начало вести о каждо-ночных Полных Бэкапах;
- глянуть что есть тут Фриварного: http://www.sqlbackupandftp.com/ и тут - и тут: http://effector.com.ua


Продолжение следует...

PS2: Убедительная просьба тем кто будет обсуждать и дополнять данную тему:
- слишком много не цитируйте из шапки темы (дабы не захломлять тему) - кратко и ясно, как это сделал уважаемый Alan2006
- на основе ваших обсуждений буду корректировать саму шапку.

[Alan2006]

Полностью цитировать не буду для удобства просмотра... Своё мнение по этому поводу выскажу...
Вариант I:
Так же необходимо вышвыривать пользователей из базы т.к. сервер скорее всего либо откажется отключаться от базы(что, кстати, маловероятно) либо вышвырнет пользователя. Второе чревато тем что какие-то данные могут быть просто потеряны из-за выполняемых в момент отключения действий.
Ещё один мелкий минус(чисто моё ИМХО) - при написании скрипта (для автоматического выполнения бекапа) нужно мудрить с командами sql-сервера.

Вариант II:
В принципе правильно НО писать код не обязательно. Есть так-называемые пакетные задания, на которые можно просто повесить выгрузку. В 7 это .rpm - файлы. В 8 не пробовал такое... но думаю это есть) Остаётся только запустить конфигуратор с пакетным заданием выгрузки и он сам всё сделает.
Небольшим плюсом является экономия места. При такой выгрузке выходящий файл получается сжатым - он уже без индексов и без избыточных данных но содержит данные и метаданные. Минус такой выгрузки - ненадёжность получаемого архива. Это следует именно из того, что избыточная информация не выгружается. При малейшем повреждении полученного на выходе файла его использовать для восстановления уже не получится...

Вариант III:
Имхо, самый надёжный способ... Что-то добавить не могу...

А вообще, все указанные выше способы лучше запускать когда пользователей нет в базе. Т.е. ночью...


З.Ы.: Полезная тема. Спасибо.

[Iskam]

В чём минус всех этих вариантов, включая и третий? В том, что базы могут быть огромными и тогда полная упаковка базы в первом варианте вызовет банальный простой существенное время (если говорить о производстве 24/7, то и полчаса - это много), а в третьем варианте (который, в общем то от второго отличается только внешним запуском винрара) каждый запуск вычислительные мощности будут уходить на полный перенос базы во временную папку и архивацию, но при этом пользователи смогут работать, возможно, ощущая некоторые тормоза.
Вот на случай, если эти тормоза напрягают, можно использовать красивый метод. База во временной папке не удаляется после архивации, а остаётся для дополнения. То есть туда копиряем не всю базу, а только, по сути, изменённые файлы. У меня на почти 30 гигабайтной месячной базе такой подход экономит очень много времени. То есть, буквально, полное копирование без индексов - минут 45-60, а дополнение временной базы - минут 10 от силы. Дальше уже работаем архиватором по сети с другой машины и сколько это времени и ресурсов займёт - в принципе плевать.

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

[Alan2006]

Цитата: Сообщение от Iskam если говорить о производстве 24/7, то и полчаса - это много

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

Цитата: Сообщение от Iskam а в третьем варианте (который, в общем то от второго отличается только внешним запуском винрара)

Ммм... не скажи... во втором случае информация не архивируется а выгружается только нужная...

Цитата: Сообщение от Iskam делать инкрементальные архивы

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

[bellic]

Братцы, мы пытаемся объять необъятное..

НЕсомненно:
1. В самом SQL есть многие вкусности и сервисы - мы думаю до них дойдём..
2. Про разностные архивы - ... давайте для простоты поставим себе задачу попроще - "Полные Каждодневные Бэкапы по Ночам"?
3. Общих схем бэкапа включающих Полные и Разностные тоже не будем предлагать - многое зависит от нагрузки на Систему..- правильно сказал Alan2006 - есть и ОСи и Сервера под это - ORACLE к примеру..
4. При том в этих вариантах разностных и Полных при работе юзеров не нужно забывать про Файлы Логов Транзакций - без них часть данных будет потеряна.
5. Давайте возьмём для примера Не-Нагруженную систему, которая позволит НОчью производить манипуляции с Бэкапами? Ну и не будем говорить пока про ОГРОМНЕЙШИЕ базы.. - для них Аналогично нужны свои Сервера, Свои ОСи.. и индивидуальный подход.
6. Думаю никто не будет возражать - если мы из ТРЁХ вариантов (БЭКАП ФАЙЛОВЫЙ, БЭКАП СРЕДСТВАМИ 1С, БЭКАП СРЕДСТВАМИ SQL, ) выберем III-й, как наиболее наверное распространенный (Имхо, по крайней мере по количеству публикаций о нем в Сети)???

Добавлено через 1 час 1 минуту
Я думаю Вы согласитесь обсуждать только Вариант III - БЭКАП СРЕДСТВАМИ SQL, как наиболее универсальный и достаточно гибкий?
Я Думаю встроенные в MSSQL вкусности, типа Планов Обслуживания, - они же "встроенные бэкаперы" - позволяющие делать как Полные, так и разностные Бэкапы -
Это хорошие инструменты (зря чтоль дядя Билл своим кодерам бабки платит?)

ЗЫ: ПО скорости создания файла Бэкапа (без ужимания Раром) могу сказать - что средствами SQL-сервера он выполняется достаточно быстро, а вот средствами 1С - не уверен.. - впрочем не могу сравнить, потому как сам не пробовал и не сравнивал.
НО что-то мне подсказывает, что 1С будет это дольше делать (Ну ясно ведь что 1С в этом случае - как дополнительное звено в цепочке к SQL-базе), хотя возможно и займет меньше места.

ЗЫ-2: Ща вот поразмыслил - 1-й вариант (Файловый) тоже пожалуй интересный - там ведь в базе всего два файлика (mybase_data.mdf и mybase_log.ldf к примеру) - бери и ужимай их чем хочешь! (правда вот не знаю - разностные архивы с них получится ли делать?)
Но конечно необходимость ОТключения базы, а перед этим - анализ на "спящих" юзеров и их тактичное "выкидывание" - очень уж портит этот способ (Имхо).

ЗЫ-3: По поводу Постоянно нагруженных систем...
В ОБЩЕМ думаю неплохим будет для них решением:
Полный Ночной бэкап (желательно в специально Отведённом на это времянном Окне - типа "выйти всем из баз 1С на 30 минут для профилактики")
(Хотя "выгон" в общем-то не обязателен - достаточно выбрать наиболее "нерабочее" время у Системы - например ОБЕД...)
+ РАЗНОСТНЫЕ Бэкапы "На лету" (без выгона юзеров) с необходимой переодичностью (тут уж сами решите - за какой отрезок времени допустима потеря информации)
И так - до следующего Полного Бэкапа в "Окне".

Кстати:
- Для моей молодой Базы (чуть более 1,2 Гига) ужатый RAR-ом Бэкап (Средствами SQL) составляет около 240 Мбайт...
- Время самого Бэкапа - точно не скажу, но счет в несколько СЕКУНД (!!!) - Глянул: 4,1 сек...)))
- Ужатие RAR-ом + некрасиво ужимать на сетевой диск - тут конечно подольше времени (но это уже ведь не критично - Бэкап то создан!)
...
...ВО на-ЗЫКАЛ...

[bellic]

Можно ещё добавить в команду:

Цитата: C:\Bat_Scripts\Rar.exe a -m3 Z:\BACKUP_SQL_BASE\%date%_sql_base.rar D:\BackUp\BackUpSQL

Опции для:
1. Добавления "ИНформации для восстановления" в получаемый архив, при этом возрастет Размер архива и время "Сжатия"
2. Добавить опцию, удаляющую "оригинальные" файлы после Сжатия

Вообще-то в скрипт не мешало бы добавить интеллекта - на предмет отслеживания Ошибок!?
Можно вообще его написать наверное на VBS + отправлять сообщения в Системный журнал Windows!?

PS: Надоть глянуть - нет ли у WinRAR-а ограничения на обрабатываемый файл и архив?
А то может сразу перенацелиться на бесплатный 7-zip ?

Ток вот в VBS я не шибко шарю... - ну чтож - придётся осваивать и его!

Забыл - не очень пожалуй нравиться что в получаемый архив попадают Каталоги из всего пути к Бэкапу...
Подскажите - как можно избавиться от этого? - иль наплевать?

[PLAstic]

Цитата: Сообщение от bellic Подскажите - как можно избавиться от этого? - иль наплевать?

У винрара есть ключик соответствующий: -ep1

[bellic]

Цитата: Сообщение от PLAstic У винрара есть ключик соответствующий: -ep1

Добавил указанный ключик, получилась команда:

C:\Bat_Scripts\Rar.exe a -m3 -ep1 Z:\BACKUP_SQL_BASE\%date%_sql_base.rar D:\BackUp\BackUpSQL

Однако в Архиве остался каталог BackUpSQL - ну это уже не так смертельно... - буду экспериментировать...
1. Как вариант - можно указать имя Ужимаемого Бэкапа - оно то известно... - тогда точно не будет никаких Каталогов, но там в каталоге с Бэкапом ещё лежит лог бэкапа,
можно конечно создать Список файлов для архивации(сжатия), надоть глянуть - какие ключики ещё можно попользовать!?
2. А лог бэкапа можно вообще не создавать..
3. Или выполнить команду сжатия для Лога в следующей строке (дабы не плодить добавочных файлов-списков) - и добавить его к уже Сжатому Бэкапу...
(хотя при этом возрастет наверное ЗНАЧИТЕЛЬНО общее время создания результирующего RAR-архива)-тогда уж лучше первые два варианта - со Списком включаемых файлов или Вообще без Лога!?

Можно попробовать ещё увеличить метод (степень) сжатия, заменив -m3 на -m4 (хорошее) или на -m5 (максимальное)
Кстати - ключик -m3 можно и не указывать - Обычный метод сжатия (используется по умолчанию)

НЕплохоб было ЗАБЛОКИРОВАТЬ Архив после всего этого?!

[PLAstic]

Цитата: Сообщение от bellic Однако в Архиве остался каталог BackUpSQL - ну это уже не так смертельно...

Всё делается немного проще:
"c:\program files\winrar\winrar.exe" a -m5 -rr -dh -x*.cdx -x*\ExtDb\*.* -x*.rar -x*.zip -x*.LCK -r -inul -oc -ppassword -agYYYYMMDD -ep1 E:\Архивы\DB.rar C:\DB2009\*.*

Где:
C:\DB2009 - каталог базы 1С
E:\Архивы\ - папка, куда будет положен архив
DB.rar - используя маску ключа -ag будет сформировано название с датой создания архива
password - пароль создаваемого архива

Почувствуй разницу между D:\BackUp\BackUpSQL и D:\BackUp\BackUpSQL\*.*

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

[marinss]

Доброго дня суток.

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

@ECHO OFF
SET PREFIX=%1
SET BAZA=%2


SET FOLDER=%DATE%

cd C:\BACKUP
mkdir "%FOLDER%"
cd "%FOLDER%"

ECHO Begin: %DATE% %TIME% > %PREFIX%.LOG

"C:\Program Files\WinRar\WINRAR.EXE" a -dh -m5 -ilog%PREFIX%.LOG %PREFIX%.RAR %BAZA%

ECHO. >> %PREFIX%.LOG
ECHO. >> %PREFIX%.LOG
ECHO End: %DATE% %TIME% >> %PREFIX%.LOG

cd C:\BACKUP



Второй, Здесь мы вызываем первый батник и указываем имя архива и путь к папке которую надо архивировать

cd C:\BACKUP
arhiv.cmd BZ1 c:\NVIDIA

Прелесть такого решения:
1. Первый батник правится только один раз
2. Во втором можно быстро добавлять команды для архивации нужных папок

Удачи.

[BoriZ]

Подскажите пожалуйста.
Настроен бэкап в SQL 2005,
1) ночью делается один раз полный
BACKUP DATABASE [ACC]
TO DISK =
N'D:\BACKUP\ACC.bak'
WITH NOFORMAT, INIT, NAME = N'ACC-Full Database Backup', SKIP, NOREWIND, NOUNLOAD, STATS = 10;

2) Чуть позже бекап лога с перезаписью
BACKUP LOG [ACC]
TO DISK =
N'D:\BACKUP\ACC.Log'
WITH INIT, NAME = N'ACC- Backup Log', SKIP, NOREWIND, NOUNLOAD, STATS = 10;

3) и дальше через каждый час идет добавление в новый бэкап лога
DBCC SHRINKFILE(ACC_log,1000)
BACKUP LOG [ACC]
TO DISK =
N'D:\BACKUP\ACC.Log'
WITH NOINIT, NAME = N'ACC- Backup Log', SKIP, NOREWIND, NOUNLOAD, STATS = 10;
DBCC SHRINKFILE(ACC_log,1000)

И вроде бы все нормально, в родной SQL весь бекап с шагами лога восстанавливается, но другом (тестовом) сервере не могу поднять бекап из логов, получается только с полного.

Говорит что том устройства ACC.Log не является частью множественного семейства набора носителей ???

Всем спасибо, разобрался полный надо поднять с NORECOVERY (!)
RESTORE DATABASE [ACC] FROM DISK = N'E:\Backup\ACC_s102\ACC.bak' WITH FILE = 1, NORECOVERY, NOUNLOAD, REPLACE, STATS = 10
GO

[bob_032]

Ктонибуть использует стримеры для резервного копирования в Server 2008 я понимаю чтоони от них отказались я сам под Линуксом до этого сидел там удобно с ним работать было привык малость и СТример стоит только не юзается.

[Alan2006]

По бекапу 1с 7.7 баз пакетным заданием:
1. Нужно создать файл с расширением .RPM в каталоге базы данных (назовём его savedata.rpm)
2. Пишем в него следующее:

[GENERAL]
Output=ReindexSavedata.log
Quit=1
CheckAndRepair=0
UnloadData=1
SaveData=0
AutoExchange=0

[UnloadData]
UnloadToFile=D:\1CBackup\SaveData.zip
IncludeUserDef=1

Вместо "D:\1CBackup\SaveData.zip" соответственно можно указать и другое полное(с путём) имя файла

3. Создаём cmd файл и помещаем его куда удобно.
4. Заполняем его следующим содержим:

"C:\Program Files\1cv77\bin\1cv7.exe" CONFIG /D"D:\База" /NUser /Ppassword /@savedata.prm

Где:
- "C:\Program Files\1cv77\bin\1cv7.exe" - путь к экзешнику 1с (кстати может быть имя другое, к примеру для sql версии имя файла будет "1cv7s.exe". + Смотрите куда устанавливали);
- "D:\База" - путь к архивируемой базе;
- User - Имя пользователя в 1с. Лучше всего с администраторскими правами;
-password - пароль этого пользователя.
-savedata.rpm - имя созданного в п.1 файла.
5. Шедулим получившийся cmd - файл и готово.

У меня добавлены ещё такие строки чтобы хранить архивы за несколько дней:

set d=%date: =%
set d=%d:.=-%
move /Y "D:\1CBackup\SaveData.zip" "Q:\1CBackup\1c-%d%.zip"

Плюсы:
- Не зависимость от платформы - не важно dbf-ная ли база или sql-ная;
- Не нужно мучиться с детачем - аттачем в скрипте базы (к примеру на энтерпрайс версии sql сервера);
- 1с сама выгрузит только нужные для восстановления данные.
- Немного поколдовав с rpm файлом можно делать ещё и другие действия: к примеру, пересчет итогов и проверка логической и физической целостности или реиндексацию для DBF базы;
- Объём. У меня из почти гиговой sql базы (~750метров база и ~250 журнал транзакций) получился 50 метровый архив.

Минусы:
- В базе не должно быть пользователей во время архивации;
- Для архивации других данных из папки с БД нужно будет дописывать cmd скрипт. К примеру у меня в этом же скрипте архивируюся отдельно печатные формы и внешние обработки;
- Получившиеся архивы более чувствительны к повреждением из-за отсутствия избыточной информации (моё субъективное мнение);
- Время. по сравнению с простой архивацией через скажем rar время увеличивается (Опять же по моим ощущениям. Я не замерял.).

[marinss]

qweyyyyyyyyy, Уважаемый, варантов в этой ветке на любой вкус.
Как варианты:
1.Всю базу/папку с базами - Подойдет акроникс, Написать батник под винрар, просто организация копирования на другой комп.
2.Автоматическая выгрузка из 1С.
3.Есть спец проги для бекапа 1С.

Что для тебя меньше проблем то и выбирай.
В организации есть акроникс, я его и юзаю, хотя дополнительно делаю архив раром.

[Alan2006]

Цитата: Сообщение от marinss 1.Всю базу/папку с базами - Подойдет акроникс, Написать батник под винрар, просто организация копирования на другой комп.

если 7-ка SQL-ная то бекап просто папки не катит... ибо даст только бекап МД файлов, служебных папок юзверей и папки внешних печатных форм (если они лежат как по умолчанию в папке базы)... чтобы раром забекапить ещё и данные нужно детачить файлы SQL базы потом архивить их и потом снова аттачить...