[{"data":1,"prerenderedAt":338},["ShallowReactive",2],{"blog-uk-supabase-branching-is-not-a-backup":3},{"id":4,"title":5,"body":6,"category":297,"cover":298,"coverAlt":299,"description":300,"draft":301,"extension":302,"faq":303,"image":318,"keywords":319,"meta":326,"navigation":327,"ogTitle":328,"path":329,"published":330,"seo":331,"stem":332,"tldr":333,"updated":330,"__hash__":337},"blog_uk\u002Fblog\u002Fsupabase-branching-is-not-a-backup.md","Branching у Supabase це не бекап. Він іде тільки вперед.",{"type":7,"value":8,"toc":285},"minimark",[9,13,16,24,29,32,35,38,122,131,135,138,141,144,148,151,154,160,163,167,170,173,199,203,206,209,214,223,227,230,233,240,243,246,249,253,273],[10,11,12],"p",{},"Ви ввімкнули branching у Supabase, бо це виглядало як акуратний спосіб\nпрацювати. Поруч із вашим проєктом тепер стоїть preview-гілка, зміни пробують\nтам, перш ніж їх хтось побачить, і вся конструкція відчувається значно\nнадійнішою, ніж місяць тому.",[10,14,15],{},"Вона й справді надійніша. Просто це не бекап, і різниця виявляється рівно\nодного дня.",[10,17,18,19,23],{},"Ось частина, яку посібники з branching оминають: ",[20,21,22],"strong",{},"гілка це друга база даних\nпоруч із вашою першою, а не її давніша версія."," Branching це місце, куди ви\nйдете перед тим, як щось змінити. Бекап це місце, куди ви йдете, коли щось уже\nпішло не так. Увімкнення branching не кладе копію ваших даних нікуди.",[25,26,28],"h2",{"id":27},"чи-є-branching-у-supabase-бекапом","Чи є branching у Supabase бекапом?",[10,30,31],{},"Ні. Гілка стартує як порожня база даних, вбрана у вашу схему, і ніщо в\nbranching не повертає давніший стан ваших даних.",[10,33,34],{},"Власна документація Supabase каже це прямо: «Нові гілки стартують без жодних\nданих із вашого головного проєкту. Це зроблено, щоб краще захистити ваші\nчутливі продакшн-дані». Гілка збирається з ваших міграцій, а міграція описує\nформу бази даних. Таблиці, стовпці, політики. Ніколи рядки.",[10,36,37],{},"Тож гілка, що стоїть поруч із вашим проєктом, це не копія з вівторка. Це нова\nбаза даних, яка ніколи не бачила ваших користувачів.",[39,40,41,56],"table",{},[42,43,44],"thead",{},[45,46,47,50,53],"tr",{},[48,49],"th",{},[48,51,52],{},"Гілка Supabase",[48,54,55],{},"Бекап",[57,58,59,71,89,100,111],"tbody",{},[45,60,61,65,68],{},[62,63,64],"td",{},"Тримає ваші рядки з давнішого моменту",[62,66,67],{},"Лише якщо ви їх туди склонували",[62,69,70],{},"Так, у цьому вся його робота",[45,72,73,76,83],{},[62,74,75],{},"Може повернути продакшен, як було",[62,77,78],{},[79,80,82],"key-verdict",{"type":81},"danger","Ніколи",[62,84,85],{},[79,86,88],{"type":87},"safe","Так",[45,90,91,94,97],{},[62,92,93],{},"Живе поза вашим обліковим записом",[62,95,96],{},"Ні, це ще один проєкт усередині нього",[62,98,99],{},"Залежить від того, який із трьох шляхів ви обрали",[45,101,102,105,108],{},[62,103,104],{},"Буде на місці наступного місяця",[62,106,107],{},"Лише якщо ви зробили її персистентною",[62,109,110],{},"Стільки, скільки ви його зберігаєте",[45,112,113,116,119],{},[62,114,115],{},"Для чого воно",[62,117,118],{},"Перевірити зміну, перш ніж вона когось дістане",[62,120,121],{},"Повернутися до того, як щось когось дістало",[10,123,124,125,130],{},"Якщо ви ніколи не з'ясовували, що насправді копіює вашу базу, то саме до цього\nзавдання стаття вас і відправляє, а\n",[126,127,129],"a",{"href":128},"\u002Fblog\u002Fdoes-supabase-back-up-my-database","ваш план вирішує більшу частину питання за дві хвилини",".",[25,132,134],{"id":133},"чим-гілка-є-насправді","Чим гілка є насправді",[10,136,137],{},"Цілим другим проєктом Supabase, з усім своїм власним.",[10,139,140],{},"«Кожна гілка це окреме середовище з власним екземпляром Supabase і власними\nобліковими даними API», так це формулює документація. Власний рядок підключення,\nвласні ключі, власний Storage, власні облікові записи входу, власні рядки. Ніщо\nвсередині не під'єднане до проєкту, на якому сидять ваші користувачі, і саме це\nробить безпечним ламати там речі.",[10,142,143],{},"Ця ізоляція це вся функція, і вона ж є причиною, чому гілка не може заодно бути\nбекапом. Копію ваших даних, на яку ви сподівалися, ніколи не знімали, а місце,\nде ви пішли б її шукати, порожнє з дня свого створення.",[25,145,147],{"id":146},"що-робить-мердж-і-чого-він-не-робить","Що робить мердж, і чого він не робить",[10,149,150],{},"Він переносить ваші зміни схеми в продакшен. Він ніколи не переносить рядки, у\nжодному напрямку, у жодну мить.",[10,152,153],{},"Коли ви мерджите, Supabase застосовує міграції вашої гілки до вашої\nпродакшн-бази й публікує зміни ваших Edge Functions. Це весь вантаж. Нова\nтаблиця, новий стовпець, переписана політика: вони їдуть. Рядки, які ви створили\nпід час перевірок, лишаються в гілці, а рядки в продакшені лишаються рівно\nтакими, якими були, включно з тими, які ви сподівалися замінити.",[155,156],"diagram",{"alt":157,"caption":158,"src":159},"Три смуги входять крізь ворота на шляху до продакшн-бази даних. Сітка комірок таблиці проходить і має галочку. Блок коду проходить і має галочку. Стос рядків даних зупиняється біля воріт і має хрестик.","Мердж публікує форму вашої бази й код навколо неї. Рядки це єдине, що він ніколи не був створений переносити.","\u002Fblog\u002Fsupabase-branching-is-not-a-backup\u002Fwhat-a-merge-carries-1600x640.png",[10,161,162],{},"Люди чекають на версію цього, якої не існує: на мердж, що сягає в продакшен і\nкладе речі назад. Замість цього в branching є деплой, застосований уперед, поверх\nтого, що саме зараз стоїть у продакшені.",[25,164,166],{"id":165},"але-я-склонував-свої-продакшн-дані-в-гілку","Але я склонував свої продакшн-дані в гілку",[10,168,169],{},"Тоді у вас є копія ваших рядків, і три речі про цю копію вирішують, чого вона\nварта того дня, коли вам знадобиться.",[10,171,172],{},"Так робити можна, і це не щось маловідоме. CLI Supabase описує опцію як\nклонування продакшн-даних у базу гілки, а management API приймає ту саму опцію\nпри створенні гілки. Якщо ви нею скористалися, ваша гілка справді тримає ваші\nдані.",[174,175,176,183,193],"ul",{},[177,178,179,182],"li",{},[20,180,181],{},"Її зняли один раз."," Клон стається під час створення гілки, і після цього\nніщо його не поповнює. Кожне замовлення, кожна реєстрація і кожен коментар\nвідтоді живуть у продакшені й більше ніде, і в цьому вся різниця між копією та\nрозкладом.",[177,184,185,188,189,130],{},[20,186,187],{},"Вона всередині того самого облікового запису."," Гілка це ще один проєкт під\nтією самою організацією, на тій самій картці, за тим самим входом. Будь-який\nспосіб втратити обліковий запис Supabase забирає гілку разом із ним, а\n",[126,190,192],{"href":191},"\u002Fblog\u002Fthree-ways-to-back-up-a-supabase-database","це інше лихо, ніж зіпсувати власні дані",[177,194,195,198],{},[20,196,197],{},"Ніхто її не перечитував."," Клон, що зупинився на півдорозі, ззовні виглядає\nтак само, як той, що дійшов до кінця, аж до миті, коли ви його відкриваєте.",[25,200,202],{"id":201},"гілка-це-та-частина-яку-задумано-зникати","Гілка це та частина, яку задумано зникати",[10,204,205],{},"Preview-гілку видаляють, коли її pull request змерджено або закрито. Це\nзадокументована поведінка цієї можливості.",[10,207,208],{},"Supabase називає preview-гілки «ефемерними й найкраще придатними для точкових\nперевірок» і каже, що вони «видаляються автоматично, коли PR змерджено або\nзакрито». Інший тип, персистентні гілки, це «довговічні гілки, рекомендовані для\nсередовищ на кшталт staging, QA чи розробки», і вони переживають закриття pull\nrequest.",[155,210],{"alt":211,"caption":212,"src":213},"Дві часові лінії йдуть зліва направо, і кожна закінчується розривом лінії. На верхній збережені файли стоять у трьох давніших точках, а стрілка повертається від розриву до найближчого з них, із галочкою. На нижній друга лінія відгалужується й біжить поруч, несучи порожню базу даних, а стрілка назад від розриву не дістає нічого, із хрестиком.","Бекап стоїть позаду вас на часовій лінії, у момент, який ви можете назвати. Гілка біжить поруч із вами, і позаду неї немає нічого, за що взятися.","\u002Fblog\u002Fsupabase-branching-is-not-a-backup\u002Fbehind-you-beside-you-1600x680.png",[10,215,216,217,130],{},"Тож за замовчуванням гілка, що тримає вашу єдину склоновану копію, це саме те,\nщо ваш робочий процес викидає того дня, коли робота завершується. Лишити її\nозначає зробити її персистентною, а персистентна гілка це другий увімкнений\nпроєкт Supabase. Supabase пропонує branching на платних планах і рахує його\nпогодинно за кожну гілку, на\n",[126,218,222],{"href":219,"rel":220},"https:\u002F\u002Fsupabase.com\u002Fpricing",[221],"nofollow","їхній сторінці цін",[25,224,226],{"id":225},"для-чого-branching-справді-добрий","Для чого branching справді добрий",[10,228,229],{},"Для дуже багато чого, і ця стаття була б нечесною, якби цього не сказала.",[10,231,232],{},"Гілка це найдешевше місце, де можна з'ясувати, що міграція прибирає стовпець, до\nтого, як вона прибере той стовпець, у якому сидять ваші клієнти. Вона дає\nвідрепетирувати зміну політики на базі, зробленій точно як ваша, з власними\nключами, так що помилка нікого не дістане. Вона дає штучному інтелекту місце, де\nможна помилятися і яке не є вашим живим застосунком. Бекап не вміє нічого з\nцього.",[10,234,235,236,130],{},"Прогалина в тому, який саме тип нещастя вона покриває. Branching захищає зміни,\nщо йдуть через pull request. Більшість того, що насправді коштує людям їхніх\nданих, повз нього ніколи не проходить: видалення в редакторі таблиць Supabase,\nяке зачепило більше рядків, ніж малося на увазі, seed-скрипт, наведений на живий\nпроєкт, міграція, яку написав штучний інтелект і яку ви схвалили о першій ночі,\nприбирання того, що виглядало тестовими даними. Жодне з цього не проходить крізь\nгілку дорогою до продакшену, і це та сама причина, з якої\n",[126,237,239],{"href":238},"\u002Fblog\u002Fversion-history-is-not-a-backup","відкат коду не повертає видалену таблицю",[10,241,242],{},"Саме на цей другий тип нещастя відповідає бекап. Він стоїть позаду вас у часі й\nтримає стан вашої бази на момент, який ви можете назвати, щоб помилка, зроблена\nпоза вашим робочим процесом, усе ще мала куди повернутися.",[10,244,245],{},"Це також те, чим є Reeve Care: заплановані копії вашої бази даних Supabase, які\nзберігаються поза вашим обліковим записом Supabase, перечитуються й перевіряються\nперед тим, як будь-яка з них зарахується як зроблена. Під'єднайте свої\nStorage-бакети, і файли, які завантажили ваші користувачі, поїдуть разом, тож\nвідновлення поверне рядки й зображення, на які ці рядки вказують.",[10,247,248],{},"Тримайте branching увімкненим у будь-якому разі. Ніщо вище не є аргументом його\nвимикати.",[25,250,252],{"id":251},"що-зробити-цього-тижня","Що зробити цього тижня",[254,255,256],"key-takeaways",{},[174,257,258,261,264,267,270],{},[177,259,260],{},"З'ясуйте, що копіює вашу базу даних за розкладом, окремо від усього, що робить із неї гілки. Якщо на це йде більше хвилини, відповідь така, що не копіює ніщо.",[177,262,263],{},"Якщо ви ставилися до склонованої гілки як до страхувальної сітки, запишіть дату її створення й дату, коли закривається її pull request. Це два кінці того, що вона покриває.",[177,265,266],{},"Увімкніть бекап, який містить ваш план Supabase. Це найдешевше в цьому списку, і воно покриває звичайне нещастя, тобто те, що ви зіпсували власні дані.",[177,268,269],{},"Тримайте одну копію поза обліковим записом Supabase, бо гілка й бекап платформи обидва стоять за тим самим входом, що й річ, яку вони захищають.",[177,271,272],{},"Відновіть одну копію в тимчасовий проєкт, щоб уперше прочитати той файл не того дня, коли він вам потрібен.",[10,274,275,276,280,281,130],{},"Перш ніж закрити цю вкладку, відкрийте свій проєкт Supabase і подивіться, чи\nзнімає щось копію за розкладом. Ця одна відповідь це вся сьогоднішня робота, і\nbranching не змінює її в жоден бік.\n",[126,277,279],{"href":278},"\u002Fchecklist","10-хвилинний чекліст безпеки"," покриває її разом з рештою того, що\nварто підтвердити у щойно запущеному застосунку, а що містить копія й що\nнасправді робить кнопка відновлення, розписано на\n",[126,282,284],{"href":283},"\u002Fsupabase-backups","сторінці бекапів Supabase",{"title":286,"searchDepth":287,"depth":287,"links":288},"",3,[289,291,292,293,294,295,296],{"id":27,"depth":290,"text":28},2,{"id":133,"depth":290,"text":134},{"id":146,"depth":290,"text":147},{"id":165,"depth":290,"text":166},{"id":201,"depth":290,"text":202},{"id":225,"depth":290,"text":226},{"id":251,"depth":290,"text":252},"Backups","\u002Fblog\u002Fsupabase-branching-is-not-a-backup\u002Fcover-1200x630.png","Лінія даних біжить далі, а друга лінія відгалужується від неї й несе поруч порожню базу даних.","Чому branching у Supabase це не бекап: гілка стартує без ваших даних, а мердж переносить саму лише схему. Для чого він потрібен і що брати замість нього.",false,"md",[304,306,309,312,315],{"q":28,"a":305},"Ні. Гілка це окрема база даних Supabase, зібрана з ваших міграцій, і Supabase документує, що нові гілки стартують без жодних даних із вашого головного проєкту. Branching дає вам місце, де перевірити зміну до того, як вона дійде до продакшену. Бекап дає вам копію ваших даних на момент, який ви можете назвати, щоб до нього повернутися. Це дві різні роботи, і увімкнути першу не означає зробити щось для другої.",{"q":307,"a":308},"Чи є в preview-гілці Supabase мої продакшн-дані?","За замовчуванням ні. Supabase каже, що нові гілки стартують без жодних даних із головного проєкту, і називає причиною захист ваших продакшн-даних. Ви можете попросити клон під час створення гілки, і CLI описує цю опцію як клонування продакшн-даних у базу гілки. Якщо ви цього не просили, у вашій гілці є ваші таблиці й жодного вашого рядка.",{"q":310,"a":311},"Чи можу я відновити продакшн-базу з гілки?","У branching немає відновлення. Мердж застосовує міграції гілки до вашої продакшн-бази й публікує зміни ваших Edge Functions; ніщо на цьому шляху не переносить рядки й ніщо не відкочує нічого назад. Якщо ви склонували продакшн-дані в гілку, ви могли б зняти з тієї бази дамп і програти його самі, але тоді вас захищає дамп, а не гілка.",{"q":313,"a":314},"Що стається з гілкою, коли я мерджу pull request?","Preview-гілку видаляють. Supabase описує preview-гілки як ефемерні й каже, що вони видаляються автоматично, коли pull request змерджено або закрито. Персистентні гілки це інший тип, призначений для staging чи QA, і вони не зникають після закриття pull request. Тож якщо гілка тримає єдину копію чогось важливого для вас, налаштування за замовчуванням викидає її того дня, коли робота завершується.",{"q":316,"a":317},"Чи коштує branching окремо?","Так. Supabase пропонує branching на платних планах і рахує його погодинно за кожну гілку, понад вашу підписку. Читайте поточний тариф на їхній сторінці цін, а не тут, бо він їхній і вони можуть його змінити. Практично це означає: персистентна гілка, яку лишили ввімкненою, це другий проєкт Supabase, за який ви платите щогодини його існування.","\u002Fblog\u002Fsupabase-branching-is-not-a-backup\u002Fcard-800x500.png",[320,321,322,323,324,325],"supabase branching бекап","чи є branching у supabase бекапом","supabase preview гілка дані","supabase branching проти бекапу","supabase гілка продакшн дані","branching бази даних supabase",{},true,"Branching у Supabase це не бекап","\u002Fblog\u002Fsupabase-branching-is-not-a-backup","2026-08-25",{"title":5,"description":300},"blog\u002Fsupabase-branching-is-not-a-backup",[334,335,336],"Branching у Supabase це не бекап. Гілка це друга база даних для перевірки змін, і вона стартує без жодного вашого продакшн-рядка.","Мердж застосовує ваші зміни схеми до продакшену. Він ніколи не переносить рядки, і немає жодної операції, яка повертає давніший стан ваших даних.","Навіть гілка, у яку ви склонували свої дані, живе в тому самому обліковому записі, а preview-гілка видаляється, щойно закривається її pull request.","S7Uov8sSSV4FP-A_VjqOfn_buvZYnPkZl9cd2iIgIQA",1787826051130]