# Зберігання даних ## Що це таке Зберігання даних, часто просто зберігання, — це шар системи, де дані перебувають між використаннями, на носіях, що переживають перезавантаження й знеструмлення. Глосарій NIST дає слову два значення, обидва взяті з SP 800-88r2: збереження даних, придатне для подальшого видобування, і апаратне забезпечення, на яке дані можна записати й з якого їх можна прочитати. Будь-яке зберігання спирається на фізичний носій: жорсткий диск із пластинами, твердотільний накопичувач, SD-картку, стрічковий картридж. Програми бачать над ним один із трьох шарів: - **Блочне зберігання** подає пристрій як ряд блоків фіксованого розміру, адресованих номерами. Розділ диска, масив RAID і віртуальний диск у хмарі виглядають для ядра саме так, а файлова система чи рушій бази даних вирішує, що означають блоки. - **Файлове зберігання** кладе на ці блоки файлову систему: імена, каталоги, розміри, власників і права доступу, а файл можна змінювати по кілька байтів. Через NFS чи SMB одне дерево каталогів обслуговує багато машин. - **Об'єктне зберігання** тримає цілі об'єкти, кожен — послідовність байтів плюс метадані, під іменем у контейнері, і до нього звертаються через HTTP API, а не через монтування. Google Cloud Storage зберігає дані як об'єкти в контейнерах, які називаються бакетами, кожен бакет належить до проєкту, а об'єкт — це незмінний фрагмент даних, що складається з файлу будь-якого формату. Три шари розходяться в тому, скільки коштує зміна. Блочний пристрій переписує один блок на місці. Файлова система редагує частину файлу й переносить його перейменуванням. Об'єктне сховище замінює об'єкт цілком: сторінка Google про об'єкти виключає дописування й обрізання, а заміна відбувається атомарно, тож читачі отримують стару версію, доки нове завантаження не завершиться. Перейменування стає копією під новим іменем і видаленням оригіналу. У бакеті з пласким простором імен папки — це картинка, яку інструменти малюють зі скісних рисок в іменах об'єктів; рядок `folder1/` є частиною імені, а окремої папки бакет не зберігає. Той самий файл у кожному з трьох шарів: ```sh # блок: ядро бачить диск як пронумеровані блоки lsblk /dev/sda # файл: файлова система над блоками, з іменами й каталогами df -h /srv # об'єкт: цілий об'єкт, надісланий у бакет через API gcloud storage cp readings.csv.gz gs://example-bucket/2024/01/ ``` ## Чому це важливо Носій визначає, як дані втрачаються. Жорсткий диск, SSD і SD-картка ламаються кожен по-своєму, і метод відновлення, що підходить одному, стає хибним інструментом для наступного. Надлишковість усередині одного корпусу, як-от дзеркальна пара дисків чи масив RAID, зберігає дані придатними для читання, коли помирає один диск, але записує кожне видалення на кожен диск так само сумлінно, як і самі дані. Довговічність і доступність — дві різні обіцянки. Довговічність — це шанс, що збережені дані вціліють; доступність — шанс, що їх вдасться прочитати в певну мить. Cloud Storage заявляє річну довговічність 99,999999999% для всіх класів зберігання, тоді як типова місячна доступність становить від 99,9% до понад 99,99% залежно від класу й розташування. Клас зберігання — це метадані кожного об'єкта, що задають його доступність і модель ціноутворення, а нові об'єкти успадковують клас бакета за замовчуванням. Холодніші класи міняють нижчу ціну зберігання на трохи нижчу доступність, мінімальний строк зберігання 30, 90 або 365 днів і плату за повторне читання даних; Google призначає їх для даних, які читають раз на місяць або рідше, щонайбільше раз на квартал і рідше ніж раз на рік. Розташування — частина даних. Копія на тому самому диску, тій самій машині чи в тому самому хмарному обліковому записі поділяє з ними долю, а копія деінде — ні. Розташування задає також швидкість і вартість: Google зазначає, що дані в тому самому регіоні, що й обчислення, які їх використовують, дають найкращу продуктивність для інтенсивної роботи з даними й можуть зменшити плату за мережу. Спосіб, у який програма дістається до сховища, визначає решту. Програма резервного копіювання restic описує свій репозиторій як просто каталог із набором підкаталогів і файлів, і той самий каталог може лежати на локальному диску, на сервері, до якого звертаються через SFTP, або в об'єктному сховищі на кшталт Google Cloud Storage чи Amazon S3. Дані лишаються тими самими, а затримка, способи відмови й людина, яка керує обліковим записом, змінюються. ## Як це виглядає на практиці На рівні фізичного носія [відновлення даних охоплювало практично всі поширені типи носіїв](/uk/portfolio/performed-data-recovery-across-a-wide-range-of-92/), від SD-карток і класичних HDD до SSD, масивів RAID, зовнішніх дисків і систем Mac. Люди приносили носії, які вийшли з ладу або були пошкоджені, а на них — фотографії, бізнес-файли, єдину копію чогось по-справжньому важливого. Кожен носій по-своєму ламається і по-своєму віддає дані: SSD — зовсім інша задача, ніж диск із пластинами, масив RAID — ще одна, а файлова система Mac має свої особливості. Знати правильний підхід до конкретного носія було не менш важливо, ніж володіти будь-якою окремою технікою, і клієнти отримували назад критично важливі дані з пристроїв, які вже подумки списали як втрачені. Шар об'єктного сховища видно в конвеєрах даних: у [шести ETL/ELT-пайплайнах, що постачали дані в Google BigQuery](/uk/portfolio/designed-implemented-and-administered-6-etl-elt-pipelines-8/), між джерелом і BigQuery стояв бакет Google Cloud Storage. Впорядковані набори даних і таблиці експортували в проміжні формати, стискали gzip і передавали в бакет, а звідти bq CLI і скрипти на Python завантажували їх у BigQuery. Цілі стиснуті файли заходили, цілі файли виходили — саме для такого шаблону й створено об'єктне зберігання. Копію, що лежить деінде, зробили так: [зашифровані резервні копії на restic ішли через SFTP у сховище іншого провайдера](/uk/portfolio/built-encrypted-backups-with-a-monthly-restore-drill-114/). До того все, що має компанія, працювало на одному хмарному інстансі, і вся можливість відновлення трималася на знімку від провайдера: знімку в тому самому обліковому записі, що й машина, яку він захищав, який ніхто в компанії не шифрував і з якого жодного разу не відновлювалися. Тепер таймер systemd запускає дамп бази даних, якщо вона є, зашифрований знімок із дедуплікацією до іншого провайдера, очищення за політикою зберігання й перевірку цілісності, а щомісячне тренування дістає з репозиторію відомий файл і звіряє його. Коли копія лежить в іншого провайдера, компанія може втратити хост і все одно повернути свої дані. ## Де виникають проблеми Більшість проблем зі зберіганням походить від копії, перевірки чи ціни, які здавалися надійними аж до дня, коли знадобилися. **Копія поділяє долю з оригіналом.** Знімок у тому самому обліковому записі, резервна копія на тому самому диску, репліка в тій самій будівлі: кожна переживає дрібні збої й гине разом із великим. Випишіть окремі події, що могли б знищити обидві копії, і переносьте одну, доки список не стане коротким. **Надлишковість вважають резервною копією.** Дзеркало копіює кожен запис на кожен диск, разом із видаленнями й пошкодженнями. Воно рятує від мертвого диска; окрема копія з власною історією рятує від помилки. **Об'єктним сховищем користуються як файловою системою.** Код, написаний для файлів, очікує дешевих перейменувань і переліків каталогів. У бакеті з пласким простором імен перейменування — це копія плюс видалення, а Google зазначає, що глибоко вкладені структури, схожі на каталоги, поступаються рідній файловій системі у швидкості переліку. Добирайте імена об'єктів під те, як їх читатимуть, а роботу, що редагує файли на місці, лишіть на файловому чи блочному зберіганні. **Перевірка читає індекс і пропускає дані.** За замовчуванням команда restic `check` перевіряє структуру репозиторію й лишає непрочитаними pack-файли з самими даними резервних копій, бо для цього довелося б завантажити кожен із них. `--read-data` читає їх усі, а підмножини від `--read-data-subset=1/5` до `5/5` охоплюють репозиторій за п'ять запусків. Перевірка, яка лише перелічує файли, доводить, що імена існують, і мало що каже про байти за ними. **Холодний клас тримає гарячі дані.** Файл, який щодня читають із класу, розрахованого на щомісячне читання, платить за кожне читання, тож добирайте клас під те, як дані насправді читають. ## Що почитати далі - [NIST glossary: storage](https://csrc.nist.gov/glossary/term/storage) — два значення слова так, як їх визначає NIST SP 800-88r2. - [Cloud Storage overview](https://cloud.google.com/storage/docs/introduction) — проєкти, бакети, об'єкти й папки та інструменти, що до них звертаються. - [About Cloud Storage objects](https://cloud.google.com/storage/docs/objects) — дані й метадані об'єктів, правила іменування, незмінність і пласкі простори імен за імітованими папками. - [Cloud Storage: Storage classes](https://cloud.google.com/storage/docs/storage-classes) — довговічність, доступність, мінімальні строки зберігання й плата за отримання для кожного класу. - [restic: Preparing a new repository](https://restic.readthedocs.io/en/stable/030_preparing_a_new_repo.html) — що таке репозиторій і локальні, SFTP та об'єктні бекенди, на яких він може лежати. - [restic: Working with repositories](https://restic.readthedocs.io/en/stable/045_working_with_repos.html) — перевірка структури репозиторію й зворотне читання даних, які він містить.