Reeve Backups
Історія версій не є резервною копією. Вона не поверне таблицю.
Lovable і Bolt ведуть історію версій вашого коду. Ваша база даних працює як окремий сервіс, тож відкат назад не поверне ваші дані.
Коротко
- Історія версій відновлює ваш код. Вона ніколи не торкається бази даних, а саме там живуть ваші користувачі, їхній вміст і їхні замовлення.
- Тобто видалена таблиця, перезаписаний рядок чи невдала міграція переживають відкат цілком неушкодженими.
- У вашого коду скасування вбудоване. У ваших даних воно є лише тоді, коли ви його туди покладете.
Щось зламалося, тож ви зробили розумну річ. Відкрили історію версій у Lovable чи Bolt, знайшли ранкову версію й натиснули відновити. Застосунок повернувся точно таким, яким був.
Дані не повернулися.
Ось те місце, де люди спотикаються: ваш код і ваші дані живуть як дві окремі системи, і кнопка скасування є лише в однієї з них. Ваш білдер зберігає креслення застосунку. Ваша база даних тримає те, що всередині. Історія версій бездоганно відбудовує креслення, до останньої деталі, і повертає вам ідентичну порожню будівлю.
Чи створює історія версій мого білдера копію моєї бази даних?
Ні. Вона зберігає ваш код, а ваші дані живуть зовсім деінде.
Lovable, Bolt, v0, Replit, Cursor та інші ведуть історію файлів вашого проєкту: сторінок, компонентів, логіки, оформлення. Це і є креслення. Відновлення версії переписує ці файли такими, якими вони були в обраний вами день.
Ваша база даних працює як інший сервіс, майже завжди Supabase, на власному акаунті. Ніщо в історії вашого проєкту туди не дістає. Відновлення не має жодної думки про ваші дані, бо не може їх побачити.
Чому код і дані лежать у двох різних місцях
Бо ваші дані мають пережити те, що ваш код робить постійно: зміни.
Ваш код перебудовується щоразу, коли ви публікуєте. Якби замовлення ваших користувачів жили всередині нього, вони стиралися б щоразу, коли ви лагодите кнопку. Тому ці двоє тримаються окремо, і навмисно: код замінний, а дані ні, і саме тому їх версіонують різні інструменти.
Ціна цього розділення і є темою цієї статті. Кожен інструмент, який версіонує одне, сліпий до іншого. Ваш білдер не поверне таблицю, а ваша база даних не поверне зламану сторінку.
Що насправді відбувається під час відкату
Ваші екрани повертаються до колишнього вигляду. Ваші дані не рухаються взагалі.
| Що | Під час відкату коду |
|---|---|
| Сторінки, компоненти, оформлення | Відновлено |
| Логіка застосунку та її виправлення | Відновлено |
| Таблиця, яку хтось видалив | Лишається видаленою |
| Рядки, які перезаписав скрипт | Лишаються перезаписаними |
| Стовпець, який прибрала міграція | Лишається прибраним |
| Файли, які завантажили ваші користувачі | Без змін в обидва боки |
Рядок про міграцію дивує найбільше. Міграція, яку ви запустили проти своєї бази, вже сталася: вона живе в базі, а не у вашому репозиторії, і скасувати файл, що її описував, нічого не змінить.
Де це справді кусає
У ті десять хвилин після помилки, коли ви шукаєте скасування й виявляєте, що його немає.
Форми, яких це набуває, цілком буденні:
- Видалення в редакторі таблиць Supabase, що зачепило більше рядків, ніж ви хотіли.
- Міграція за допомогою ШІ, яка прибрала стовпець, щоб зникла помилка типів.
- Скрипт наповнення чи скидання, спрямований на бойовий проєкт замість тестового.
- Прибирання того, що виглядало як тестові дані, а виявилося чиїмось справжнім акаунтом.
Жодна з цих речей не торкається жодного рядка вашого коду. Кожна з них переживає відкат неушкодженою, і саме тому відкат здається таким, що нічого не зробив. Він зробив рівно те, що робить.
Для чого історія версій справді добра
Для чималого, і це варто сказати прямо, бо відповідь тут не «ні для чого».
Це справжнє скасування для справжніх проблем: зміна оформлення, про яку ви шкодуєте, публікація, що зламала сторінку, правка ШІ, яка переписала робочий екран на гірше, функція, що зрештою зробила застосунок складнішим. Усе це живе у вашому коді, і для цього вона працює саме так, як обіцяно.
Проблема полягає в тихому припущенні, що її робота покриває все. Такого припущення ніхто не робить навмисне; воно те, з чим ви лишаєтеся, коли ніхто не сказав вам, що систем дві.
Як здобути справжнє скасування для ваших даних
Його треба покласти туди самому. Тобто копію бази даних, зняту за розкладом і збережену там, куди втрата акаунта не дотягнеться.
Зробити це можна трьома способами, вони коштують різних грошей і різної уваги, і кожному бракує того, що покривають інші. Три способи зробити резервну копію бази Supabase проходить усі три, зокрема той, який більшості варто увімкнути першим, і причину, чому самого його замало.
Саме для цього є й Reeve Care: копії вашої бази Supabase за розкладом, збережені поза вашим акаунтом Supabase і перевірені, перш ніж зарахуватися. Під’єднайте свої бакети Storage — і файли, завантажені вашими користувачами, поїдуть разом, тож відновлення поверне рядки й зображення, на які вони вказують.
Що містить така копія і що насправді робить кнопка — на сторінці резервних копій Supabase.
Що зробити цього тижня
Що робити
- З'ясуйте, чи щось узагалі зараз копіює вашу базу даних. Не код. Базу даних. Якщо відповідь шукається довше за хвилину, відповідь «ні».
- Увімкніть резервну копію, яку включає ваш тариф Supabase. Вона захищає від ваших власних помилок, а саме про цю поломку й ідеться.
- Тримайте ще одну копію деінде, бо копія, що живе всередині акаунта, не допоможе, якщо ви втратите акаунт.
- Копіюйте завантажені файли окремо. Вони не лежать ані у вашому коді, ані у вашій базі.
- Відновіть одну копію в тимчасовий проєкт, щоб перше читання того файлу не припало на день, коли він потрібен.
Перш ніж закрити цю вкладку, відкрийте свій проєкт Supabase і подивіться, чи увімкнено резервні копії. Ця одна перевірка і є вся сьогоднішня робота. 10-хвилинний чеклист безпеки охоплює її разом з рештою того, що варто підтвердити у щойно запущеному застосунку, а посібник із безпеки Supabase проходить по тому, що ще зазвичай лишається відкритим.
Поширені запитання
Я випадково видалив таблицю. Чи можна її повернути?
Лише з копії, зробленої до видалення, тож перше, що варто з'ясувати: чи є така копія взагалі. Відкат коду цього не зробить, і ваш білдер теж. На платному тарифі Supabase є щоденні копії та відновлення на момент часу, якщо ви його додали. На безкоштовному тарифі автоматичного немає нічого. Перевірте, що ви маєте, перш ніж міняти будь-що інше: деякі шляхи назад ускладнюються, щойно поверх прогалини починають писатися нові дані.
Чи робить Lovable резервні копії моєї бази Supabase?
Ваш білдер зберігає версії файлів проєкту. Ваша база даних працює як окремий сервіс на вашому власному акаунті Supabase, і ніщо в історії проєкту туди не дістає. Білдери додають нові можливості, тож дивіться документацію саме свого, а не припускайте в той чи інший бік. Але виходьте з того, що відповідь «ні», доки не прочитаєте, що «так».
Чи є моя історія Git резервною копією?
Ні, рівно з тієї самої причини, з якої нею не є історія версій. Git стежить за файлами, з яких збирається ваш застосунок. Він жодного разу не бачив жодного рядка ваших даних і не може повернути жоден. Репозиторій і база даних відрізняються за своєю природою, хоча обидва звуться «ваш проєкт».
Мої дані на місці. Чи треба щось робити сьогодні?
Сьогодні найдешевший день, коли ви це налаштуєте, бо даних мало, а важить те, щоб звичка існувала до того, як стане потрібною. Втрати, які болять, рідко бувають драматичними. Це помилково набрана команда під час нічного ремонту, у проєкті, де реальних користувачів рівно стільки, щоб почати з нуля вже не вийшло.