Добрый день!

Всегда пользовался RAR ом, но стал сомневаться.

Имеем 40 филейных баз на одной конфигурации, при архивировании файлов 1CD при 90% ой идентичности получаем на выходе только 50% ое сжатие.

Может сжатие пофайловое? А надо комплексное? Может есть ключ какой-либо?

Сжимаю глубиной m3

CF уже сжат

два CF надо сжимать не по отдельности, а вместе.

раньше, во времена JAR было многопроходное сжатие...

Лучше не объединять 40 баз в один архив. Для каждой базы нужен собственный архив

Дедупликацию можно организовать на уровне файловой системы (NTFS, ZFS)

Ещё можно проводить синхронизацию с центром и бэкапить только центральную базу.
Подразумевается, что любую филиальную можно создать из центральной.

(0)

Вроде эра больших накопителей и гигабитного интернета уже наступила. Или нет ?

(6) да, но эти бэкапы вырываются вперёд со своими размерами

(7) Файловые базы и большие размеры? Как-то у меня одно с другим не сочетается...

SQL давно научился делать бекапы и быстро и сжимать так, что после уже ничего сжимать не нужно.

переводите свои филейные базы на серверную структуру.

(9) рад за SQL но не по карману

(1) возможно в этом (если речь про 1CD, а не CF) и проблема основная, провожу эксперименты.

(10) Ms sql express, PG ?

(0) попробуй 7z
это давно де факто стандарт
но учти для хорошего сжатия надо или время или очень мощный многоядерник

(13)+ еще можно бэкапить только данные
не сохранять конфу саму, если она не меняется
использовать разностные бэкапы

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

(10) Новая лицензия разработчика как использовать дома (на виртуалке?)?

Как я себе установил полностью лицензионный сервер 1с

1. качаем и устанавливаем

https://learn.microsoft.com/ru-ru/sql/ssms/download-sql-server-management-studio-ssms?view=sql-server-ver16  примерно 650 метров
и
https://www.microsoft.com/ru-RU/download/details.aspx?id=101064 маленький, после запуска скачиваем полный дистриб  SQLEXPRADV_x64_RUS примерно 850 метров, ограничения на использования бесплатной версии https://learn.microsoft.com/ru-ru/sql/sql-server/editions-and-components-of-sql-server-2019?view=sql-server-ver16
максимум 1 камень и максимум 4 ядра, максимальный размер одной базы - 10 гигов

2. регистрируемся на https://developer.1c.ru/
3. ставим себе сервер 1с и платформу
4. при запуске базы получаем Комьюнити лицензию по логину и паролю из 3.


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

(16)


P.S.

И как это ему поможет с его 40 периферийными базами (магазинами) ?

Приходят в магазин "компетентные органы", а директор им:
-- Это тетя Маша. По четным она уборщица, а по нечетным разработчик 1С !

для магазина - SQL бесплатно, и лицензия на минисервер 1с (17 тр), думаю ЛЮБОЙ магазин (даже ларек) может себе позволить это...

(18)И как это связано с комьюнити лицензией про который речь зашла в (16)?
И что делать ТС если у него больше 5 подключений?

И что делать с sql бэкапами?

Размер самой большой базы какой?

(19) если более 5 подключений - то это не ларек и можно купить сервер 1с

по классике сперва надо загнать в tar, а потом gzip...

(12) Экспресс не умеет сжатые бэкапы

(16) почему не sql developer edition? Для разработки он также бесплатен, но не имеет ограничений как експресс

(0) может вам AOMEI Backupper подойдет ? я лично на Effector Saver - т.к он и в облако копию на ЯД шлет

(25) но там же сервер 1с все равно же тогда брать - а это 100 К

(27) ну вопрос не ко мне, я лишь предложил заменить редакцию скуля

(27) сервер 1с за сотку? Это ноут столько стоит. На сервер надо выделить 500-800 тыс

(29) Он говорит о приложении Сервер 1с.

Файловые, только dt. Обычные файловые копии могут и не открыться.

(31) Так и dt могут потом не загрузиться

(31) Ровно наоборот. Это dt может не загрузиться, а заархивированный cd - разархивировать и что ему будет? С чего бы это ему вдруг не открыться?
Разве что только если ты архивировал cd в момент активной работы в базе, а не выгнав всех пользователей. Ну или если архив битый, но тут уж любой архив - хоть dt архивируй, хоть cd.

А вот c dt - засада может быть. легко.

С Евгением Рошалем связался, он предложил решение. Не могу не поделиться.

Можно попробовать использовать solid сжатие с 4 GB словарем:
RAR a -s -md4g arc.rar file1 file2
Такой размер словаря доступен с версии RAR 7.00.

Результат поражает, архив стал весить в 38 раз меньше. (уточняю)

(34) Это реклама платного WINRAR?

Почему ты не воспользовался (13) ?
Где у бесплатного 7zip можно задать нужный размер словаря/слова/блока!

(34) чивооо??
(35) кста, у меня есть лицуха, надо будет проверить

(35) А в чем проблема? Размер словаря задается, правда максимум 1,5 гига

(37) Поставь 64 битный уже

(34) "Результат поражает, архив стал весить в 38 раз меньше"
Чем что?

(31) При этом сама 1С в ИТС говорит, что выгрузка в DT не является резервной копией

https://its.1c.ru/db/ut115doc/bookmark/Backup/Backup

(40) Выгрузка в DT не является полной резервной копией файловой базы, потому что теряется (не особо нужная) часть данных
И происходит трансформация формата хранения данных

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

(38) стоит 64-х битный, просто старый, 2015 года, версия 15.12.
Просто архивацией не балуюсь, смысла обновлять небыло

(34) Расстрелять...@ Иосиф В.

(41)>Выгрузка в DT не является полной резервной копией файловой базы gотому что теряется (не особо нужная) часть данных

Потому, что нет гарантий, что выгруженный dt ты сможешь загрузить обратно. Ты можешь делать нерабочие бекапы не зная об этом.

(31) +(41) Файловые - только НЕ dt. Сотрудник мой недавно приобрёл бесценный практический опыт: выгрузил базу клиента в dt. Затем загамачил базу. А из dt база не восстановилась.

(44)(45) делать нерабочие (которые не восстанавливаются) бэкапы можно любым методом
не только в DT

всегда надо проверять бэкапы на возможность восстановления ))

(41)
"Бэкап - в общем смысле это резервная копия, из которой можно полностью восстановить исходное состояние"

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

(46) Но есть нюанс (с)
Если вы запакуете повреждённую, но запускающуюся базу в zip (7z, rar, etc) , то распаковав zip вы получите ровно ту же базу. Из которой можно что-то выковырять.
Но если вы выгрузите повреждённую, но запускающуюся базу в dt, то есть шанс не получить из dt ничего.

(48) Это смотря как запакуете
Есть нюанс что в момент запаковки (-ssw) база будет открыта и изменена, есть шанс не получить из архива ничего

(49)+ выгрузка в DT в этом плане надежней, ибо монопольно выполняется

(49) для этого нужно делать копию 1cd (и не простым копированием а специализированым софтом, в поиск "моментальный снимок файла") и потом его архивировать

Как из большущего файла получить моментальный снимок - вообще непонятно как это работает... Что-то там с перехватом и перенаправлением ввода-вывода

(46)>всегда надо проверять бэкапы на возможность восстановления ))
Мне кажется ты немного путаешь теплое с мягким. Разумеется всегда следует проверять архивы. может быть место кончилось, да и что угодно может быть еще. Раз в месяц должна быть регламентная автооперация, которая поднимает базу из архива. Здесь нет вопросов. Вопрос в другом. Все проблемы при создании бекапа детектятся на стадии создании бекапа и в целом ты можешь понять, что у тебя проблемы в момент создания бекапа. В случае с выгрузкой в дт, понять, что, что-то пошло не по плану, ты можешь только когда разворачиваешь бекап. И даже тут можно как-то смириться и просто чаще проверять. Дело в том, что делать бекапы посредством dt просто не зачем. Тупо нет в этом никакого смысла. В случае с файловой: Нужно гарантия монопольного доступа? Наложи блокировку и выгони пользователей. Решать проблему с монопольным доступом тебе все равно придется для выгрузки в ДТ тоже. Или делай копию со снимка, как правильно пишут в (51). Если серверная то средствами СУБД решай этот вопрос. А дт, он немного для других случаев.

(53) Про копии со снимков это та же лотерея
Ибо вопрос что там снялось и в какой момент, может при реструктуризации базы или в момент записи связанных объектов

И да
Если не загружается DT - значит база изначально была битая и выгрузка в DT прошла криво

Это ничем не отличается от битого бэкапа файловой или sql

Неважно каким способом делаются бэкапы - важно проверить возможность его восстановления!

(52) Естественно, происходит подмена блоков. С момента объявления снапшота все изменяемые или добавляемые данные, которые пишутся в файл или в метаданные, на самом деле пишутся в другое место диска. При чтении снимка происходит обращение только к старым блокам (до момента снапшота), это дает возможность гарантировать, что файл во время копирования не изменится. А прочий софт, который работает с текущим состоянием диска, работает уже с новыми блоками файловой системы, не зная об этом.
При закрытии(удалении) снапшота происходит слияние, все измененные данные в новых блоках связываются с исходными записями файлов.
В винде это называется "теневое копирование". В серверных Windows можно создавать несколько снапшотов с возможностью обращения к любому из них. В клиентских функциональность ограничена лишь для целей снимков восстановления системы и бэкапов.

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

(56) Так то да. С этой точки зрения копирование во время снапшота практически аналогично копированию с выдернутого на лету диска. Немного лучше, потому что всё-таки операции записи NTFS при этом не рвутся и метаданные файловой системы не полетят. А вот относительно корректности данных на прикладном уровне ничего нельзя гарантировать.

Чтобы копия во время теневого копирования была адекватной приложение - та же 1с - должна уметь взаимодействовать со службой теневого копирования - так объясняли умные люди

(55) СПБ за пояснение

(59) В линуксе есть btrfs, так там снапшоты могут быть даже доступны на запись (если смонтировать с соответствующим флагом), и таким образом, любой снапшот идеологически эквивалентен корню файловой системы. То есть, можно взять и писать во вчерашнюю базу. А в винде - так, полумеры)

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

Файловая поднимает в память блоки файла,выполняет их изменение и потом делает запись на диск.
Кроме того,может идти выделение новых блоков с отражением в структуре файла ещё не записанных блоков.
Печальная операция - превращение одного блока в два,если что-то не влезло,так как могут быть потеряны данные.

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

(50) "выгрузка в DT в этом плане надежней, ибо монопольно выполняется"

to all - ой, вот только не надо тут про снапшоты.
Исходное условие - для dt нужен монопольный доступ. Никакая религия при этом условии не запрещает делать архив с помощью любого архиватора.

PS: Странные люди "апологеты dt". Значится, для dt они подразумевают исходное условие -  монопольный доступ.
А для простого архива тут же про монопольный забывают и  начинают возражать, даже про снапшоты вспоминают.
Нет уж, давайте исходное условие будет одинаковым - монопольный доступ что для dt, что для cd.
Нехорошо сравнивать при разных исходных условиях.

(64) На практике когда просишь "выгрузить в DT и прислать" - с большой вероятностью получишь рабочую копию базы
А вот выгрузку sql или копию .1cd не всегда получается рабочую получить и тем более развернуть

Риски нерабочего dt - очень редки
И скорее относятся когда требуется вмешательство спецов на низком уровне или сисадминов над исходной базой

Один раз начал выгружать базу в .dt . Сделалась за секунд 5 . Навожу на файлик выгрузки, а он весит 0 кб .

(66) тебе никогда ярлык на базу .1cd не присылали?

(65)

Речь шла про бекапы.


Зачем ты делаешь бекапы в момент реструктуризации?


см (48)

Это бывает достаточно дорого, проверять каждый бекап и на вопрос зачем надо делать именно так, ответа так и нет.

(68) скупой платит дважды

(67) А меня как-то попросили восстановить документы на флешке. Раньше открывались, а теперь что-то перестали. Оказалось, на флешке хранились ярлыки, а сами документы на рабочем столе и их просто рассортировали по папкам.
Ситуацию усложнял тот факт, что у юзера была "пионерская" винда с вырезанными значками ярлыков, то есть внешне ярлык и файл никак не отличались.

(69)Тупой трижды

(67) Нет. Просто какой-то сверх разум выключил-включил серв .
Хорошо ,что я заметил ,а то бы восстанавливал из бэкапа скуля .А он был 3ч давности ,и автоматический . И после этого бэкапа было ~300 документов.

(66)

Счастливое время. Базы, которые можно выгрузить в DT.

(70) Это не юзер - а юзверЬ !

(73) Я в секте " Свидетелей .dt@"

(64) "Исходное условие - для dt нужен монопольный доступ." - предположение не верное. Ключевое слово ibcmd. Для выгрузки dt-файла через него не требуется монопольный режим.

(76) Таки там фактически монопольный доступ аля снимок средствами 1С

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