WAL-G, например, умеет бекапить MS SQL. Причём умеет бекапить его не только в Azure, но и в S3 и в GCP.
Если говорить про WAL-G для PG, то, например, в этом релизе MS SQL объявили о дифференциальных бекапах на Standby. WAL-G это делал в 2017 для Постгреса.
Или, например, у нас есть prefault. Когда Standby сильно отстаёт от Primary и нужно его догнать WAL-G умеет прогревать страницы данных, к которым скоро будет обращение в логе изменений. Но это скорее свистелка.
У нас есть мониторинг целостности данных в облачном сторейдже: можем пошуршать по файликам и не скачивая всё проверить несколько инвариантов.
Из полезного: мы поддерживаем вообще любые облака, много кодеков сжатия, много режимов снятия дельт, много правил хранения и у нас простая настройка. И ещё мы не только принимаем Pull Request, но и назначаем коммиттеров из сообщества. Попробуйте реализовать свою хотелку в MS SQL :)
А ещё WAL-G единообразно работает для PG, GP, Cloudberry, MongoDB, Redis, Valkey, FoundationDB, MS SQL и чего-то там ещё.
Печально. Ну, Волга бесплатная (во всяком случае я не знаю где бы её можно было купить). Если где-то будут интересные фичи которые можно притащить в WAL-G - сообщайте, притащим :)
Для Postgres правильно пользоваться WAL-G, PgProbackup или pgBackrest. Первые два, кстати, написаны во многом в России. Как разработчик WAL-G хочу сказать, что у MS SQL нет большинства наших фич. Ну и, конечно, мы умеем разворачивать только одну базу из бекапа.
На Advanced Patch Feedback Session Питер Е и Томаш предложили сделать хуки, чтобы экстеншен мог отменить. Но все облака уже эксплуатируют эту штуку запатченной у себя.
Моё мнение - любой форк строго хуже ваниллы. Причём это касается даже мастера ванилы, который хуже релиза. А свежий релиз хуже прошлогоднего. Настоящий Постгрес начинатеся где-то с версии х.3 или х.4.
Ребята и из ПгПро, и из Тантора выкладывают патчи и чинят баги в ванилле - это замечательно. Сравнивать их коммерческие продукты не берусь (и даже не буду делать выводов из толпы PgPro в 40 человек в pgsql-hackers, хотя это хочется отметить! Тантор есть в хакерсах, это тоже замечательно, ждём остальных)
вы забыли одно маленькое условие - в этот момент никто другой с базой работать не должен от слова совсем. Не самый частый случай для продовой базы с секретной инфой.
Во-первых, уязвимость остаётся уязвимостью, даже если для эксплуотации требуется тишина. Во-вторных, не требуется, изменения пройдут в несколько сотен байт WAL, которые часто окажутся подряд даже в очень нагруженной системе. Но это всё не важно, я не хочу публично развивать идеи эксплуотации CRIME.
Да блин, ну это смешно. Если у меня есть pg_select_all_data, то я уже суперадмин. Зачем мне подбирать хэш, если я имею право его тупо прочитать?
Нет, это не так, pg_select_all_data не может читать pg_authid. Но цель, конечно, выйти из базы и атаковать соседние системы.
цена канала между серверами, отнюдь не нулевая
Это так с точки зрения применения в конкретной системе.
А с точки зрения массового продукта, сообществе Postgres не хочет чтобы настройки по-умолчанию приводили к известной уязвимости. Кроме этого, у security team есть определение уязвимости, под которое CRIME попадает, если сжатие ключено сервером из коробки.
А вы рассказываете про появившихся откуда-то неизвестных атакующих с pg_select_all_data. Это театр, а не инженерия.
Доступ к мониторингу может быть получен другим способом. Типичные взломы проводятся с комбинацеий уязвимостей, кроме того приправляются социальной инженерии. В моём примере CRIME используется для выхода из СУБД на машину, но цели и условия могут быть иные. Я не ломаю вашу базу, я только демонстрирую, что уязвимые к таком вектору атаки системы существуют.
ну а как?
Если вы администрируете базу данных - просто обновляйте софт вовремя. Основной вектор атаки в большинстве случаев - эксплуотация известных уязвимостей, если против вас используют zero day - вы бы не писали эти вопросы. Если вы разрабатываете приложение - временами просматривайте OWASP всем коллективом разработчиков - уже это сделает вашу систему намного более сложной целью в куче других атакуемых систем. Если вы разрабатываете базу данных... фиг знает, стоит изучать все существующие уязвимости. Могу порекомендовать мои работы: тренажер github.com/x4m/pg_cve_demo/ и статью https://xakep.ru/2021/12/03/postgresql-cve-history/
Начнём с того, что я не преувеличиваю, а констатирую наблюдаемые свойства атаки, указывая на все ограничения. В рассылке я, точно также как и вы, был сторонником включения сжатия, но настройкой суперпользователя. И сообществе в итоге пришло именно к такому консесусу по этому вопросу.
Во-вторых, все уязвимости обладают свойством "розовых соплей", но тем не менее эксплуатируются. Я очень надеюсь, что в своих системах вы более творчески и критически подходите к безопасности сервисов. Именно такое отношение "да тут взломать сложно" и приводит к большому количеству инъекций в коде. "Сложность" эксплуатации уязвимости зачастую номинальная.
Из приведённых вами примеров. Доступ на прослушку? Подходите творчески, достаточно доступа к мониторингу, например роли pg_select_all_data, чтобы увидеть представление со статистикой по сети. Ровно один писатель в БД в период времени длинной в сотни микросекунд. Это редкость? Нет. Секретные данные вместе с несекретными? Ну, допустим, у пользователя есть право менять свой пароль. Хэш его пароля лежит на одной страничке с md5 админа. Full page image уехавший по сети раскрывает пароль админа. Наконец, про энтропию - вам не нужно угадывать весь хэш за один раз, вы можете сделать тысячу смен паролей и подобрать хэш постепенно, по одному байту. В pgsql hackers можно найти эксплойт, который за 400 смен паролей атакующего вытаскивает хэш суперюзера, с которым потом можно зайти в базу. Любую, без особой специальной подготовки, просто включить сжатие и получить доступ к мониторингам базы!
Пожалуйста, не относитесь к безопасности своих систем вот так. Все уязвимости эксплуатируют творчески и с желанием приложить много усилий.
Работают ли они full time над ванилой или full time над ответвлением постгрес в рамках коммерческой компании где они трудоустроены? Это все же разные постгрес и разные процессы.
Нет, когда я говорю Постгрес - я имею ввиду ванильный Постгрес, а не что-то типа Постгреса. Абсолютное большинство коммиттеров и контрибьюторов full time работают над Постгресом. А не чем-то типа.
И да, коммерческие компании готовы отдать в ваниллу что угодно. Но оно не того качества, которое требует ванила.
Если у нападающего есть возможность писать в базу данных и сделать так, чтобы его изменения сжимались вместе с какими-нибудь секретными данным - по длинне передаваемых данных он может понять насколько его данные похожи на секрет. Тут лучше поподробнее почитать CRIME, это очень инетерсная штука. Из-за неё сжатие удалили из TLS, сжатие существенно ослабляет криптографию.
Вот тут есть определённое искажение восприятия, которое я часто встречаю. Абсолютное большинство коммиттеров и контрибьюторов full time работают над Постгресом. И уровень разработки открытого кода на голову выше любой коммерческой разработки.
Да, процесс разработки сложился до того, как появился git. Тем более Github. Но сам процесс редко является проблемой. А вот когнитивная сложность системы, высокая связность движущихся частей - является причиной проблем. Linux модульный и там есть коммиттеры в разные части. Коммиттер Postgres внося изменения отвечает за всю систему + совместимость с расширениями, драйверами, экосистемой из тулзов.
Причина не коммитить что-то может быть смешной, но если она есть - найти коммиттера будет сложно. Их внимание довольно диффицитно, даже если его разделить на патчи вообще без недостатков.
Мы в Ржакенхилле (офис команды разработки в Екатеринбурге) играем в игру "назови 10 причин не коммитить это". В простой версии для commitfest item. В сложной - для commit log.
Роберт говорит "we tend to make a committer anyone who understands what actually can be committed". Думаю, это гипербола, но всё же что-то в этом есть.
Тормозить развитие в довольной развитой системе - не очевидно неправильное решение. В качестве аналогии можно подумать о раковых опухолях - они тоже являются быстрым клеточным ростом.
В случае с Постгресом всё, конечно, не так однозначно, нам надо двигаться вперёд. Но осторожно, стараясь ничего не сломать.
То что UUIDv7 не вошёл в PostgreSQL 17 из-за того, что feature freeze случился за две недели до принятия RFC 9562 - это, по моему мнению, конечно плохо. Надо было коммитить год назад, мой код был готов.
Но в общем случае - в операционной базе данных стабильность превыше всего.
Облака не очень любят специализированное железо: один и тот же гипервизор должен подходить для всех задач. Исключения встречаются: GPU для нейросетей и гейминга, атомные часы для Spanner. Но вот даже с этими часами подход не стал мейнстримом: алгоритмы видимости строк, основанные на времени, либо стараются сделать устойчивыми к отклонению часов (Clock-SI), либо делают из привычных компонент часы получше чем обычно (Amazon Time Sync Service).
Моя точка зрения — базы данных и так уже сильно повлияли на commodity-железо, компьютеры уже сделаны для баз данных и дальнейшая специализация не предвидится. Но не все со мной согласны! Если хотите вдохновится на более железячные базы данных — рекомендую доклад с SIGMOD 2019 про "Dark silicon — a currency we do not control" https://plds.github.io/slides/KTHTalk-pirk.pdf
Далеко не все базы помещаются в ОЗУ, та же Почта, про базу которой мы много говорили — более петабайта. И паттерн нагрузки такой, что не рационально хранить всё в ОЗУ.
Но даже если и не брать в расчёт очень большие данные, есть что оптимизировать и в террабайтных данных, и в гигабайтных.
Стоит обсудить идеи по оптимизации в листе рассылки pgsql-hackers, насмотренность сообщества поможет определить на сколько эта оптимизация актуальна. Если же речь не об оптимизации ядра СУБД, то такие вопрос лучше всего обсудить на каком-нибудь митапе про управление данными.
Одно можно сказать уверенно: в управлении данными ещё очень много инженерных задач. Да, компьютеры быстрые, они быстрые давно, и новые горизонты производительности позволяют создавать новые неожиданные системы, создание которых раньше было бы слишком дорогим.
WAL-G, например, умеет бекапить MS SQL. Причём умеет бекапить его не только в Azure, но и в S3 и в GCP.
Если говорить про WAL-G для PG, то, например, в этом релизе MS SQL объявили о дифференциальных бекапах на Standby. WAL-G это делал в 2017 для Постгреса.
Из того, чего, кажется, нет у MS SQL. WAL-G умеет догнать реплику бекапом. Backup for catchup и catchup-send. Подробнее рассказано в моём докладе на PGConf EU: https://www.postgresql.eu/events/pgconfeu2024/sessions/session/5792-hidden-gems-of-wal-g-backup-tool/
Или, например, у нас есть prefault. Когда Standby сильно отстаёт от Primary и нужно его догнать WAL-G умеет прогревать страницы данных, к которым скоро будет обращение в логе изменений. Но это скорее свистелка.
У нас есть мониторинг целостности данных в облачном сторейдже: можем пошуршать по файликам и не скачивая всё проверить несколько инвариантов.
Из полезного: мы поддерживаем вообще любые облака, много кодеков сжатия, много режимов снятия дельт, много правил хранения и у нас простая настройка. И ещё мы не только принимаем Pull Request, но и назначаем коммиттеров из сообщества. Попробуйте реализовать свою хотелку в MS SQL :)
А ещё WAL-G единообразно работает для PG, GP, Cloudberry, MongoDB, Redis, Valkey, FoundationDB, MS SQL и чего-то там ещё.
Печально. Ну, Волга бесплатная (во всяком случае я не знаю где бы её можно было купить). Если где-то будут интересные фичи которые можно притащить в WAL-G - сообщайте, притащим :)
Для Postgres правильно пользоваться WAL-G, PgProbackup или pgBackrest. Первые два, кстати, написаны во многом в России. Как разработчик WAL-G хочу сказать, что у MS SQL нет большинства наших фич. Ну и, конечно, мы умеем разворачивать только одну базу из бекапа.
Да, облака, конечно, подстроятся, не проблема. Просто после того как это решение было предложено в мае - руки не дошли...
На Advanced Patch Feedback Session Питер Е и Томаш предложили сделать хуки, чтобы экстеншен мог отменить. Но все облака уже эксплуатируют эту штуку запатченной у себя.
Моё мнение - любой форк строго хуже ваниллы. Причём это касается даже мастера ванилы, который хуже релиза. А свежий релиз хуже прошлогоднего. Настоящий Постгрес начинатеся где-то с версии х.3 или х.4.
Ребята и из ПгПро, и из Тантора выкладывают патчи и чинят баги в ванилле - это замечательно. Сравнивать их коммерческие продукты не берусь (и даже не буду делать выводов из толпы PgPro в 40 человек в pgsql-hackers, хотя это хочется отметить! Тантор есть в хакерсах, это тоже замечательно, ждём остальных)
Во-первых, уязвимость остаётся уязвимостью, даже если для эксплуотации требуется тишина. Во-вторных, не требуется, изменения пройдут в несколько сотен байт WAL, которые часто окажутся подряд даже в очень нагруженной системе. Но это всё не важно, я не хочу публично развивать идеи эксплуотации CRIME.
Нет, это не так, pg_select_all_data не может читать pg_authid. Но цель, конечно, выйти из базы и атаковать соседние системы.
Это так с точки зрения применения в конкретной системе.
А с точки зрения массового продукта, сообществе Postgres не хочет чтобы настройки по-умолчанию приводили к известной уязвимости. Кроме этого, у security team есть определение уязвимости, под которое CRIME попадает, если сжатие ключено сервером из коробки.
Доступ к мониторингу может быть получен другим способом. Типичные взломы проводятся с комбинацеий уязвимостей, кроме того приправляются социальной инженерии. В моём примере CRIME используется для выхода из СУБД на машину, но цели и условия могут быть иные. Я не ломаю вашу базу, я только демонстрирую, что уязвимые к таком вектору атаки системы существуют.
Если вы администрируете базу данных - просто обновляйте софт вовремя. Основной вектор атаки в большинстве случаев - эксплуотация известных уязвимостей, если против вас используют zero day - вы бы не писали эти вопросы. Если вы разрабатываете приложение - временами просматривайте OWASP всем коллективом разработчиков - уже это сделает вашу систему намного более сложной целью в куче других атакуемых систем. Если вы разрабатываете базу данных... фиг знает, стоит изучать все существующие уязвимости. Могу порекомендовать мои работы: тренажер github.com/x4m/pg_cve_demo/ и статью https://xakep.ru/2021/12/03/postgresql-cve-history/
Начнём с того, что я не преувеличиваю, а констатирую наблюдаемые свойства атаки, указывая на все ограничения. В рассылке я, точно также как и вы, был сторонником включения сжатия, но настройкой суперпользователя. И сообществе в итоге пришло именно к такому консесусу по этому вопросу.
Во-вторых, все уязвимости обладают свойством "розовых соплей", но тем не менее эксплуатируются. Я очень надеюсь, что в своих системах вы более творчески и критически подходите к безопасности сервисов. Именно такое отношение "да тут взломать сложно" и приводит к большому количеству инъекций в коде. "Сложность" эксплуатации уязвимости зачастую номинальная.
Из приведённых вами примеров. Доступ на прослушку? Подходите творчески, достаточно доступа к мониторингу, например роли pg_select_all_data, чтобы увидеть представление со статистикой по сети. Ровно один писатель в БД в период времени длинной в сотни микросекунд. Это редкость? Нет. Секретные данные вместе с несекретными? Ну, допустим, у пользователя есть право менять свой пароль. Хэш его пароля лежит на одной страничке с md5 админа. Full page image уехавший по сети раскрывает пароль админа. Наконец, про энтропию - вам не нужно угадывать весь хэш за один раз, вы можете сделать тысячу смен паролей и подобрать хэш постепенно, по одному байту. В pgsql hackers можно найти эксплойт, который за 400 смен паролей атакующего вытаскивает хэш суперюзера, с которым потом можно зайти в базу. Любую, без особой специальной подготовки, просто включить сжатие и получить доступ к мониторингам базы!
Пожалуйста, не относитесь к безопасности своих систем вот так. Все уязвимости эксплуатируют творчески и с желанием приложить много усилий.
Нет, когда я говорю Постгрес - я имею ввиду ванильный Постгрес, а не что-то типа Постгреса. Абсолютное большинство коммиттеров и контрибьюторов full time работают над Постгресом. А не чем-то типа.
И да, коммерческие компании готовы отдать в ваниллу что угодно. Но оно не того качества, которое требует ванила.
Если у нападающего есть возможность писать в базу данных и сделать так, чтобы его изменения сжимались вместе с какими-нибудь секретными данным - по длинне передаваемых данных он может понять насколько его данные похожи на секрет. Тут лучше поподробнее почитать CRIME, это очень инетерсная штука. Из-за неё сжатие удалили из TLS, сжатие существенно ослабляет криптографию.
Вот тут есть определённое искажение восприятия, которое я часто встречаю. Абсолютное большинство коммиттеров и контрибьюторов full time работают над Постгресом. И уровень разработки открытого кода на голову выше любой коммерческой разработки.
Да, процесс разработки сложился до того, как появился git. Тем более Github. Но сам процесс редко является проблемой. А вот когнитивная сложность системы, высокая связность движущихся частей - является причиной проблем. Linux модульный и там есть коммиттеры в разные части. Коммиттер Postgres внося изменения отвечает за всю систему + совместимость с расширениями, драйверами, экосистемой из тулзов.
Причина не коммитить что-то может быть смешной, но если она есть - найти коммиттера будет сложно. Их внимание довольно диффицитно, даже если его разделить на патчи вообще без недостатков.
Мы в Ржакенхилле (офис команды разработки в Екатеринбурге) играем в игру "назови 10 причин не коммитить это". В простой версии для commitfest item. В сложной - для commit log.
Роберт говорит "we tend to make a committer anyone who understands what actually can be committed". Думаю, это гипербола, но всё же что-то в этом есть.
Я очень раз что новый UUID полезен :)
Тормозить развитие в довольной развитой системе - не очевидно неправильное решение. В качестве аналогии можно подумать о раковых опухолях - они тоже являются быстрым клеточным ростом.
В случае с Постгресом всё, конечно, не так однозначно, нам надо двигаться вперёд. Но осторожно, стараясь ничего не сломать.
То что UUIDv7 не вошёл в PostgreSQL 17 из-за того, что feature freeze случился за две недели до принятия RFC 9562 - это, по моему мнению, конечно плохо. Надо было коммитить год назад, мой код был готов.
Но в общем случае - в операционной базе данных стабильность превыше всего.
Облака не очень любят специализированное железо: один и тот же гипервизор должен подходить для всех задач. Исключения встречаются: GPU для нейросетей и гейминга, атомные часы для Spanner. Но вот даже с этими часами подход не стал мейнстримом: алгоритмы видимости строк, основанные на времени, либо стараются сделать устойчивыми к отклонению часов (Clock-SI), либо делают из привычных компонент часы получше чем обычно (Amazon Time Sync Service).
Моя точка зрения — базы данных и так уже сильно повлияли на commodity-железо, компьютеры уже сделаны для баз данных и дальнейшая специализация не предвидится. Но не все со мной согласны! Если хотите вдохновится на более железячные базы данных — рекомендую доклад с SIGMOD 2019 про "Dark silicon — a currency we do not control" https://plds.github.io/slides/KTHTalk-pirk.pdf
Далеко не все базы помещаются в ОЗУ, та же Почта, про базу которой мы много говорили — более петабайта. И паттерн нагрузки такой, что не рационально хранить всё в ОЗУ.
Но даже если и не брать в расчёт очень большие данные, есть что оптимизировать и в террабайтных данных, и в гигабайтных.
Стоит обсудить идеи по оптимизации в листе рассылки pgsql-hackers, насмотренность сообщества поможет определить на сколько эта оптимизация актуальна. Если же речь не об оптимизации ядра СУБД, то такие вопрос лучше всего обсудить на каком-нибудь митапе про управление данными.
Одно можно сказать уверенно: в управлении данными ещё очень много инженерных задач. Да, компьютеры быстрые, они быстрые давно, и новые горизонты производительности позволяют создавать новые неожиданные системы, создание которых раньше было бы слишком дорогим.