ШІ-агент видалив мої дані в Supabase. Що можна відновити?

Ви попросили агента прибрати кілька тестових рядків або полагодити міграцію, яка не хотіла застосуватися. Він сам написав SQL, запустив його проти проєкту, яким користується ваш живий застосунок, і повідомив, що готово. Застосунок і далі завантажується. Таблиця порожня.

Коли ШІ-агент видалив дані з вашої бази, те, що ви зможете відновити, вирішилося ще до його запуску. Наступні хвилини вирішують, скільки з цього вціліє.

Ось те місце, яке промахують майже всі відповіді на це питання. Вам радять відкотити код або попросити агента скасувати зроблене. Жодне з двох не торкається ваших даних, а поки ви пробуєте, єдине, що ще у ваших руках, тихо гіршає: те, що ваш застосунок просто зараз пише в базу.

Що можна відновити після того, як ШІ видалив мої дані?

Те, що було в останній копії вашої бази, знятій до видалення, і нічого з того, що з'явилося після неї.

Це вся відповідь, і більша її частина вирішилася кілька тижнів тому. Тут немає жодного експертного кроку, немає чого розвидаляти, немає журналу, який чекав би в Supabase, щоб його програли заново. Рядок, який прибрав DELETE або DROP TABLE, зник із бази тієї миті, коли інструкція підтвердилася. Назад повертається копія, а копія або існує, або ні.

Тож перед вами два завдання. З'ясувати, які копії існують. І не дати проміжку між найновішою з них і теперішнім моментом стати ще дорожчим, ніж він уже є.

Найперше: зупиніть усе, що пише в базу

Перш ніж шукати резервну копію, вимкніть усе, що пише нові рядки. Читання не заважає.

Причин дві, і друга людей заскочує.

Перша: відновлення не є злиттям. Повернути копію означає замінити таблиці, які в ній є, тим, що вони містили тоді, і все написане після неї піде разом з ними. Клієнт, який зареєструється за ту годину, поки ви це читаєте, стане рядком, який ви видалите власноруч, згодом, кроком, на який ви вже зважилися.

Друга: деякі шляхи гіршають, поки ви чекаєте. Відновлення на момент часу в Supabase повертає весь проєкт на обрану вами хвилину, тож що далі застосунок відходить від помилки, то більше справжньої роботи це повернення викидає разом зі шкодою.

Година за оголошенням про технічні роботи коштує дешево. Пояснювати комусь, що його замовлення створили, а потім навмисно прибрали, коштує значно дорожче.

Чи можна попросити агента скасувати це?

Ні. Він ніколи не тримав ваших рядків.

Агент написав інструкцію, а ваша база її виконала. Те, що він має тепер, залишається стенограмою тієї розмови, а стенограма відрізняється від копії таблиці. Попросіть його скасувати видалення, і ви отримаєте впевнену відповідь, правдоподібний SQL і жодних даних.

Про ризик варто сказати точно, бо прохання здається безневинним. Запустити агента ще раз означає другий безнаглядний сеанс проти живої бази, яка вже щось втратила. Якщо він вирішить, що зниклу таблицю найкраще полагодити, створивши нову, тепер на місці старої стоятиме нова порожня таблиця, а ви ускладнили опис втрати для того, хто допомагатиме вам наступним.

Заберіть його з проєкту, доки не зрозумієте, де ви стоїте. Те саме стосується історії версій вашого білдера: відкотити код до сьогоднішнього ранку означає відновити сторінки й лишити дані рівно там, де вони зараз, з причин, які варто зрозуміти один раз.

Де шукати, у такому порядку

Ідіть цим списком і спиніться на першому пункті, який у вас є. Він упорядкований за тим, скільки ваших даних повертається, а не за тим, наскільки це легко.

Кожен шлях, який щось повертає, має ту саму вимогу, і саме вона вирішує справу: він мав існувати до видалення. Жоден із них не вмикається зараз і не дотягується назад. Ваш тариф Supabase вирішує щодо перших двох, а перевірка забирає близько двох хвилин.

Що повертається, а що падає в проміжок

Копія такою, якою вона була, і нічого з того, що сталося після неї.

Рядки, створені між тією копією й видаленням, не пошкоджені й не ховаються десь у незручному кутку. Їх ніколи не записували ніде, окрім бази, з якої їх прибрали. Це та частина, яку важко прийняти перед порожньою таблицею, бо втратити щось зазвичай означає, що воно ще десь є.

Наскільки широка ця смуга, залежить тільки від того, що знімало копії. Нічна копія може вмістити туди цілий робочий день. Відновлення на момент часу звужує смугу до хвилини, і це майже вся причина його окремої ціни. Дамп, який ви зробили того дня, коли згадали про нього, вміщує туди весь час, що минув відтоді.

Є варіант, у якому проміжок важить мало: застосунок, дані якого здебільшого ваш власний вміст і змінюються повільно. І є варіант, у якому він важить дуже багато: усе, де живуть замовлення, повідомлення чи реєстрації, де день рядків означає день людей, які це помітять.

Агент видалив частину, а не все

Тоді перед вами справжній вибір, і жодна з двох відповідей не є чистою.

Відновлення не повертає зниклі рядки, лишаючи решту в спокої. Воно замінює таблиці з копії тим, що ці таблиці містили тоді, повністю. Відновити означає повернути прибране агентом і водночас відкотити кожен добрий рядок, написаний відтоді. Не відновлювати означає зберегти добрі рядки й лишити діру.

Що правильно, залежить від того, скільки справжньої роботи лежить після копії. Якщо відповідь майже ніякої, відновлюйте й живіть далі. Якщо відповідь три дні клієнтських записів, зазвичай виграє повільніший шлях: спершу експортувати вцілілі рядки, відновити, а потім покласти експортовані рядки згори. Це марудно, і це єдиний шлях, який нічого не втрачає.

Це також аргумент за те, щоб скопіювати базу в її нинішньому зламаному стані, перш ніж торкатися чогось узагалі. Хоч би що ви вирішили, ви хочете мати змогу повернутися до того стану, з якого почали.

Як минає та сама година, коли копія вже є

Коротше, і це радше рішення, ніж пошук. Ви обираєте копію, дивитеся, що вона тримала, і натискаєте кнопку.

Саме це робить Reeve Care: перевірені копії вашої бази Supabase за розкладом, зашифровані й збережені поза вашим обліковим записом Supabase, а за ними відновлення в один клац. Перш ніж відновлення почнеться, воно знімає свіжу копію поточного стану, щоб і саме відновлення можна було скасувати.

Обмеження варто назвати тим самим подихом, бо знати їх означає мати змогу вирішити, чи це вам підходить:

• Воно копіює вашу базу даних, а також файли, які завантажили ваші користувачі, щойно ви під’єднаєте свої бакети Storage. Це необов’язково й потребує другого ключа.
• Сьогодні воно працює з Supabase і більше ні з чим.
• Ви відновлюєтеся до копії, яка існує, а не до будь-якої хвилини, яку назвете. У найгіршому разі ви втрачаєте один інтервал, тобто до однієї ночі на початковому тарифі й менше на двох вищих.
• Облікових записів для входу ніколи не торкаються. Нікого не розлогінюють, не видаляють і не повертають.
• Ключ до бази, який зберігається, вміє тільки читати, і це була обіцянка тоді, коли ви його під'єднали. Записати дані назад потребує того, який уміє писати, тож відновлення щоразу питає пароль вашої бази й не лишає жодного. Необов’язковий ключ до ваших файлів уміє писати, бо Supabase не видає для Storage ключів лише для читання, і сторінка, де ви його передаєте, каже про це заздалегідь.

Що покриває кожен тариф, написано на головній сторінці. Якщо ви волієте не платити за це нічого, простий варіант того самого захисту це pg_dump за розкладом, якого ви справді дотримуєтеся, збережений там, куди не дотягнеться втрата вашого облікового запису Supabase. Три шляхи й те, що проминає кожен із них проходить це без продажної промови.

Цю саму годину показано, копія за копією, на сторінці резервних копій Supabase.

Що робити просто зараз

Перш ніж закрити цю вкладку, відкрийте свій проєкт Supabase і дізнайтеся, чи хоч щось копіює вашу базу, а тоді запишіть, де ця копія лежить. Десятихвилинний чеклист безпеки покриває це разом з рештою того, що варто підтвердити у щойно запущеному застосунку.