PostgreSQL для 1С 8.3: ускоряем резервное копирование и восстановление для отдельной базы очень большого размера

Администрирование - Оптимизация БД (HighLoad)

PostgreSQL копирование восстановление pg_dump pg_restore psql copy 1C

68
PostgreSQL для 1С 8.3 ускоряем резервное копирование и восстановление для отдельной базы очень большого размера. В этой статье разберем оптимизацию работы с моментальным снимком отдельной базы 1С в кластере PostgreSQL средствами pg_dump.exe, pg_restore.exe, psql.exe в среде Windows Server 2008,2012,2016. А также разберем проблемные ситуации и неожиданные ограничения при работе 1С в связке с PostgreSQL. Для Linux все аналогично. Копирование-восстановление с помощью моментального снимка базы может потребоваться в разных случаях: - Копирование в другую базу в пределах кластера. - Копирование в другую базу на другом сервере с более высокой версией PostgreSQL. - Восстановление текущей базы. - Восстановление некоторых таблиц текущей базы в случае падения 1С и т.д.

PostgreSQL для 1С 8.3 ускоряем резервное копирование и восстановление для отдельной базы очень большого размера.

 

В этой статье разберем оптимизацию работы с моментальным снимком отдельной базы 1С в кластере PostgreSQL средствами pg_dump.exe, pg_restore.exe, psql.exe в среде Windows Server 2008,2012,2016. А также разберем проблемные ситуации и неожиданные ограничения при работе 1С в связке с PostgreSQL. Для Linux все аналогично.

Копирование-восстановление с помощью моментального снимка базы может потребоваться в разных случаях:

- Копирование в другую базу в пределах кластера.

- Копирование в другую базу на другом сервере с более высокой версией PostgreSQL.

- Восстановление текущей базы.

- Восстановление некоторых таблиц текущей базы в случае падения 1С и т.д.

 

Задача 1. Копирование базы 1С на лету во время работы пользователей с сохранением целостности с помощью команд pg_dump.exe, psql.exe. Для этого в общем случае алгоритм следующий:

Шаг 1. Выгружаем с помощью pg_dump.exe все таблицы из базы данных, кроме данных таблицы config (т.е. для config  выгружаем только ее схему)

Шаг 2. Выгружаем с помощью psql.exe данные таблицы public.config с помощью COPY WITH BINARY

 

Итак,

- Шаг 1. Выгружаем с помощью pg_dump.exe все таблицы из базы данных, кроме данных таблицы config (т.е. для config  выгружаем только ее схему):

"<путь к pg_dump>\pg_dump.exe" и далее параметры с комментариями

--host <ip адрес или имя хоста сервера>

--port <порт>

--username "postgres" – имя пользователя

--role "postgres" - роль

--no-password – не спрашивать пароль в пакетном режиме

--format directory – создавать архив в виде каталога для использования параметра --jobs. При этом каждая таблица копируется в отдельный файл в каталоге, что позволяет распараллелить процесс создания архива

--jobs=<количество параллельных потоков процессора> - подбирается примерно как <количество ядер процессора>*2, можно пробовать увеличение или уменьшение параметра, чтобы максимально загрузить систему, не мешая работе пользователей. Практически на каждый процесс запускается копирование одной таблицы из базы данных. Сколько процессов задействовано, столько таблиц и обрабатывается одновременно. С помощью этого параметра можно достигнуть ускорения резервного копирования в 4 раза и более в зависимости от мощности оборудования сервера.

--blobs – позволяет выгружать поля большого размера

--encoding UTF8 - кодировка

--verbose – включить подробное комментирование

--exclude-table-data=config - исключить из выгрузки данные таблицы config, т.е. выгрузить только ее схему (config содержит записи: конфигурация, конфигурации поставщиков, отличия основной конфигурации от конфигураций поставщиков). Это требуется, когда база находится на поддержке у двух и более конфигураций поставщика и (или) очень много изменений внесено в конфигурацию. При этом размер изменений основной конфигурации относительно конфигурации одного из поставщиков приближается к 1Гб, что является пределом для поля большого размера в PostgreSQL. А 1С хранит изменения только в одной из записей таблицы config. При небольшом размере конфигурации можно не использовать этот параметр. Но при критическом (если размер хотя бы одной записи таблицы public.config (конфигурации) после чтения и распаковки в стандартный поток вывода stdout превысит 1 Гб) pg_dump.exe завершится с ошибкой:

pg_dump: Ошибка выгрузки таблицы "config": сбой в PQgetResult().
pg_dump:  Сообщение  об ошибке с сервера: invalid memory alloc request size 11173708065
pg_dump: Выполнялась команда: COPY public.config (filename, creation, modified, attributes, datasize, binarydata) TO stdout;

Если используется --format custom, то архив выгружается в виде одного файла, и ошибка создания архива на таблице public.config обнаружится при выполнении команды pg_restore, что и есть самое неприятное:

pg_restore: обрабатываются данные таблицы "public._usersworkhistory" 
pg_restore: обрабатываются данные таблицы "public._yearoffset" 
pg_restore: обрабатываются данные таблицы "public.config" 
pg_restore: [внешний архиватор] не удалось прочитать входной файл: конец файла

(кроме того --format custom не позволит использовать --jobs - распараллеливание)

Наблюдается на больших конфигурациях KA 1.1-2.4, УПП 1.3, ERP 2.4.

--file "<имя каталога архива без таблицы config>"

"<имя базы данных>"

Шаг 2. Выгружаем с помощью psql.exe данные таблицы public.config с помощью COPY WITH BINARY:

md "<имя каталога архива только с таблицей config >" - создаем каталог для таблицы config

"<путь к psql>\psql.exe" – далее параметры

--host <ip адрес или имя хоста сервера>

--port <порт>

--username "postgres" – имя пользователя

--no-password – не спрашивать пароль в пакетном режиме

--command "COPY public.config TO '<имя каталога архива только с таблицей config с разделителями \\ для винды>' WITH BINARY;"

--dbname="<имя базы данных>"

 

Задача 2. Восстановление базы 1С в копию во время работы пользователей с сохранением целостности с помощью команд pg_restore.exe, psql.exe. Для этого в общем случае алгоритм следующий:

Шаг 0. Создаем пустую копию базы средствами pgAdmin.exe или с помощью psql.exe, dropdb, createdb.

Шаг 1. Загружаем с помощью pg_restore.exe все таблицы из архива базы данных, кроме данных таблицы config (т.е. для config  загружаем только ее схему)

Шаг 2. Загружаем с помощью psql.exe данные таблицы public.config с помощью COPY WITH BINARY

 

Шаг 0. Создаем пустую копию базы средствами pgAdmin.exe или с помощью psql.exe, dropdb, createdb.

Если база данных существует, мы должны сначала удалить ее из кластера с помощью команды DROP DATABASE "<имя базы данных>", а затем создать заново с помощью команды CREATE DATABASE "<имя базы данных>". Проще всего это сделать через pgAdmin, так как в нем есть запрос на удаление базы и образец запроса на создание базы. При удалении базы необходимо закрыть все соединения с базой, иначе база не будет удалена. Для Windows запрос на создание базы выглядит так:

 

CREATE DATABASE "<имя базы данных>"

WITH

OWNER = postgres

ENCODING = 'UTF8'

LC_COLLATE = 'Russian_Russia.1251'

LC_CTYPE = 'Russian_Russia.1251'

TABLESPACE = pg_default

CONNECTION LIMIT = -1;

 

Если мы время от времени хотим проверять, что база корректно достается из архива, то имеет cмысл автоматизировать шаг 0 в батнике командами psql, dropdb, createdb (добавлено по просьбам читателей):

 

0.1 Перед удалением закрываем все активные соединения с базой <имя базы данных>, кроме текущего:

"<путь к psql>\psql.exe" – далее параметры

--host <ip адрес или имя хоста сервера>

--port <порт>

--username "postgres" – имя пользователя

--dbname="<имя базы данных>"

--no-password – не спрашивать пароль в пакетном режиме

--command "SELECT pg_terminate_backend(pg_stat_activity.pid) FROM pg_stat_activity WHERE pg_stat_activity.datname = '<имя базы данных>' AND pid <> pg_backend_pid();"

 

0.2 Удаляем базу <имя базы данных>, если она существует без подтверждения об удалении.
"<путь к dropdb>\dropdb.exe"

--host <ip адрес или имя хоста сервера>

--port <порт>

--username "postgres" – имя пользователя

--no-password – не спрашивать пароль в пакетном режиме

--if-exists - проверка существования базы

--echo - вывод команд SQL, которые выполнит postgreSQL при вызове

"<имя базы данных>

 

0.3 Создаем заново базу <имя базы данных> после удаления
"<путь к createdb>\createdb.exe"

--host <ip адрес или имя хоста сервера>

--port <порт>

--username "postgres" – имя пользователя

--no-password – не спрашивать пароль в пакетном режиме

--echo - вывод команд SQL, которые выполнит postgreSQL при вызове

--owner="postgres" - владелец базы

--encoding="UTF8" - кодировка

--locale="Russian_Russia.1251" - устанавливает одновременно параметры LC_COLLATE и LC_CTYPE для базы данных.

--tablespace="pg_default" - указывает табличное пространство, используемое по умолчанию.

"<имя базы данных>"

Теперь уже не нужно даже лезть в pgAdmin и там корячиться.

Шаг 1. Загружаем с помощью pg_restore.exe все таблицы из архива базы данных, кроме данных таблицы config (т.е. для config  загружаем только ее схему):

"<путь к pg_restore>\pg_restore.exe"

--host <ip адрес или имя хоста сервера>

--port <порт>

--username "postgres" – имя пользователя

--role "postgres" - роль

--no-password – не спрашивать пароль в пакетном режиме

--dbname "<имя базы данных в которую восстанавливаем>"

--jobs=<количество параллельных потоков процессора> - подбирается примерно как <количество ядер процессора>*2, можно пробовать увеличение или уменьшение параметра, чтобы максимально загрузить систему, не мешая работе пользователей. Практически на каждый процесс запускается восстановление одной таблицы базы данных. Сколько процессов задействовано, столько таблиц и индексов обрабатывается одновременно. С помощью этого параметра можно достигнуть ускорения восстановления базы в 2-3 раза и более в зависимости от мощности оборудования сервера.

--verbose – включить подробное комментирование

"<имя каталога архива без таблицы config>"

 

Шаг 2. Загружаем с помощью psql.exe данные таблицы public.config с помощью COPY WITH BINARY

"<путь к psql>\psql.exe" – далее параметры

--host <ip адрес или имя хоста сервера>

--port <порт>

--username "postgres" – имя пользователя

--dbname="<имя базы данных>"

--no-password – не спрашивать пароль в пакетном режиме

--command "\COPY public.config FROM '<имя каталога архива только с таблицей config с разделителями \\ для винды>' WITH BINARY;"

 

Обратите внимание на метакоманду \COPY вместо просто COPY.

\COPYоткрывает файл и передает содержимое на сервер, тогда как COPY сообщает серверу, что он сам открывает файл и читает его, что может быть проблематичным по разрешению или даже невозможно, если клиент и сервер работают на разных компьютерах без совместного доступа к файлам между ними.

Соответственно при использовании просто COPY может выскочить следующая ошибка:

Postgres ERROR: Permission denied (не удалось открыть файл для чтения)

Заметим, что архив базы может быть успешно восстановлен на последующих версиях  PostgreSQL. В моем случае, я переносил базу с сервера PostgreSQL 9.6 на PostgreSQL 10.3.

Все проходило гладко. Трудности теоретически могут возникнуть в команде  \COPY, т.к. она является платформо-зависимой.

На реальной базе размером 380 Гб за счет распараллеливания было достигнуто ускорение при работе pg_dump - в 4 раза, при работе pg_restore - в 2,5 раза, что весьма существенно, когда процесс занимает несколько часов.

 

Было: 2 часа на копирование, стало 0,5 часа на копирование; было 10 ч на восстановление, стало 4 ч на восстановление.

 

Ниже привожу примеры bat-файлов (качайте) для создания архивной копии базы данных DO_PROBA и восстановления в другую базу данных DO_PROBA_COPY. При этом в названии каталогов архива используется дата и время начала архивации и выводятся замеры времени на создание-восстановление. При восстановлении из вновь созданного архива необходимо каждый раз менять дату и время в bat-файле для восстановления (ее можно скопировать из имени каталога архива по образцу). Теперь будьте очень осторожны при восстановлении базы. По просьбам читателей и пользователей в bat-файлы добавлены команды автоматического удаления и создания восстанавливаемой базы в случае ее существования. Не ошибитесь в наименовании базы в команде SET ar_base_to=<Имя базы, куда восстанавливаем> !!! Иначе можно легко порушить существующие базы. 

СОВЕТ: периодически проверяйте (хотя бы раз в неделю) загрузку бэкапа в какую-нибудь тестовую базу и запускайте для проверки работоспособности режим конфигуратора 1С и рабочий режим. Тогда всегда будете уверены в своей архивной копии!!!

68

Скачать файлы

Наименование Файл Версия Размер
PostgreSQL для 1С 8.3 ускоряем резервное копирование и восстановление для отдельной базы очень большого размера.:
.zip 1,67Kb
08.12.18
8
.zip 1,67Kb 8 Скачать

См. также

Специальные предложения

Комментарии
Избранное Подписка Сортировка: Древо
1. PbI4 1 04.12.18 23:40 Сейчас в теме
02.11.18 14:48

А ни у кого не случается иногда такая ошибка при ресторе?

pg_restore: обрабатываются данные таблицы "public._usersworkhistory"
pg_restore: обрабатываются данные таблицы "public._yearoffset"
pg_restore: обрабатываются данные таблицы "public.config"
pg_restore: [внешний архиватор] не удалось прочитать входной файл: конец файла


Причём всегда после конфига и иногда рестор отрабатывает без ошибки на том же самом дампе

месяц прошёл в старой теме (https://infostart.ru/article/rezervnoe-kopirovanie-i-vosstanovlenie-bazy-1s-sredstvami-postgresql-540298/), повторим - может есть адекватные ответчики, спасибо
3. vsasav 345 05.12.18 09:31 Сейчас в теме
(1) Это и есть грабли, которые описаны в статье, когда pg_dump не может выгрузить public.config. Для этого и применяется команда COPY в статье.
Сам недавно наткнулся на них. Это означает - ваш архив базы - битый, но это вы не увидите, пока не используете pg_restore. Используйте мой вариант, когда отдельно выгружается public.config с помощью COPY WITH BINARY. Он будет работать всегда, т.к. конфигурация относительно редко меняется.
4. vsasav 345 05.12.18 10:57 Сейчас в теме
(1) Теперь можете свой -1 поменять на +1 ;)
2. frkbvfnjh 387 05.12.18 08:57 Сейчас в теме
Спасибо, много нового узнал! И главное описано очень понятно и детально.
5. starik-2005 1443 05.12.18 12:47 Сейчас в теме
+ просто за то, что кто-то пишет про постгри.
6. DonAlPatino 48 05.12.18 13:20 Сейчас в теме
Т.е. "просто" как в MS SQL бэкап во время работы пользователей на лету сделать нельзя? Это для всех версий postgress актуально?
8. vsasav 345 05.12.18 13:49 Сейчас в теме
(6) pg_dump - это и есть бэкап на лету (моментальный снимок), актуально для PostgreSQL 9.Х и выше
11. DonAlPatino 48 05.12.18 15:08 Сейчас в теме
(8) "просто" - это по одной кнопке все-таки (простите человек, испорченного MS), а не набором скриптов, с последовательной выгрузкой отдельных таблиц. Вот это "спотыкание" на отдельных таблиц - это стандартная ситуация или просто "временами бывает"?
12. starik-2005 1443 05.12.18 15:29 Сейчас в теме
(11)
"просто" - это по одной кнопке все-таки (простите человек, испорченного MS), а не набором скриптов
ИМХО, любой скрипт плавно превращается в одну кнопку. Не?
15. TODD22 17 05.12.18 18:02 Сейчас в теме
(12)после 3х дней гугла и чтения мануалов. Набор запчастей превращается в автомобиль после трех дней сборки. А хотелось бы взять готовый, сесть и поехать сразу.
Fox-trot; +1 Ответить
18. vsasav 345 05.12.18 21:45 Сейчас в теме
(11) Тут ничего не поделаешь: ограничение PostgreSQL на 1 Гб в длине поля типа binary по чтению в stdout. Аналогичные грабли мы нашли бы, думаю, и в MSSQL на 1С, если бы размер изменений конфигурации приблизился к 2 Гб, но на практике никто такого еще видимо не испытывал. Так что все впереди. PostgreSQL тут ни при чем. Это особенность реализации от 1С. Можно было бы не в одну запись пихать изменения, а в несколько. К счастью ошибка обходится с помощью COPY WiTH BINARY.
7. TarasovAV 05.12.18 13:38 Сейчас в теме
Т.е., если база небольшая, скажем до 500 МБ, то бэкапирование с помощью --format custom пройдет успешно? И при восстановлении не возникнет указанная ошибка?
9. vsasav 345 05.12.18 14:04 Сейчас в теме
--format custom пройдет успешно на базе любого размера, только если размер ни одной из записей таблицы public.config (конфигурация) после чтения и распаковки в стандартный поток вывода stdout не превысит 1 Гб, то же самое касается формата --format directory. Для небольших по объему размеров конфигураций - прокатит, но для больших в один самый неожиданный момент завершится с ошибкой, повторяюсь:

--exclude-table=config - исключить из выгрузки таблицу config. Это требуется, когда база находится на поддержке у двух и более конфигураций поставщика и (или) очень много изменений внесено в конфигурацию. При этом размер изменений основной конфигурации относительно конфигурации одного из поставщиков приближается к 1Гб, что является пределом для поля большого размера в PostgreSQL. А 1С хранит изменения только в одной из записей таблицы config. При небольшом размере конфигурации можно не использовать этот параметр. Но при критическом pg_dump.exe завершится с ошибкой:

pg_dump: Ошибка выгрузки таблицы "config": сбой в PQgetResult().
pg_dump: Сообщение об ошибке с сервера: invalid memory alloc request size 11173708065
pg_dump: Выполнялась команда: COPY public.config (filename, creation, modified, attributes, datasize, binarydata) TO stdout;

Если используется --format custom, то архив выгружается в виде одного файла, и ошибка создания архива на таблице public.config обнаружится при выполнении команды pg_restore, что и есть самое неприятное:

pg_restore: обрабатываются данные таблицы "public._usersworkhistory"
pg_restore: обрабатываются данные таблицы "public._yearoffset"
pg_restore: обрабатываются данные таблицы "public.config"
pg_restore: [внешний архиватор] не удалось прочитать входной файл: конец файла

(кроме того --format custom не позволит использовать --jobs - распараллеливание)

Наблюдается на больших конфигурациях KA 1.1-2.4, УПП 1.3, ERP 2.4.
DonAlPatino; A_Max; Fox-trot; neyasytyf; TarasovAV; +5 Ответить
20. DonAlPatino 48 06.12.18 10:21 Сейчас в теме
(9)Спасибо большое - вот теперь все понятно.
10. TarasovAV 05.12.18 14:10 Сейчас в теме
Спасибо за развернутый ответ.
13. neyasytyf 05.12.18 16:03 Сейчас в теме
Спасибо за третий шаг
Шаг 3. Загружаем с помощью psql.exe таблицу public.config с помощью COPY WITH BINARY


Сам делал через:
psql -c "COPY (select * from public.config where datasize < 629605263) TO '/var/lib/pgsql/arhiv/$filename.config'" db
Но потом необходимо cf подгружать.

Вместо --exclude-table можно использовать --exclude-table-data=config, тогда структура таблицы config выгрузится без данных, и можно в два шага выгружать.
A_Max; CSiER; Fox-trot; vsasav; +4 Ответить
14. vsasav 345 05.12.18 17:36 Сейчас в теме
(13) Да, про --exclude-table-data=config - ценное замечание. Пожалуй, откорректирую статью. Во всем должна быть минимизация.
A_Max; neyasytyf; +2 Ответить
17. vsasav 345 05.12.18 18:39 Сейчас в теме
(13) Минимизировал статью в соответствии с указанным выше замечанием. СПАСИБО !
19. neyasytyf 06.12.18 09:44 Сейчас в теме
(17) Ну тогда еще стоит упоминуть, что создать базу можно командой createdb из консоли. Так удобней в скриптах для восстановления делать, чтобы не использовать psql.
22. vsasav 345 06.12.18 12:42 Сейчас в теме
(19) Хорошо, тогда уж и dropdb для кучи для удаления базы. Приведу примеры в следующей модификации статьи.
25. vsasav 345 06.12.18 17:44 Сейчас в теме
Внимание!!! По просьбе (19) и к счастью для всех, кто хочет все одной кнопкой статья была доработана!!!

Теперь будьте очень осторожны при восстановлении базы. По просьбам читателей и пользователей в bat-файлы добавлены команды автоматического удаления и создания восстанавливаемой базы в случае ее существования. Не ошибитесь в наименовании базы в команде SET ar_base_to=<Имя базы, куда восстанавливаем> !!! Иначе можно легко порушить существующие базы.
16. Gavris 05.12.18 18:14 Сейчас в теме
Приветствую.
Побилась база 1с.
Есть бекап в виде выгрузки 1c из postgres 9.4 формат *.sql
Весит 100 гигов.
Обратно не загружается. Ввожу вот такую команду
"C:\Program Files\PostgresPro 1C\9.4\bin\psql.exe" -U postgres gef_restore < E:\BackUp\gef201811300311.sql

Выводит вот такое: http://joxi.ru/p27K7a9UoXZ332
Посоветуйте что можно сделать. Готов заплатить.
21. vsasav 345 06.12.18 12:22 Сейчас в теме
(16) В данном случае копия БД скорее всего не является целостной, т.к. использована сторонняя программа с неизвестной внутренней реализацией.
Необходимо для создания архива использовать pg_dump, pg_restore. Вот что написано в документации: https://postgrespro.ru/docs/postgresql/9.4/app-pgdump

pg_dump
Название
pg_dump -- выгрузить базу данных PostgreSQL в формате скрипта в файл или архив
Синтаксис
pg_dump [ параметр-подключения ...] [ параметр ...] [ база_данных ]

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

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

Для восстановления из архивных форматов файлов используется утилита pg_restore. Эти форматы позволяют указывать pg_restore какие объекты базы данных восстановить, а также позволяют изменить порядок следования восстанавливаемых объектов. Архивные форматы файлов спроектированы так, чтобы их можно были переносить на другие платформы с другой архитектурой.

Применение архивных форматов в сочетании утилит pg_restore и pg_dump позволяет организовывать эффективный механизм архивации и переноса данных. pg_dump можно использовать для резервирования всей базы данных, а затем при применении pg_restore выбрать нужные объекты для восстановления. Наиболее гибкие форматы резервных файлов это "custom" (-Fc) и "directory" (-Fd). Они позволяют выбрать и изменить порядок объектов, поддерживают восстановление в несколько потоков, а также сжимаются по умолчанию. При этом формат "directory" единственный, позволяющий выгружать данные в несколько потоков.

Во время работы pg_dump следует обращать внимание на предупреждения, которые печатаются в стандартный поток ошибок, особенно ввиду рассмотренных далее ограничений.
23. starik-2005 1443 06.12.18 14:27 Сейчас в теме
(16)
Выводит вот такое: http://joxi.ru/p27K7a9UoXZ332
По всей видимости в таблице Документ242 в одном из полей содержится что-то в поле флд6173, что делает уникальный индекс неуникальным. Можно в скульной выгрузке найти скрипт создания таблицы и удалить из него команды создания индексов. Ну а потом уже в 1С ТиИ с реструктуризацией.
24. vsasav 345 06.12.18 15:27 Сейчас в теме
(23) Да, кроме копания в коде SQL ничего не остается. Скорее всего строка № 97413 таблицы документа 242 порушена, но я могу ошибаться, т.к. текст ошибки нечитабельный. Нужно искать по содержимому поля fld и пробовать удалять битые записи и связанные с ними записи других таблиц документа.
26. trdm 08.12.18 09:32 Сейчас в теме
(24)
Да, кроме копания в коде SQL ничего не остается.

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

(23) А сколько в архиве весит файло?
27. starik-2005 1443 08.12.18 21:03 Сейчас в теме
Оставьте свое сообщение