Reeve Backups
Branching у Supabase це не бекап. Він іде тільки вперед.
Чому branching у Supabase це не бекап: гілка стартує без ваших даних, а мердж переносить саму лише схему. Для чого він потрібен і що брати замість нього.
Коротко
- Branching у Supabase це не бекап. Гілка це друга база даних для перевірки змін, і вона стартує без жодного вашого продакшн-рядка.
- Мердж застосовує ваші зміни схеми до продакшену. Він ніколи не переносить рядки, і немає жодної операції, яка повертає давніший стан ваших даних.
- Навіть гілка, у яку ви склонували свої дані, живе в тому самому обліковому записі, а preview-гілка видаляється, щойно закривається її pull request.
Ви ввімкнули branching у Supabase, бо це виглядало як акуратний спосіб працювати. Поруч із вашим проєктом тепер стоїть preview-гілка, зміни пробують там, перш ніж їх хтось побачить, і вся конструкція відчувається значно надійнішою, ніж місяць тому.
Вона й справді надійніша. Просто це не бекап, і різниця виявляється рівно одного дня.
Ось частина, яку посібники з branching оминають: гілка це друга база даних поруч із вашою першою, а не її давніша версія. Branching це місце, куди ви йдете перед тим, як щось змінити. Бекап це місце, куди ви йдете, коли щось уже пішло не так. Увімкнення branching не кладе копію ваших даних нікуди.
Чи є branching у Supabase бекапом?
Ні. Гілка стартує як порожня база даних, вбрана у вашу схему, і ніщо в branching не повертає давніший стан ваших даних.
Власна документація Supabase каже це прямо: «Нові гілки стартують без жодних даних із вашого головного проєкту. Це зроблено, щоб краще захистити ваші чутливі продакшн-дані». Гілка збирається з ваших міграцій, а міграція описує форму бази даних. Таблиці, стовпці, політики. Ніколи рядки.
Тож гілка, що стоїть поруч із вашим проєктом, це не копія з вівторка. Це нова база даних, яка ніколи не бачила ваших користувачів.
| Гілка Supabase | Бекап | |
|---|---|---|
| Тримає ваші рядки з давнішого моменту | Лише якщо ви їх туди склонували | Так, у цьому вся його робота |
| Може повернути продакшен, як було | Ніколи | Так |
| Живе поза вашим обліковим записом | Ні, це ще один проєкт усередині нього | Залежить від того, який із трьох шляхів ви обрали |
| Буде на місці наступного місяця | Лише якщо ви зробили її персистентною | Стільки, скільки ви його зберігаєте |
| Для чого воно | Перевірити зміну, перш ніж вона когось дістане | Повернутися до того, як щось когось дістало |
Якщо ви ніколи не з'ясовували, що насправді копіює вашу базу, то саме до цього завдання стаття вас і відправляє, а ваш план вирішує більшу частину питання за дві хвилини.
Чим гілка є насправді
Цілим другим проєктом Supabase, з усім своїм власним.
«Кожна гілка це окреме середовище з власним екземпляром Supabase і власними обліковими даними API», так це формулює документація. Власний рядок підключення, власні ключі, власний Storage, власні облікові записи входу, власні рядки. Ніщо всередині не під'єднане до проєкту, на якому сидять ваші користувачі, і саме це робить безпечним ламати там речі.
Ця ізоляція це вся функція, і вона ж є причиною, чому гілка не може заодно бути бекапом. Копію ваших даних, на яку ви сподівалися, ніколи не знімали, а місце, де ви пішли б її шукати, порожнє з дня свого створення.
Що робить мердж, і чого він не робить
Він переносить ваші зміни схеми в продакшен. Він ніколи не переносить рядки, у жодному напрямку, у жодну мить.
Коли ви мерджите, Supabase застосовує міграції вашої гілки до вашої продакшн-бази й публікує зміни ваших Edge Functions. Це весь вантаж. Нова таблиця, новий стовпець, переписана політика: вони їдуть. Рядки, які ви створили під час перевірок, лишаються в гілці, а рядки в продакшені лишаються рівно такими, якими були, включно з тими, які ви сподівалися замінити.
Люди чекають на версію цього, якої не існує: на мердж, що сягає в продакшен і кладе речі назад. Замість цього в branching є деплой, застосований уперед, поверх того, що саме зараз стоїть у продакшені.
Але я склонував свої продакшн-дані в гілку
Тоді у вас є копія ваших рядків, і три речі про цю копію вирішують, чого вона варта того дня, коли вам знадобиться.
Так робити можна, і це не щось маловідоме. CLI Supabase описує опцію як клонування продакшн-даних у базу гілки, а management API приймає ту саму опцію при створенні гілки. Якщо ви нею скористалися, ваша гілка справді тримає ваші дані.
- Її зняли один раз. Клон стається під час створення гілки, і після цього ніщо його не поповнює. Кожне замовлення, кожна реєстрація і кожен коментар відтоді живуть у продакшені й більше ніде, і в цьому вся різниця між копією та розкладом.
- Вона всередині того самого облікового запису. Гілка це ще один проєкт під тією самою організацією, на тій самій картці, за тим самим входом. Будь-який спосіб втратити обліковий запис Supabase забирає гілку разом із ним, а це інше лихо, ніж зіпсувати власні дані.
- Ніхто її не перечитував. Клон, що зупинився на півдорозі, ззовні виглядає так само, як той, що дійшов до кінця, аж до миті, коли ви його відкриваєте.
Гілка це та частина, яку задумано зникати
Preview-гілку видаляють, коли її pull request змерджено або закрито. Це задокументована поведінка цієї можливості.
Supabase називає preview-гілки «ефемерними й найкраще придатними для точкових перевірок» і каже, що вони «видаляються автоматично, коли PR змерджено або закрито». Інший тип, персистентні гілки, це «довговічні гілки, рекомендовані для середовищ на кшталт staging, QA чи розробки», і вони переживають закриття pull request.
Тож за замовчуванням гілка, що тримає вашу єдину склоновану копію, це саме те, що ваш робочий процес викидає того дня, коли робота завершується. Лишити її означає зробити її персистентною, а персистентна гілка це другий увімкнений проєкт Supabase. Supabase пропонує branching на платних планах і рахує його погодинно за кожну гілку, на їхній сторінці цін.
Для чого branching справді добрий
Для дуже багато чого, і ця стаття була б нечесною, якби цього не сказала.
Гілка це найдешевше місце, де можна з'ясувати, що міграція прибирає стовпець, до того, як вона прибере той стовпець, у якому сидять ваші клієнти. Вона дає відрепетирувати зміну політики на базі, зробленій точно як ваша, з власними ключами, так що помилка нікого не дістане. Вона дає штучному інтелекту місце, де можна помилятися і яке не є вашим живим застосунком. Бекап не вміє нічого з цього.
Прогалина в тому, який саме тип нещастя вона покриває. Branching захищає зміни, що йдуть через pull request. Більшість того, що насправді коштує людям їхніх даних, повз нього ніколи не проходить: видалення в редакторі таблиць Supabase, яке зачепило більше рядків, ніж малося на увазі, seed-скрипт, наведений на живий проєкт, міграція, яку написав штучний інтелект і яку ви схвалили о першій ночі, прибирання того, що виглядало тестовими даними. Жодне з цього не проходить крізь гілку дорогою до продакшену, і це та сама причина, з якої відкат коду не повертає видалену таблицю.
Саме на цей другий тип нещастя відповідає бекап. Він стоїть позаду вас у часі й тримає стан вашої бази на момент, який ви можете назвати, щоб помилка, зроблена поза вашим робочим процесом, усе ще мала куди повернутися.
Це також те, чим є Reeve Care: заплановані копії вашої бази даних Supabase, які зберігаються поза вашим обліковим записом Supabase, перечитуються й перевіряються перед тим, як будь-яка з них зарахується як зроблена. Під'єднайте свої Storage-бакети, і файли, які завантажили ваші користувачі, поїдуть разом, тож відновлення поверне рядки й зображення, на які ці рядки вказують.
Тримайте branching увімкненим у будь-якому разі. Ніщо вище не є аргументом його вимикати.
Що зробити цього тижня
Що робити
- З'ясуйте, що копіює вашу базу даних за розкладом, окремо від усього, що робить із неї гілки. Якщо на це йде більше хвилини, відповідь така, що не копіює ніщо.
- Якщо ви ставилися до склонованої гілки як до страхувальної сітки, запишіть дату її створення й дату, коли закривається її pull request. Це два кінці того, що вона покриває.
- Увімкніть бекап, який містить ваш план Supabase. Це найдешевше в цьому списку, і воно покриває звичайне нещастя, тобто те, що ви зіпсували власні дані.
- Тримайте одну копію поза обліковим записом Supabase, бо гілка й бекап платформи обидва стоять за тим самим входом, що й річ, яку вони захищають.
- Відновіть одну копію в тимчасовий проєкт, щоб уперше прочитати той файл не того дня, коли він вам потрібен.
Перш ніж закрити цю вкладку, відкрийте свій проєкт Supabase і подивіться, чи знімає щось копію за розкладом. Ця одна відповідь це вся сьогоднішня робота, і branching не змінює її в жоден бік. 10-хвилинний чекліст безпеки покриває її разом з рештою того, що варто підтвердити у щойно запущеному застосунку, а що містить копія й що насправді робить кнопка відновлення, розписано на сторінці бекапів Supabase.
Поширені запитання
Чи є branching у Supabase бекапом?
Ні. Гілка це окрема база даних Supabase, зібрана з ваших міграцій, і Supabase документує, що нові гілки стартують без жодних даних із вашого головного проєкту. Branching дає вам місце, де перевірити зміну до того, як вона дійде до продакшену. Бекап дає вам копію ваших даних на момент, який ви можете назвати, щоб до нього повернутися. Це дві різні роботи, і увімкнути першу не означає зробити щось для другої.
Чи є в preview-гілці Supabase мої продакшн-дані?
За замовчуванням ні. Supabase каже, що нові гілки стартують без жодних даних із головного проєкту, і називає причиною захист ваших продакшн-даних. Ви можете попросити клон під час створення гілки, і CLI описує цю опцію як клонування продакшн-даних у базу гілки. Якщо ви цього не просили, у вашій гілці є ваші таблиці й жодного вашого рядка.
Чи можу я відновити продакшн-базу з гілки?
У branching немає відновлення. Мердж застосовує міграції гілки до вашої продакшн-бази й публікує зміни ваших Edge Functions; ніщо на цьому шляху не переносить рядки й ніщо не відкочує нічого назад. Якщо ви склонували продакшн-дані в гілку, ви могли б зняти з тієї бази дамп і програти його самі, але тоді вас захищає дамп, а не гілка.
Що стається з гілкою, коли я мерджу pull request?
Preview-гілку видаляють. Supabase описує preview-гілки як ефемерні й каже, що вони видаляються автоматично, коли pull request змерджено або закрито. Персистентні гілки це інший тип, призначений для staging чи QA, і вони не зникають після закриття pull request. Тож якщо гілка тримає єдину копію чогось важливого для вас, налаштування за замовчуванням викидає її того дня, коли робота завершується.
Чи коштує branching окремо?
Так. Supabase пропонує branching на платних планах і рахує його погодинно за кожну гілку, понад вашу підписку. Читайте поточний тариф на їхній сторінці цін, а не тут, бо він їхній і вони можуть його змінити. Практично це означає: персистентна гілка, яку лишили ввімкненою, це другий проєкт Supabase, за який ви платите щогодини його існування.