mayton2019

Я просоединяюсь к совету выше. На тему того что самое эффективное уплотение информции
можно сделать на уровне разработки приложения.

Я-бы предложил не сжимать всю базу а проанализировать, какие таблицы и какие поля занимают
80% всего пространства. (Процены я взял с головы по принципу Паретто. Вы можете взять любой
процент. Можно 90 или 70 не суть важно. Важно чтобы не закапыватья м мелочах.)

Из опыта других БД. (Не MS-SQL). Часто бывало что потребителем места были BLOB-поля где
лежали какие-то несуразные и никому не нужные документы. Аттачменты. Картинки. Копии
email из переписок с пользователем и многое другое. Были ситуации когда причиной роста
БД были старые архивные записи в таблице которые почему-то были забыты. Они должны
были удаляться но из за бага не удалялись.

Хорошая практика в данном случае - убрать из БД все длинные текстовые документы
или положить их в gzip на уровне самого приложения например. Обычно такие поля
не участвуют напрямую в операциях OLTP и их сжатие ни на что особо не влияет.

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

По поводу ROW level/block level сжатия. Я не специалист в MS_SQL, но обычно это надо
предварительно тестировать под нагрузкой на PROD для всех DBMS в общем то.
Велика вероятность падения производительности а это, сами понимаете слишком
большая цена за экономию. И диски в наше время значительно дешевле скажем чем 10 лет назад.

Современные аналитики обычно не работают с БД напрямую. Особенно с той БД, где ходят клиенты
и активно работают короткие транзакции (OLTP).

В крупных конторах наподобие банков и торговых сетей обычно для аналитиков отгружаются
все-все исторические данные, что проходили в БД. В денормализованном виде. Обычно
такие себе широкие таблицы по 100 - 500 колонок. И эти таблицы сливаются во всякие
аналитические системы (Databricks) в формате column-oriented tables (Delta-table). И аналитики
работают с этими данными на языках SQL/Python/R e.t.c. Строют всякие графики, краcивые
картинки и агрегации.

ОИБ здесь конечно при делах и не при делах. Рациональное зерно такого разделения
состоит в том что с БД транзакций снимается ненужная I/O нагрузка и БД работает легче
и аналитики не натворят бед с denial of service.

Не знаю как щас. А лет 10 назад базы обслуживал DBA. Это был инженер и хозяйственник. Кроме того что он знал бизнес. Он также знал примерный объем таблиц в гигабайтах и в миллионах строк. Не обязательно все а хотя-бы топ 10. И даже если какая-то из них внезапно опухла - то это было-бы лакмусом того что в системе что-то пошло не так. (Я в бытность DBA-администраторства знал примерно сколько в день растут таблицы бизнес-фактов и сколько архивных логов накатывает Oracle). Обычно схема даже очень сложных систем состоит из справочников которые не растут. И из таблиц бизнес-операций которые и нужно держать под наблюдением. И их не очень много.

Вот тут пишут как посмотреть размер таблиц https://stackoverflow.com/questions/21738408/postg...

Количество строк - сами напишете. Ну и мониторинг и еще раз мониторинг. Возможно причины - банальны. Переход на новую версию комплекса в процессе которого были добавлены новые колонки например.

И внезапный рост бизнес-данных - это не вопрос к qna. Это вопрос ко всем отвественным которые платят за железо и софт и сам программный продукт 1С.

Странно всё это

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

верни лучше взад.

Что еще менялось кроме железа. Версия PG?

Такие задачи я делал просто в текстовых редакторах. Надо только найти тот который загрузит файл на 1.4Гб.
Попробуй Notepad++. Потом визуально можно просто отметить номера строк для резки. И уже порезать консольными утилитами типа head/tail

Если вообще не осилил - тогда качай докер. Потом mySQL https://hub.docker.com/_/mysql Ну и дальше погнал. Загружай.

Скорее всего не будет работать. NAS может обеспечить throughput, но не IOPs.

Это одна причина. И вторая - протокольная. Если Mysql все таки запрашивает какую-то операцию которая характерна только только для локального диска (fsync) то что будет если мигнет сеть ? Это фатально для базы. Я не знаю как она среагирует, но это равносильно выдергиванию SATA диска из шлейфа.

Был в десятке разных компаний. У всех - по разному.
Бэкап это по большей части организационный вопрос. Главное что в этом топике вам никто правильно не ответит.

Нужно спрашивать ваш бизнес о требованиях к базе. Например:

1) Как долго бизнес согласен ждать восстановления? Это влияет например на стратегию делания инкрементальных кумулятивных и полных бэкапов для БД. Разумеется все БД - в режиме arhivelog/wal.
2) От чего мы страхуемся? От физических повреждений. Или еще нужно предохранится от неверно поставленного обновления на базу. Тут - надо прикупить дополнительных дисков или магнитных накопителей.

Самое главное что у вас должны быть учебные тревоги. Тоесть вы должны реально откатать бэкап+восстановление хотя-бы несколько раз. Иначе то что вы делаете будет фейком. Часто видел такое. Бэкап делает какой-то сисадмин средствами Акрониса например. Но этот сисадмин и понятия не имеет как работает Oracle и что вообще нужно предварительно подготовить чтоб бэкапные файлы не стали ненужным балластом.

Если носитель информации - ненадежный - то к нему добавляют дополнительные коды типа Хэмминга которые восстанавливают поврежденные биты после сбоя. На 99% нормальных носителей это реализовано аппаратно. Если твоя флешка сбоит или не очень надежна то желательно купить новую. Если ты всё таки хочешь наковырять золота в навозе - посмотри в сторону утилиты par2 manpages.org/par2 она на десяток процентов увеличит размер твоих бэкапов но будет гарантировать фиксацию нескольких бит если такое будет. Она работает поверх обычной файловой системы и ее коды контроля будут просто дополнительными файлами рядышком.

А проверить восстановистя ли бэкап в принципе - невозможно. Как в той философской мысли - нельзя узнать какой пудинг пока ты его не съел. Поэтому и гарантировать целосность бэкапа на логическом уровне можно только проведя симуляцию его полного восстановления в БД.