Чому у вашому дампі Supabase немає користувачів

Ви зробили відповідальну річ. Знайшли, як зробити резервну копію бази Supabase, запустили команду, яку знайшли, і поклали файл у безпечне місце.

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

Ось частина, яку майже кожен посібник пропускає: supabase db dump сам по собі це не копія ваших даних. Без інших прапорців він пише форму вашої бази і нічого з її вмісту, а auth лишає поза навіть цим. Supabase публікує резервну копію як три команди, і ваші акаунти їдуть у третій.

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

Чи містить резервна копія Supabase моїх користувачів?

Залежить від того, яка команда написала файл, і команда, яку запускає більшість, їх не містить.

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

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

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

Що команда dump пише сама по собі

План поверхів. Жодного рядка і нічого з auth.

Довідкова сторінка Supabase про цю команду каже це двома реченнями. Вона запускає pg_dump із додатковими прапорцями, щоб виключити керовані Supabase схеми, і серед ігнорованих є auth, storage і створені розширеннями. Та сама сторінка далі каже, що типовий дамп не містить ані даних, ані власних ролей, і що ви отримуєте їх, попросивши через --data-only і --role-only.

Тож ось це, що ви найімовірніше й запускали:

supabase db dump --db-url "postgresql://…your connection string…" -f backup.sql

дає файл, повний інструкцій CREATE TABLE. Кожен стовпець, кожен індекс, кожна політика, яку ви написали на своїх таблицях, і жодного рядка чогось.

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

Як перевірити дамп, який у мене вже є?

Відкрийте його в текстовому редакторі й пошукайте auth. Те, що знайдеться, кладе ваш файл в одну з трьох груп.

1. Жодного збігу. Схеми auth немає в цьому файлі в жодному вигляді. Саме це пише голий supabase db dump.
2. Збіги, але лише в рядках, що починаються з CREATE, ALTER або GRANT. У вас є креслення реєстру і нікого всередині.
3. Рядок COPY "auth"."users" або COPY auth.users, під яким ідуть рядки даних до рядка з \. Або низка рядків, що починаються з INSERT INTO "auth"."users". Ваші акаунти там.

Якщо вам зручніше в командному рядку, два grep відповідають на те саме:

grep -c 'auth.*users' backup.sql
grep -n 'COPY .*auth.*users\|INSERT INTO .*auth.*users' backup.sql

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

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

Як експортувати користувачів auth у Supabase?

Командою даних, яка є іншою командою, ніж та, що пише схему.

Посібник Supabase із резервного копіювання та відновлення публікує копію як три файли, і їх варто побачити разом, бо ця форма і є відповіддю:

supabase db dump --db-url "postgresql://…" -f roles.sql --role-only
supabase db dump --db-url "postgresql://…" -f schema.sql
supabase db dump --db-url "postgresql://…" -f data.sql --use-copy --data-only \
  -x "storage.buckets_vectors" -x "storage.vector_indexes"

Другий рядок це той, який запускають окремо. Третій це той, у якому ваші користувачі.

Ці два факти виглядають як суперечність, і вони нею не є. Речення на довідковій сторінці Supabase про виключення auth описує дамп схеми, а дамп даних проходить і цією схемою теж.

Якщо вам потрібні лише акаунти, назвіть схему і отримаєте саму цю шухляду:

supabase db dump --db-url "postgresql://…" -f users.sql --data-only --use-copy --schema auth

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

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

pg_dump "postgresql://…" --schema public --schema auth --schema storage \
  --no-owner --file backup.sql

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

Що ламається, коли ви повертаєте користувачів

Дві речі, і Supabase документує обидві.

Тригери, які здатні зашифрувати стовпець двічі. Команда відновлення в посібнику Supabase має посередині інструкцію, яку легко прочитати як шум:

psql \
  --single-transaction \
  --variable ON_ERROR_STOP=1 \
  --file roles.sql \
  --file schema.sql \
  --command 'SET session_replication_role = replica' \
  --file data.sql \
  --dbname "postgresql://…"

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

Власність і права, які спинять прокручування. Дамп, знятий із проєкту Supabase, несе рядки, що посилаються на ролі, до яких новий проєкт вас не пустить. Нотатки з усунення несправностей до того самого посібника кажуть закоментувати будь-який рядок із ALTER ... OWNER TO "supabase_admin" у schema.sql і конкретний рядок GRANT "postgres" TO "cli_login_postgres" у roles.sql. Обидва це текстова правка перед початком, і обидва спиняють прокручування, надрукувавши на екрані рядок, на якому воно вдавилося.

Чи доведеться моїм користувачам входити знову?

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

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

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

Тож чесна версія така, що відновлення зазвичай просить усіх увійти один раз. Це лист у підтримку. Це не втрачений акаунт, а різниця між цими двома в тому, чи була схема auth у вашому файлі.

Трьох речей у ньому однаково немає, хоч що ви робіть із прапорцями. Ваших завантажених файлів, бо Storage тримає байти поза базою і жоден дамп на жодному плані до них не дістає. Ваших edge-функцій, які є окремим завантаженням і чиї import maps, зазначає Supabase, не забираються автоматично. І налаштувань вашого проєкту, які є конфігурацією, а не даними, і вводяться руками наново.

Що зробити цього тижня

Зробити це один раз руками варто незалежно від того, як ви зрештою робитимете копії, бо доки ви не відкрили дамп, у вас було саме лише слово «резервна копія». Чи робити далі руками, це окреме питання, і три шляхи та скільки коштує кожен це місце, де на нього відповідають.

Де тут місце Reeve Care

Care знімає копію за розкладом, і реєстр у ній.

• Ваші акаунти в копії. Схема auth їде разом із вашими власними таблицями, бо копія застосунку на Supabase без його користувачів це копія половини. Рядки storage, що описують ваші файли, теж приїжджають, і самі файли також, щойно ви під'єднаєте облікові дані Storage.
• Кнопка відновлення повертає ваші таблиці й лишає акаунти у спокої. Прокрутити auth.users поверх живого проєкту означає вигнати всіх із системи й повернути акаунти, які хтось видалив навмисно, тож це лишається запитом, над яким є людина. Тож натиснути кнопку в паніці не вийде так, щоб вигнати клієнтів, яким ви намагалися допомогти.
• Копію перечитують, перш ніж вона зарахується як знята. Дата у вашій панелі це останній раз, коли копію відкрили й перевірили, а не момент, коли стартувало завдання чи приземлився файл.
• Відновлення спершу робить знімок поточного стану, тож у самого відновлення є скасування.

Care починається від $49 на місяць за один застосунок. Це прейскурантна ціна, і сторінка цін іноді нижча за цифру тут і ніколи не вища.

Як копію знімають, перевіряють і повертають, намальовано крок за кроком на сторінці резервних копій Supabase.

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