1. Если кончится место на диске то том ISM будет помечен как "full" а девайс как read-only. Придется отключать этот том и подсоединять к пулу новый.

2. Место внутри тома можно освобождать с помощью определения политики retention и утилиты onsmsync , см. Backup and Restore Guide p.8-11 Expiring Old backups

3. Как? не давать пользователям обновлять данные? :)

4. Если *nix то используйте символические ссылки для имен устройств

5. Долгое время эксплуатировали ISM на сильно загруженном сервере с OLTP (иногда DSS), ISM работал без нареканий. Для лучшей производительности устройства ISM надо держать на отдельных от устройств Информикса дисках.

Хм, интересно, я считал что ISM будеть удалять устаревшие save set'ы. Возможно чтобы удаление произошло, надо сделать нек. доп. действия?

Как вариант, можно использовать схему удаления устаревших архивов, путем создания группы клонированных томов: перед очередным level-0 клонируете текущие тома в клоны (предварительно клоны очищаются с помощью ism_op -label), после чего запускаете level-0. Фишка здесь в том, что level-0 и бэкап журналов попадает только в обычные тома, в клоны он не идет. Т.о. всегда имеете в наличии текущий level-0 + журналы в нормальных томах и предыдущий в клонах.

В других SM ситуация несколько иная. Например при использовании Tivoli Storage Manager onsmsync помечает истекшие бэкапы, после чего сам TSM их удаляет (периодически в TSM запускается процесс который шерстит тома на предмет поиска устаревших бэкапов)

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

Еще можете использовать схему с перенаправлением бэкапов по read_only: 4 устройства, 2 для текущего level-0 и журналов, 2 для предыдущего помеченных как read_only. Перед следующим level-0 текущие девайсы помечаете как read_only (размонтируете их, делаете read_only ism_op -mount $DEVICEDATA -read_only, снова монтируете), предыдущие очищаете и разрешаете в них запись (размонтировать, сделать ism_op -label $DEVICEDATA -force, снова смонтировать для записи).
Эта схема менее затратна по времени, поскольку не тратится время на клонирование данных. Такую схему до сих пор использую.

Последовательность действий для очистки томов под новый бэкап такая:

размонтировать ism_op -unmount $DEVICE
разметить заново ism_op -label $DEVICE -force
смонтировать ism_op -mount $DEVICE

46 Gb архивов это немало, тем более если диски медленные. Можете конечно попробовать делать через пересоздание тома и девайса ISM. Или делать бэкап и переключение между томами чаще, тогда и данных в ISM будет накапливаться меньше.

А кстати, насколько много транзакций идет в вашей системе, что накапливается такой объем данных в ISM ? Или может быть просто на сервере много данных?
Рекомендую прописать в скрипт $INFORMIXDIR/bin/onbar строку
export ISM_COMPRESSION=TRUE, это позволит сжимать данные перед записью в ISM.