Немного не по теме....
А как вообще готовить nbackup -decompress ? Команда в виде строки передаётся? Такое подозрение что она вообще игнорится
PS: FB 3.0.5.33179, Win10

hvlad,
Ну раз nbackup -? в винде показывает -de в наличии - ожидал что оно таки работает.

hvlad,
А какие сейчас вообще перспективы появления nbackup -decompress под виндой?

hvlad,
Не то чтобы без этого совсем жить нельзя, но как говориться, шанцевый инструмент заточкой не испортишь.
На счёт сомнений в скорости... тут вот какой момент - если между диском с БДой и местом где должен лежать бекап находится сетка, то чем он (бекап) по размеру меньше, тем процесс быстрее. Подобные прыжки в ширину со сжатием обычно начинаются из-за конечности локальных ресурсов на сервере БД, когда например держать локально инкременталку 0-го уровня уже нет возможности.
За всех не скажу, но лично в моём случае использование сжатия вывода nbackup-а сокращает время процесса примерно в 2.5 - 3 раза (nbackup -B ... stdout|zstd -3 -o %BackUpFile%)
И всё бы хорошо, но теперь проблема в том что в случае аларма придётся разархивировать бекап перед восстановлением БД. А это, мало того, что время на промежуточное копирование (что в таких случаях ресурс очень ценный), так и собственно пресловутое дополнительное место на дисках требуется.

hvlad,
Почему нет, для себя - то?

hvlad,
Понял, завтра погоняю в реальном окружении и отпишусь.

hvlad,
Чего-то не взлетает. Никакой реакции на ключ -DE . Работает точно так же как и предыдущая версия, распаковщик (ни zstd, ни 7z) не вызывается.

hvlad,
Заменил. Версия 3.0.5.33190(x64) от сегодня на 14:23
Не висит, копирует файл из \\STORAGE\Backups\db.level0.nbk.zstd в D:\DB\test.fdb потом выдает ошибку что это не файл снапшота (не записал точный текст)
Ком.строка:
nbackup -DE "zstd -dc --no-progress" -R D:\DB\test.fdb \\STORAGE\Backups\db.level0.nbk.zstd
zstd в папке фаербёрда (установлен снапшот Firebird-3.0.5.33190-0_x64)

hvlad,
Последний, по крайней мере завёлся. О результатах позже.

Итак, отвечу сразу на два вопроса:
1. Работает ли это? - О да!!! Прекрасно работает :)
2. Был ли в этом смысл?

Тестировал только для zstd, так как 7z тут совсем не в кассу.
Использованные БД:
Размер БД Размер архива Коэффициент сжатия (Ka) 64.1 GB 17.4 GB 3.683908045977011405.0 GB 168.0 GB 2.410714285714286

Время восстановления nbackup из снапшота 0-го уровня
Ta - из сжатого
Twa - из несжатого

Сценарии
1. SSD-SSD (с быстрого диска на быстрый диск на локальном хосте)
Twa ~= Ta
2. HDD-SSD (с небыстрого диска на быстрый диск на локальном хосте)
Twa ~= 0.7*Ka*Ta
3. SSD-LAN-SSD (с быстрого диска на быстрый диск через локальную сеть)
Twa ~= 1.1*Ta
4. SSD-WAN-SSD (с быстрого диска на быстрый диск через высоколатентную сеть(канал с филиалом))
Twa ~= Ka*Ta
PS: Удивил результат 2-го сценария. При коэффициентах сжатия от ~1.45 и выше даже тут zstd уже имеет смысл.
PPS: Все результаты получены путём поверхностной проверки в реальном окружении и полноценным тестом не являются. Короче Disclaimer.
Имхо, с учётом кучи освобождённого места при хранении и как минимум неотставания распаковки от прямого копирования во всех сценариях - смысл в использования сжатия очевиден.

hvlad,
Вообще не вопрос. Тебе спасибо, что было что тестировать.
PS: С удовольствием бы протестировал такую же фичу и для gbak -c(-b) -se, когда stdin(stdout) недоступен и сжать(распаковать) динамически не возможно. Ну это так, мечтательно :)