Единственный известный мне рабочий USB-IP софт - www.virtualhere.com Эта частичка Австралии - сердце и российских "импортозамещенных" аппаратных USB-IP хабов. Всё остальное... в том состоянии, как слог вашей статьи.
Это очень хорошо, спасибо, почитал. Требует pg_combinebackup, но уже лучше.
Давайте в двух словах расскажу принцип бекапа MS SQL, который реализован более 25 лет назад. Он очень похож на классический файловый, только вместо файлов страницы БД.
У страниц БД есть dirty bit. Full Backup по умолчанию сбрасывает это бит в 0 (как атрибут archive на файлах), а изменение страницы ставит бит в 1.
Full Backup - копирует все страницы независимо от значения бита dirty и сбрасывает его в 0.
Differential - копирует только страницы с битом dirty и не меняет бит.
Full Backup в режиме copy_only - копирует все страницы базы, но не сбрасывает бит. Это позволяет не нарушать основную цепочку Full/Diff при снятии дополнительных копий.
Работает просто, быстро, эффективно. Неужели за это нельзя проявить чуточку уважения к проприетарному продукту? )
Как вы верно говорите, это бекап кластера в сборе, и надо придерживаться схемы один инстанс - 1 база. Рядом стоит инстанс SQL Server, в котором около 1000 мелких баз (еще и с auto close), и он бекапится (и восстанавливается ручками) встроенным заданием, которое даже ротацию обеспечивает. Кто-то настроил 10 лет назад, так и работает.
А к bg_basebackup немного не хватает pg_baserestore, чтобы не возиться с каталогом данных.
Это не из коробки (не средствами postgresql), и это не бекап (а снепшот файловой системы). Всё равно что в винде сделать persistent vss snapshot и забрать оттуда файлы. База даже скорее всего будет консистентной, если отработает vss writer, но это всё же не бекап.
Бекап - когда вы пишете:
BACKUP DATABASE [MYDB] ....
А восстановление
RESTORE DATABASE [MYDB] FROM DISK=...
при это можете сделать первое восстановление, и продолжить из другого файла: RESTORE DATABASE [MYDB] FROM DISK= WITH NORECOVERY
Можете восстановить, перевести базу в Read Only и посмотреть внутри, всё ли вас устроило? RESTORE DATABASE [MYDB] WITH STANDBY = N'D:\MSSQL\DATA\MYDB_STANDBY01.tuf'
А если не устроило, догнать её вперед логом:
RESTORE LOG [MYDB] FROM DISK = N'D:\MYDB_2024210090041.trn' WITH FILE = 1, STANDBY = N'D:\MYDB_2016120816_7.tuf'
Поверьте, если не обсуждать цену, то с точки зрения администратора SQL Server - приятная и надежная в работе СУБД, простая в обслуживании, с хорошим инструментарием управления. Например генерация кода T-SQL в Management Studio - очень удобно.
Для примера простой сценарий. База данных 20Tb, прирост в месяц 1%, 200Gb. Задача - обеспечить восстановление базы хотя бы на конец каждого дня. В SQL Server такое задание сделает встроенный wizard за 1 минуту, и вы израсходуете на 7 недельных копий примерно 11Tb пространства.
Как уже написали, дамп базы - не совсем то. Дифференциальный бекап вы не сделаете, и логами до нужного момента не догоните. Бекап бинарный, с компрессией, внутри него не данные таблиц, а страницы базы данных. Плюс портабельность базы, здесь detach, там attach, и бекап не нужен.
Пожалуй, используемый prompt был бы интереснее готового проекта.
Да там оборот на обороте, вроде
curious detail, нюансы неточности обратного перевода нейросети
Эталонная снежинка наверняка хранится в палате мер и весов.
Чтобы не уметь пользоваться телефоном и запускать сову? Волшебники лора ГП не создали ни одной полезной вещи и живут в средневековье.
Мне кажется, что вывод напрашивается обратный. В большинстве тестов при равной стоимости выиграли P-ядра. И только для СУБД лучше - больше ядер.
две гистограммы по синтетике, где P-ядра выигрывают
многоугольник c E-ядрами, где они выигрывают в синтетике исключительно по СУБД. В nginx разница небольшая.
многоугольник c синтетикой и выигрышем single core в 1.5 раза на P-ядро, который вы назвали "незначительным"
Есть журнал событий System и Active Directory.
Без этого вашу статью можно отнести только к вредным советам. Не знаем что было, не знаем что именно помогло, не знаем что получилось.
Замечательно. Так в чем же была проблема - в log файлах, размерах базы ntds или её фрагментации?
Репликацию.
nonauthoritative . Делать так нежелательно - затрат больше, чем на переустановку.
Первая ссылка в Яндексе - достаточно трудно?
Приемлемы, но способ не нашёл. Плохо искал. Ещё интереснее, используют ли российские производители usb-ip именно этот способ лицензирования.
Единственный известный мне рабочий USB-IP софт - www.virtualhere.com Эта частичка Австралии - сердце и российских "импортозамещенных" аппаратных USB-IP хабов. Всё остальное... в том состоянии, как слог вашей статьи.
Спасибо, интересно, нужно попробовать. Похвалитесь, пожалуйста, каких фич нет Ms SQL?
Совесть есть у вас?
Это очень хорошо, спасибо, почитал. Требует pg_combinebackup, но уже лучше.
Давайте в двух словах расскажу принцип бекапа MS SQL, который реализован более 25 лет назад. Он очень похож на классический файловый, только вместо файлов страницы БД.
У страниц БД есть dirty bit. Full Backup по умолчанию сбрасывает это бит в 0 (как атрибут archive на файлах), а изменение страницы ставит бит в 1.
Full Backup - копирует все страницы независимо от значения бита dirty и сбрасывает его в 0.
Differential - копирует только страницы с битом dirty и не меняет бит.
Full Backup в режиме copy_only - копирует все страницы базы, но не сбрасывает бит. Это позволяет не нарушать основную цепочку Full/Diff при снятии дополнительных копий.
Работает просто, быстро, эффективно. Неужели за это нельзя проявить чуточку уважения к проприетарному продукту? )
Еще 26Mbps, и получится догнать субфлагман Xiaomi 15t pro на бюджетном Mediatek?
Как вы верно говорите, это бекап кластера в сборе, и надо придерживаться схемы один инстанс - 1 база. Рядом стоит инстанс SQL Server, в котором около 1000 мелких баз (еще и с auto close), и он бекапится (и восстанавливается ручками) встроенным заданием, которое даже ротацию обеспечивает. Кто-то настроил 10 лет назад, так и работает.
А к bg_basebackup немного не хватает pg_baserestore, чтобы не возиться с каталогом данных.
Это не из коробки (не средствами postgresql), и это не бекап (а снепшот файловой системы). Всё равно что в винде сделать persistent vss snapshot и забрать оттуда файлы. База даже скорее всего будет консистентной, если отработает vss writer, но это всё же не бекап.
Бекап - когда вы пишете:
BACKUP DATABASE [MYDB] ....
А восстановление
RESTORE DATABASE [MYDB] FROM DISK=...
при это можете сделать первое восстановление, и продолжить из другого файла:
RESTORE DATABASE [MYDB] FROM DISK= WITH NORECOVERY
Можете восстановить, перевести базу в Read Only и посмотреть внутри, всё ли вас устроило?
RESTORE DATABASE [MYDB] WITH STANDBY = N'D:\MSSQL\DATA\MYDB_STANDBY01.tuf'
А если не устроило, догнать её вперед логом:
RESTORE LOG [MYDB] FROM DISK = N'D:\MYDB_2024210090041.trn' WITH FILE = 1, STANDBY = N'D:\MYDB_2016120816_7.tuf'
Поверьте, если не обсуждать цену, то с точки зрения администратора SQL Server - приятная и надежная в работе СУБД, простая в обслуживании, с хорошим инструментарием управления. Например генерация кода T-SQL в Management Studio - очень удобно.
Для примера простой сценарий. База данных 20Tb, прирост в месяц 1%, 200Gb. Задача - обеспечить восстановление базы хотя бы на конец каждого дня. В SQL Server такое задание сделает встроенный wizard за 1 минуту, и вы израсходуете на 7 недельных копий примерно 11Tb пространства.
Как сделать backup базы данных postgresql из коробки?
Как уже написали, дамп базы - не совсем то. Дифференциальный бекап вы не сделаете, и логами до нужного момента не догоните. Бекап бинарный, с компрессией, внутри него не данные таблиц, а страницы базы данных. Плюс портабельность базы, здесь detach, там attach, и бекап не нужен.
Он хотя бы бекапится из коробки четырьмя разными способами, а потом из них даже восстанавливается.
Чувствую себя неважно всю неделю, зато часы всегда со 100% зарядом!