На днях случились две занимательные истории про бекапы.
Послушайте!
Ведь, если ЦОДы зажигают —
значит — это кому-нибудь нужно?
В Южной Корее сгорел ЦОД - G-Drive Fire Destroys 125,000 Officials' Data. Бекапов не было.
Все бы ничего, но это было официальное корейское государственное облако.
Согласно официальной части «просто загорелись литиевые батареи при переносе».
Неофициально злые языки говорят, что облако давно взломали или северные корейцы, или китайцы, и слили оттуда все, что было интересного, поэтому
Все было ясно. Дом был обречен. Он не мог не сгореть. И, действительно, в двенадцать часов ночи он запылал, подожженный сразу с шести концов.
Объемы данных заявлены как 858 терабайт. Бекапы, а что бекапы, ну не смогли:
The actual number of users is about 17% of all central government officials. According to the Ministry of the Interior and Safety, as of last August, 125,000 public officials from 74 ministries are using it. The stored data amounts to 858TB (terabytes), equivalent to 449.5 billion A4 sheets.
Вся эта история, конечно, вранье.
Система хранения данных 5 летней давности (из 2020 года), даже среднего сегмента, то есть обычная, серийная, продаваемая в розницу – это 36 SSD дисков формата PALM, размещаемые в систему хранения высотой 2 юнита, включенных через NVME.
Например, Huawei dorado 5000 v6 с дисками Huawei 15.36TB SSD NVMe Palm Disk Unit(7")
Или, система из того же ценового диапазона, 8 летней давности (из 2017 года) - HPE Nimble Storage All Flash Array AF60 или AF80, с заявленной емкостью системы хранения от 1.8 до 3.7 петабайт, с SSD дисками комплектом в 24 штуки - HPE Nimble Storage AF40/60/80 All Flash Array 184TB (24x7.68TB) FIO Flash Bundle.
Диски 2.5 и по 7.68TB Тб, так что потребуется больше дисков, больше места, и больше денег. Старая система, ничего не поделать.
В 2025 году петабайт, да еще с учетом сжатия и дедупликации, это даже не половина стойки.
Все современные системы хранения данных, кроме уж совсем SOHO (small office - home office):
и продаваемые как системы хранения данных,
и продаваемые как программно-определяемые системы хранения данных,
и продаваемые как гиперконвергентые среды (Storage space direct, vSAN) для гиперскейлеров и частных облаков,
Все они:
Во первых имеют в составе функционал репликации на «другой удаленный ЦОД» - то есть функционал метрокластера, синхронный или асинхронный. Это не бекап, это только репликация, но она спасет от пожара, потопа, и так далее (лицензируется отдельно).
Во вторых, так или иначе, интегрируются с системами резервного копирования, в том числе с офлайн хранением – с классическими ленточными библиотеками (LTO) или их эмуляцией, Virtual Tape Library (тот же QUADstor).
Что-то там еще пытаются рассказать, что такие объемы записать на кассеты нельзя .. ну что ж. Посчитаем.
Кассета Quantum LTO-9 – это 18 терабайт не сжатых данных.
10 кассет – 180 терабайт. 100 кассет – 1800 терабайт, 2.5 раза выполнить полный бекап этих 850 Тб
Расширяемая ленточная библиотека HPE Storage MSL3040 Tape Library идет с комплектом на 40 слотов, расширяется до 640 слотов.
Сам привод для дисков (стример), например HPE Storage LTO Ultrium Tape Drives, точнее HPE StoreEver MSL LTO-9 Ultrium 45000 Fibre Channel Drive Upgrade Kit (R6Q74A) какой-то странный, я что-то не пойму, почему везде пишут, что он не FC, а SAS 12G.
Но, какая разница. Для библиотеки (HPE StoreEver MSL 3040 Tape Library) заявлена скорость:
Maximum Data Transfer (Native) 22.5 TB/hr (21 LTO-9 drives)
Maximum Data Transfer (Native) 51.4 TB/hr (48 LTO-9 drives)
Источник: QuickSpecs, официальный сайт HPE.
То есть для «обычных» 4 приводов скорость составит около 4 терабайт \ час, 98-100 Тб\сутки. 850 заявленных терабайт можно было записать за 8-10 дней на 4 дисках, или, для записи «за сутки» потребовалось бы 35 приводов из максимум 48.
Деление полученного бекапа на несколько потоков для записи, Aux copy with Maximum streams для Commvault (не путать с Multiplexing, он не для этого) – функционал не очевидный, и возможно что-то надо покрутить – подпилить, но решаемый.
Так что, было бы желание, а коммерческие решения есть на рынке очень давно. Но, желания не было.
Летом 2025 года Газпромбанк торжественно отчитался, цитата:
Москва, 18 июня 2025 года – Газпромбанк успешно завершил один из самых масштабных ИТ-проектов последних лет — переход на полностью импортозамещённую автоматизированную банковскую систему (АБС) ЦФТ, в основе которой лежит программно-аппаратный комплекс Скала^р (продукт Группы Rubytech) для построения доверенной ИТ-инфраструктуры финансового сектора на базе технологии Postgres Pro Enterprise.
Официальный сайт Газпромбанка, статья Газпромбанк завершил переход на импортозамещённую автоматизированную банковскую систему
Перешел и перешел, молодцы. Но попалась мне на глаза реклама ООО «Постгрес Профессиональный», под видом статьи Как Газпромбанк перешел на российскую СУБД. Поскольку это реклама под видом «колонки» (то, что реклама написано внизу, серыми буквами), то дата не проставлена.
Понравилась мне оттуда цитата:
Приведу пример с резервным копированием и восстановлением данных. Высокая скорость этих процессов была для нас одним из ключевых требований, потому что при наступлении фатальной ошибки критически важно быстро восстановиться из резервной копии. Postgres Pro Enterprise делает это за два часа, иностранные решения, которые мы тестировали, — за 14.
Возникает вопрос, как так это у них получается.
Если (по неизвестным причинам) использовать не средства резервного копирования (которые все равно используют RMAN), а сам RMAN, то он, если я правильно прочитал, позволяет выполнять параллельное восстановление, цитата:
As long as there are many backup pieces into a backup set, RMAN will use an appropriate number of channels - if allocated - to restore the database.
Ex:
7 backup pieces and 6 channels allocated - RMAN will use the whole 6 channels in parallel
6 backup pieces and 6 channels allocated - RMAN will use the whole 6 channels in parallel
5 backup pieces and 6 channels allocated - RMAN will use only 5 channels - one will be IDLE
rman restore datafile : how to force parallelism ?
Если говорить про Microsoft SQL, то там есть SMB multichannel, и давным давно есть Accelerated database recovery, ADR и Multi-Threaded Version Cleanup (MTVC)
Accelerated Database Recovery enhancements in SQL Server 2022
У Postgre тоже есть параллельное исполнение:
By using multiple concurrent jobs, you can reduce the time it takes to restore a large database on a multi-vCore target server. The number of jobs can be equal to or less than the number of vCPUs that are allocated for the target server.
Best practices for pg_dump and pg_restore for Azure Database for PostgreSQL
Но не в 7 же раз разница.
Не знаю, как после первой истории не вспомнить загадку про трех черепах:
Три черепахи ползут по дороге. Одна черепаха говорит: “Впереди меня две черепахи”. Другая черепаха говорит: “Позади меня две черепахи”. Третья черепаха говорит: “Впереди меня две черепахи и позади меня две черепахи”. Как такое может быть?
Вторая история просто интересная.
Как говорил один мой знакомый, покойник: я слишком много знал.
