Reeve Backups
Як відновити резервну копію Supabase, і що ламається потім
Як відновити резервну копію Supabase з панелі або з файлу дампа, що саме замінює відновлення і чому ваш застосунок може лишитися зламаним після нього.
Коротко
- Щоб відновити резервну копію Supabase, ви або відкочуєте проєкт у панелі, або програєте файл дампа в проєкт через psql. Який із двох шляхів вам доступний, вирішилося ще до сьогодні.
- Скопіюйте базу такою, якою вона є зараз, перш ніж щось відновлювати. Відновлення замінює таблиці, що є в копії, тож кожен рядок, написаний відтоді, іде разом із ними.
- Звичний результат це відновлення, яке спрацювало, і застосунок, який усе одно зламаний, бо ваші завантажені файли й облікові записи ніколи не були в копії бази.
Щось у вашій базі даних пішло не так, і цього разу у вас є копія. Тепер ви дивитеся на кнопку, яку ніколи не натискали, у проєкті зі справжніми користувачами всередині, й міркуєте, що вона зараз із ними зробить.
Ось частина, яку гайд за гайдом лишає поза кадром. Майже кожна стаття про те, як відновити резервну копію Supabase, закінчується в ту мить, коли відновлення завершилося, а саме там починається більшість клопоту. Звичний результат це не відновлення, яке провалилося. Це відновлення, яке спрацювало й усе одно лишило застосунок зламаним, бо копія бази ніколи не містила нічого, крім бази.
Допомагає перестати уявляти це як повернення ваших даних. Відновлення міняє вашу базу на старішу, і це ближче до заміни цілої шафи з документами, ніж до повернення однієї теки на місце. Усе далі випливає з цього.
Як відновити резервну копію Supabase?
Три шляхи, і який із них відкритий вам сьогодні, вирішилося ще до сьогодні.
| Шлях | Що робить | Що потрібно |
|---|---|---|
| Панель Supabase | Замінює базу того проєкту датованою нічною копією на ваш вибір | Платний план, і копія ще лежить у вашому вікні |
| Point-in-time recovery | Відкочує весь проєкт до хвилини, яку ви назвете | Додаток PITR, придбаний до того, від чого ви оговтуєтесь |
Файл дампа, програний через psql | Завантажує файл у той проєкт, на який ви вкажете, включно з новісіньким | Файл, і пароль бази даних цільового проєкту |
Перші два кладуть ваші дані туди, де вони й були. Третій єдиний, хто може покласти їх деінде, і саме це потрібно того дня, коли проблема це ваш обліковий запис, а не ваші дані.
Якщо ви не певні, що саме у вас є, план Supabase, на якому ви сидите, вирішує перші два, і перевірка займає близько двох хвилин.
Скопіюйте те, що маєте зараз, перш ніж щось відновлювати
Спершу зробіть копію бази в її нинішньому зламаному стані. Це одна команда, і саме вона робить оборотним кожне наступне рішення.
pg_dump "postgresql://…ваш рядок підключення…" \
--clean --if-exists --no-owner \
--file before-restore-2026-08-24.sql
Причин дві, і другу люди зазвичай дізнаються запізно.
Перша та, що відновлення це заміна. Таблиці з копії повертаються рівно такими, якими були, тож кожен рядок, написаний у них відтоді, іде разом із ними. Клієнтка, яка зареєструвалася сьогодні вранці, це рядок, який ви зараз навмисне видалите.
Друга та, що ваша зламана база й досі лишається єдиним місцем, де частина ваших даних узагалі існує. Якщо копія від вівторка, а шкода сталася в четвер, то все створене в середу стоїть перед вами просто зараз і більше ніде. Відновіть згори, і воно зникне вдруге, цього разу вашою рукою, а не через випадковість.
Поки ви працюєте, вимкніть усе, що пише нові рядки. Міркування ті самі, що й після будь-якого невдалого видалення: проміжок між копією й теперішнім дорожчає тим більше, чим довше застосунок його заповнює.
Відновлення з панелі Supabase
Це замінює базу вашого проєкту копією, яку ви оберете, і проєкт недоступний, поки воно триває.
Відкрийте проєкт, з яким говорить ваш застосунок, зайдіть у Database, потім Backups, і виберіть датовану копію. Точні кроки читайте у власній документації Supabase про резервні копії, бо панель перебудовують, а ця сторінка цього не помітить.
Скільки це триває, залежить від розміру вашої бази, і це відповідь самого Supabase. Поставте повідомлення про технічні роботи перед початком.
Point-in-time recovery це та сама операція з тоншим регулятором. Замість обрати минулу ніч ви називаєте хвилину, і проєкт відкочується до неї. Supabase називає це руйнівною дією, і це правильне слово. Їхні нотатки підтримки додають, що відновлення point-in-time не може початися, доки не прибрано наявні слоти реплікації та підписки. Тож якщо щось у вашому застосунку читає зміни бази в міру їх появи, це крок перед початком, а не помилка на півдорозі.
Жоден із цих двох шляхів не покладе ваші дані в інший проєкт. Обидва діють на проєкт, у якому ви стоїте, а отже жоден недоступний того дня, коли зламався саме ваш доступ до облікового запису.
Відновлення файлу дампа через psql
Ви наводите psql на проєкт і програєте файл усередину. Той проєкт може бути
тим, що у вас був, або новісіньким на обліковому записі, який ви відкрили сьогодні
вранці.
psql -d "postgresql://…рядок підключення цільового проєкту…" \
--variable ON_ERROR_STOP=1 \
--single-transaction \
--file backup-2026-08-09.sql
Два з цих перемикачів варто розуміти, бо саме типова поведінка psql і є несподіваною.
ON_ERROR_STOP=1 спиняється на першій помилці. Без нього psql читає помилку,
друкує її й іде далі до наступного рядка, тож файл, який зламався на рядку 400 із
30 000, усе одно закінчується запрошенням, схожим на успіх, над базою, якій
бракує всього після того рядка. --single-transaction загортає весь файл в одну
операцію, тож збій лишає базу такою, якою вона була, а не наполовину зміненою.
Далі облікові дані, на яких багато хто застрягає. Програти резервну копію означає
писати, тож потрібне щось, що вміє писати. Ключ anon цього не зробить, і ключ
лише для читання теж. Те, чого хоче psql, це пароль бази даних цільового
проєкту, і він лежить у налаштуваннях вашого проєкту Supabase, у розділі Database.
Що саме повернеться, залежить від того, що є у файлі, а це вирішилося тоді, коли
дамп створювали. Ваші облікові записи це та частина, яку варто перевірити,
перш ніж на неї покладатися. Вони живуть у схемі з назвою auth поруч із
хешованими паролями, і Supabase описує
їхнє перенесення між проєктами
як роботу з власними кроками. Якщо ви відновлюєте в новий проєкт і хочете, щоб
люди заходили з паролем, який у них уже є, прочитайте ту сторінку перед початком.
А новий проєкт має новий URL і нові ключі. Ваш застосунок і далі вказує на старий, доки ви цього не зміните, і саме з цього починається наступний розділ.
Відновилося, а застосунок усе одно зламаний
Це звичайний результат. Майже завжди це одна з п'яти речей, і перша забирає хвилину.
| Що ви бачите | Що сталося насправді | Що робити |
|---|---|---|
| Застосунок вантажиться, а кожен список порожній | Він і далі говорить зі старим проєктом | Впишіть URL і публікований ключ нового проєкту в налаштування застосунку й розгорніть його заново |
| Зображення, аватари й завантаження зникли | Файли живуть у Storage, поза базою. Відновлені рядки містять лише шлях до кожного файлу | Відновіть файли з їхньої власної копії. Жодна копія бази не містить їх, на жодному шляху |
| Ніхто не може увійти | Облікові записи живуть у схемі auth, а чи були вони у файлі, залежить від того, як робили дамп | Скористайтеся посібником Supabase з міграції auth або відновіть із копії, що містить цю схему |
| Сторінки читаються добре, а збереження не працює | База повернулася доступною для читання й не для запису | Створіть рядок через застосунок, перш ніж вважати справу закритою. Абзац нижче має подробиці |
| Одна функція зламана, а її таблиця ціла | Edge-функції живуть у вашому репозиторії, поза базою | Розгорніть їх заново з білдера або з репозиторію |
Четверта заслуговує на увагу. Право читати й право писати надаються окремо, і відновлення може влучити в одне й промазати повз інше. Тож сторінки наповнюються вашими даними, усе виглядає відновленим, а потім перша людина, яка надсилає форму, отримує помилку. Погляд на застосунок ніколи вам цього не покаже, бо дивитися це читати.
Як зрозуміти, чи відновлення справді вдалося
Увійдіть, знайдіть рядок, який можете назвати, а потім напишіть один. Саме в такому порядку, і остання перевірка та, що важить.
- Увійдіть через застосунок так, як увійшов би користувач, а не відкривайте редактор таблиць Supabase. Це перевіряє застосунок, з'єднання й облікові записи за один раз.
- Знайдіть рядок, який пам'ятаєте. Конкретне замовлення, названий клієнт, останнє, що ви додали перед поломкою. «Дані наче на місці» це відчуття; рядок, який ви можете назвати, це перевірка.
- Порівняйте кількість із тим, чого очікували. Відкрийте найбільшу таблицю в редакторі Supabase і прочитайте число рядків. Відновлення, що спинилося посередині, зазвичай виявляється тут як завелика нестача.
- А тоді напишіть щось. Створіть рядок так, як це робить користувач: оформте тестове замовлення, збережіть профіль, залиште коментар. Це перевірка, яка провалюється, коли три попередні проходять, і єдине, що доводить, що відновлення завершилося.
- Відкрийте щось, що завантажив користувач. Якщо у вашому застосунку є зображення чи вкладення, клацніть одне з них. Чи повернулися ваші файли, це окреме питання від того, чи повернулися рядки.
Що зробити просто зараз
Що робити
- Скопіюйте базу такою, якою вона є зараз, перш ніж щось відновлювати. Це один
pg_dump, і саме він робить наступне рішення оборотним. - Вимкніть усе, що пише нові рядки, поки ви працюєте, бо відновлення видаляє все, що надійшло після зроблення копії.
- Добирайте шлях під проблему. Відновлення з панелі лагодить ваші дані; лише файл дампа, програний через
psql, здатен перенести їх у новий проєкт. - Якщо користуєтесь
psql, вмикайтеON_ERROR_STOP=1. Відновлення, яке тихо здалося посередині, виглядає точно так само, як те, що вдалося. - Перевіряйте відновлення записом, а не читанням. Увійдіть, знайдіть рядок, який можете назвати, а тоді створіть один через застосунок.
- Ставтеся до завантажених файлів і облікових записів як до окремих робіт. Жодна з них не закінчена, коли закінчена база.
Перш ніж закрити цю вкладку, з'ясуйте, чи маєте ви взагалі з чого відновлювати й де воно лежить. Ця одна відповідь вирішує, яка половина цієї статті вам колись знадобиться. Десятихвилинний чекліст безпеки охоплює це поряд з рештою того, що варто перевірити в щойно запущеному застосунку, а посібник з безпеки Supabase проходить по тому, що зазвичай лишається відкритим.
Що робить Reeve Care того дня, коли ви відновлюєте
Копія вже існує, її вже прочитали назад і перевірили, і лежить вона поза вашим обліковим записом Supabase. Це перетворює описану вище годину на вибір, яку саме копію, і на натискання кнопки.
Чотири речі, які це змінює саме в цій статті.
Копію перевірено ще до того, як вона вам знадобилася. Кожну резервну копію читають назад і звіряють із тим, що в неї пішло, а дата у вашій панелі це остання копія, яка пройшла перевірку, а не остання спроба. Наполовину зроблене відновлення, від якого застерігає ця стаття, це проблема, яку ми знаходимо звичайного пообіддя, перш ніж вона стане вашою.
Страхувальна копія це не крок, який треба пам'ятати. Натискання «відновити» спершу робить свіжу копію поточного стану, тож саме відновлення можна скасувати.
Ваші завантажені файли теж повертаються, щойно ви під'єднаєте свої бакети Storage. Це той рядок таблиці вище, який інакше не має доброї відповіді.
Ключ до бази, який ми тримаємо, вміє лише читати. Відновлення мусить писати, тож воно щоразу питає пароль вашої бази й не зберігає жодного. Необов'язковий ключ до ваших файлів уміє писати, бо Supabase не видає ключа лише для читання для Storage, і сторінка, де ви його передаєте, каже це заздалегідь.
Обмеження йдуть тим самим подихом, бо їх краще знати до оплати, ніж під час збою:
- Працює із Supabase і сьогодні більше ні з чим.
- Ви відновлюєтеся до копії, яка існує, а не до будь-якої названої хвилини. У найгіршому разі ви втрачаєте один інтервал, це до ночі на початковому плані й менше на двох вищих.
- Облікові записи не чіпають ніколи. Нікого не виводять із сесії, не видаляють і не повертають.
Хай там як, лишайте резервні копії Supabase увімкненими. Дві копії у двох місцях це вся ідея, і дешевша з них уже є у вашому плані. Що охоплює кожен план Care, написано на головній сторінці.
Якщо ви волієте не платити за жодне з цього, усе в цій статті працює й так.
pg_dump за розкладом, якого ви справді дотримуєтесь, збережений там, куди
втрата вашого облікового запису Supabase не дотягнеться, плюс одне тренувальне
відновлення на квартал, доводить вас майже до кінця.
Три шляхи й те, що кожен із них лишає поза увагою
розповідає це без продажів.
Увесь цикл намальовано крок за кроком на сторінці резервних копій Supabase: як копія покидає Supabase, перевірка, що йде за нею, і кнопка, яка кладе її назад.
Поширені запитання
Як відновити резервну копію Supabase?
Є три шляхи. У панелі ви обираєте датовану нічну копію, і Supabase замінює нею базу того проєкту, для чого потрібен платний план. Point-in-time recovery відкочує весь проєкт до хвилини, яку ви назвете, і потребує додатка PITR, придбаного заздалегідь. Або ви самі програєте файл дампа через psql, і це єдиний шлях, здатний перенести ваші дані в інший проєкт на іншому обліковому записі. Перед будь-яким із трьох зробіть копію бази такою, якою вона є зараз.
Чи видаляє відновлення дані, додані після створення копії?
Так. Відновлення це заміна, а не злиття: таблиці з копії повертаються рівно такими, якими були на той момент, і все написане в них потім зникає. Разом із рядками, з якими все було гаразд. Саме тому варто зупинити запис у застосунку перед початком, і саме тому варто зберегти копію поточного стану, щоб потім покласти добрі новіші рядки згори, якщо ви вирішите, що вони вам потрібні.
Відновлення завершилося, але зображення в застосунку зникли. Чому?
Бо ваших файлів ніколи не було в резервній копії. Supabase Storage живе поза вашою базою Postgres, тож копія бази містить рядок, що вказує на кожен файл, і жодного файлу. Відновлення дає вам таблицю, повну посилань на те, чого вже немає, або на те, що лежить у проєкті, яким ви більше не користуєтесь. Storage треба копіювати й відновлювати окремо, хоч який шлях резервного копіювання ви обрали.
Чи можу я відновити копію Supabase в інший проєкт?
Лише з файлу дампа, який ви тримаєте самі. Відновлення в панелі й point-in-time recovery обидва діють на проєкт, у якому ви стоїте, тож жоден не допоможе того дня, коли проблема саме в тому, що ви не можете зайти в обліковий запис. Файл pg_dump, програний через psql, потрапляє в той проєкт, на який ви вкажете, включно з щойно створеним на новому обліковому записі. Це і є та різниця того дня, коли вона важить.
Чи доведеться моїм користувачам реєструватися заново після відновлення?
Це залежить від того, чи були облікові записи в копії. Вони живуть у схемі бази з назвою auth разом із хешованими паролями, і Supabase описує їхнє перенесення між проєктами як роботу з власними кроками, а не як щось, що їде разом із вашими таблицями. Якщо ви відновлюєте в новий проєкт, прочитайте той посібник перед початком. Відновлення в межах того самого проєкту зазвичай лишає вхід недоторканим.
Скільки триває відновлення в Supabase?
Supabase каже, що це залежить від розміру вашої бази й від того, скільки даних треба обробити, і це чесна відповідь, яка мало допомагає, поки ви чекаєте. Виходьте з того, що проєкт буде недоступний увесь цей час, і поставте повідомлення про технічні роботи перед початком. Їхні нотатки підтримки додають, що відновлення point-in-time не може початися, доки не прибрано наявні слоти реплікації та підписки, тож перевірте це насамперед, якщо щось у вашому застосунку читає зміни бази наживо.