Отправлено: 16.01.12 10:36. Заголовок: Архивация в letodb

Хочу посоветоваться. Задача - сделать бэкап (архив) базы в произвольный момент времени.
Пусть архиватор будет 7z, хотя это не принципиально.
Утилита запускается на сервере, где установлен letodb, по определенному графику (хотя бы планировщиком).
Входные параметры: каталог БД и список расширений файлов, которые надо поместить в архив.
Предлагается такой алгоритм: сканируется все содержимое каталога БД, и формируется список @listfiles для архиватора.
Если это не файл данных, он просто добавляется в список. Если это файл данных, то выполняется попытка его открыть монопольно. Если попытка успешная - файл закрывается и добавляется в список.
Если нет - добавляется в список № 2 для 2-го прохода.
Для 1-го прохода через run вызывается архиватор, и ему дается список файлов.
Для 2-го прохода создается новый каталог, куда средствами letodb через команду copy to копируются открытые файлы, затем вызывается архиватор с командой добавления в архив файлов, которые не были заархивированы во время 1-го прохода.
Какие будут идеи ?

 Отправлено: 17.01.12 16:39. Заголовок: santy пишет: Бэкап ..

santy пишет:

цитата:

Бэкап (архив) базы - это критическая операция, её желательно делать, когда пользователи не работают в базе

У меня такое бывает крайне редко. Обычно это праздники. Обычно с базой идет работа 24 часа в сутки.

 Отправлено: 17.01.12 17:35. Заголовок: Если база крутится п..

Если база крутится постоянно, тогда нужно использовать средства сервера или специальные программы, например Effector saver 3 -Автоматическое архивирование баз данных 1С:Предприятия, произвольных данных ....

Возможно ли в Letodb реализовать команды резервного копирования?

 Отправлено: 17.01.12 17:37. Заголовок: Может использовать к..

Может использовать какой-то флаг (типа safety car), до флага все транзакции отрабатывают, а которые появились после флага становятся в очередь и ждут когда флаг уйдет с трассы, а в момент когда перед флагом место пусто (нет транзакций) запускается архивирование, флаг обнуляется, пошла нормальная работа. Как такой вариант?

 Отправлено: 17.01.12 19:54. Заголовок: Dima пишет: santy п..

Dima пишет:

цитата:

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

Ну, если выбор "между двух зол", то пауза в работе сервера зло все-таки меньшее, чем неполноценный бэкап

Паш, а на каких механизмах реализована поддержка транзакций в лето? Как обеспечивается одномоментность видимости всей совокупности изменений одной транзакции относительно других?

 Отправлено: 17.01.12 20:07. Заголовок: Pasha пишет: проще ..

Pasha пишет:

цитата:

проще использовать зеркалирование средствами ОС

Какими?

 Отправлено: 17.01.12 22:00. Заголовок: PSP пишет: цитата..

PSP пишет:

цитата:

цитата: проще использовать зеркалирование средствами ОС Какими?

Да вот хотя бы так:
http://support.microsoft.com/kb/307880

 Отправлено: 18.01.12 09:01. Заголовок: Паш, там вот такой т..

Паш, там вот такой текст:

"Вы не можете создавать зеркальные тома на компьютерах под управлением Windows XP Home Edition, 
 Windows XP Professional или Windows XP 64-Bit Edition. Однако вы можете использовать компьютер  
 с Windows XP Professional для создания зеркальных томов на удаленных компьютерах,  
 работающих под управлением серверных операционных систем Windows 2000 Server,  
 Windows 2000 Advanced Server или Windows 2000 Datacenter Server."

Только на Windows Server такое возможно. У меня же (да и у тебя, наверное) LetoDB работает на XP. А у некоторых - под Linux.
Может все-таки присмотришься к моему предложению, а? Всё может делаться самим сервером, отдельным его потоком, ничего останавливать не надо, нагрузки большой, имхо, не будет, файлы (как основные, так и копия) всегда открыты монопольно, индексы для копии создавать не нужно.

 Отправлено: 18.01.12 09:27. Заголовок: У меня на 98 крутитс..

У меня на 98 крутится .
PSP пишет:

цитата:

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

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

И еще вопрос - как при
PSP пишет:

цитата:

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

записать этот бекап на болванку, на флешку когда они открыты монопольно, север останавливать?

 Отправлено: 18.01.12 09:46. Заголовок: AlexMyr пишет: когд..

AlexMyr пишет:

цитата:

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

Ну, сервер должен быть защищен бесперебойником в любом случае. А без него любой бэкап будет непригоден для использования. Даже полный бэкап от MS SQL Server, если во время его создания выключить питание. Я думаю, всё будет зависит от того, писались ли данные в бэкап в момент отключения или нет. Если не писались, то может быть он и будет исправен. Предсказать это невозможно, имхо.

AlexMyr пишет:

цитата:

записать этот бекап на болванку, на флешку когда они открыты монопольно, север останавливать?

Я уже писал, что потоку, который создает бэкап, можно также поручить периодическое архивирование в zip.
А zip уже будет доступен для копирования и т.д.

 Отправлено: 18.01.12 09:57. Заголовок: PSP пишет: Я уже пи..

PSP пишет:

цитата:

Я уже писал, что потоку, который создает бэкап, можно также поручить периодическое архивирование в zip. А zip уже будет доступен для копирования и т.д.

Так, допустим zip у нас с датой 18.01.2012 10:00, следующий будет создан через 12 часов (или через сколько?), сейчас допустим 18.01.2012 12:13 и мне надо проверить данные в архиве, как быть?

 Отправлено: 18.01.12 10:01. Заголовок: AlexMyr пишет: как ..

AlexMyr пишет:

цитата:

как быть?

Можно придумать команду для сервера "Создать Архив Немедленно".

 Отправлено: 18.01.12 10:03. Заголовок: PSP пишет: Можно пр..

PSP пишет:

цитата:

Можно придумать команду для сервера "Создать Архив Немедленно".

Пришли к тому, о чем Паша спрашивал, вот

 Отправлено: 18.01.12 10:06. Заголовок: AlexMyr пишет: Приш..

AlexMyr пишет:

цитата:

Пришли к тому, что Паша спрашивал, вот

Нееее, отличия есть. Когда есть в наличии точная копия файлов базы данных, нет никакой проблемы сделать из нее zip. Даже zip делать не надо. Есть точная копия.

PS. Но, всё зависит от Паши. Помочь ему в написании этого не могу, поэтому умолкаю.

 Отправлено: 18.01.12 10:24. Заголовок: Pasha пишет: Пусть ..

Pasha пишет:

цитата:

Пусть архиватор будет 7z

7z умеет такое:

-ssw (Compress files open for writing) switch
Compresses files open for writing by another applications. If this switch is not set, 7-zip doesn't include such files to archive.

И делать update ( -u ). Хоть после каждой записи в таблицу...

 Отправлено: 18.01.12 10:46. Заголовок: Chikanuk пишет: 7z ..

Chikanuk пишет:

цитата:

7z умеет такое:

Проверил:
C:\TEMP\>7z a -ssw rrr.7z res.dbf

7-Zip 9.22 beta Copyright (c) 1999-2011 Igor Pavlov 2011-04-18

Scanning

Updating archive rrr.7z

Compressing res.dbf
WARNING: Процесс не может получить доступ к файлу, так как этот файл занят други
м процессом.



WARNINGS for files:

res.dbf : Процесс не может получить доступ к файлу, так как этот файл занят друг
им процессом.

----------------
WARNING: Cannot open 1 file

 Отправлено: 18.01.12 10:57. Заголовок: Chikanuk, это для фа..

Chikanuk, это для файлов, открытых в для совместного доступа. Для монопольно открытых не подойдет.

 Отправлено: 18.01.12 11:39. Заголовок: PSP пишет: Может вс..

PSP пишет:

цитата:

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

А сформулируй точно своё предложение, я что-то его не понимаю.

 Отправлено: 18.01.12 11:55. Заголовок: Sergey Spirin пишет:..

Sergey Spirin пишет:

цитата:

А сформулируй точно своё предложение

Попробую (всё это очень сыро, разумеется)...

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

Вот, вкратце. Можете пинать...

 Отправлено: 18.01.12 12:08. Заголовок: 1-й поток - идет тра..

1-й поток - идет транзакция, все успешно, 2-й поток заметил изменения и начинает архивирование и одновременно в 1-ом потоке начинается новая транзакция при которой происходит сбой вплоть до падения letodb, в результате архив получился не полным или битым. Что делать?
PSP пишет:

цитата:

Существуют файлы-копии в отдельной папке, в которые посредством отдельного потока того же сервера записываются последовательно те же изменения, которые внесены в лог.

Я правильно понимаю, что поток который делает архивирование ждет когда закончится основная транзакция?

 Отправлено: 18.01.12 12:12. Заголовок: В лог должна попадат..

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