پرش به مطلب اصلی

مهاجرت از Remnawave

XLADA فورکی از Remnawave تحت AGPL-3.0-only است، بنابراین مهاجرت به جابه‌جایی ایمیج‌ها خلاصه می‌شود: نام‌های سرویس، والیوم پایگاه داده و شبکه همان قبلی می‌مانند و PostgreSQL روی همان دایرکتوری داده بالا می‌آید. در ادامه — ترتیب «در جای خود»، روی همان سرور.

چه چیزی حفظ می‌شود​

فقط ایمیج‌های کانتینرها تغییر می‌کنند. نام جدول‌ها و ستون‌ها در فورک عمداً تغییر نام نداده‌اند، بنابراین پایگاه دادهٔ فعال معتبر می‌ماند:

مدلجدول
کاربرانusers
نودهاnodes
هاست‌هاhosts
مدیرانadmin
توکن‌های APIapi_tokens
دستگاه‌های HWIDhwid_user_devices
پروفایل‌های پیکربندیconfig_profiles
گروه‌های داخلی و خارجیinternal_squads, external_squads
تنظیماتremnawave_settings

فایل .env بدون تغییر نام کلیدها منتقل می‌شود: APP_SECRET، POSTGRES_USER، POSTGRES_PASSWORD، POSTGRES_DB، DATABASE_URL، PANEL_DOMAIN، FRONT_END_DOMAIN، SUB_PUBLIC_DOMAIN و بقیه به همان شکل خوانده می‌شوند. صفحهٔ اشتراک همچنان از متغیرهای با پیشوند REMNAWAVE_ استفاده می‌کند (REMNAWAVE_PANEL_URL، REMNAWAVE_API_TOKEN).

مهاجرت‌های XLADA فقط افزایشی‌اند: جدول گزارش اقدامات مدیران و فیلدهای عامل دوم اضافه می‌شوند. بنابراین مهاجرت برگشت‌پذیر است — کافی است ایمیج قبلی پنل را برگردانید.

آماده‌سازی​

پیش از شروع نام‌ها و نسخه‌های واقعی را بررسی کنید — بالا آمدن پایگاه داده به آن‌ها بستگی دارد:

docker volume ls
docker ps --format 'table {{.Names}}\t{{.Image}}'
والیوم و نسخهٔ PostgreSQL

فایل مهاجرت نام والیوم نصب قبلی را حفظ می‌کند (در compose استاندارد این نام remnawave-db-data است). اگر والیوم شما نام دیگری دارد، آن را تغییر نام ندهید، بلکه دستور name: در compose را به نام موجود برسانید.

دایرکتوری داده میان نسخه‌های ماژور ناسازگار است. compose جدید XLADA برای PostgreSQL 18 در نظر گرفته شده است، اما برای مهاجرت همان نسخهٔ ماژوری گرفته می‌شود که والیوم شما را ساخته — در فایل آماده این postgres:17.6 است. انتقال به 18 بعداً و در گامی جداگانه با پشتیبان (dump) و بازیابی انجام می‌شود.

نسخهٔ پشتیبان​

از پایگاه داده پشتیبان (dump) بگیرید و .env را ذخیره کنید. تا زمانی که مهاجرت بررسی نشده، پشتیبان را بیرون از والیوم پایگاه داده نگه دارید.

docker exec remnawave-db pg_dump -U "$POSTGRES_USER" "$POSTGRES_DB" \
> ~/remnawave-backup-$(date +%F).sql
tail -n 1 ~/remnawave-backup-*.sql # انتظار می‌رود: -- PostgreSQL database dump complete

cp deploy/.env ~/remnawave-env-backup
chmod 600 ~/remnawave-env-backup

توقف استک قدیمی​

cd deploy && docker compose down

بدون پرچم -v متوقف کنید: آن والیوم‌ها را همراه با پایگاه داده حذف می‌کند.

اجرای XLADA روی همان پایگاه داده​

فایل docker-compose.migrate-from-remnawave.yml را از مخزن XLADA بردارید. این فایل با compose معمولی فقط در این تفاوت دارد که نام سرویس‌ها و والیوم نصب قبلی را حفظ می‌کند؛ compose معمولی یک پایگاه دادهٔ خالی می‌ساخت. در .env متغیر اختیاری با تگ ایمیج را اضافه کنید:

XLADA_VERSION=latest

اجرا:

docker compose -f docker-compose.migrate-from-remnawave.yml up -d
docker logs -f remnawave

مهاجرت‌ها هنگام راه‌اندازی کانتینر به‌صورت خودکار اعمال می‌شوند: entrypoint دستورهای prisma migrate deploy و prisma db seed را اجرا می‌کند. در لاگ منتظر خطوط Migrations deployed successfully! و Nest application successfully started بمانید.

خودکارسازی

همین گام‌ها را اسکریپت migrate-to-xlada.sh انجام می‌دهد: پشتیبان، .env، فایل compose و فهرست والیوم‌ها را در backups/<تاریخ-زمان>/ می‌گذارد، پشتیبان را از نظر کامل بودن بررسی می‌کند، استک را بدون -v متوقف می‌کند و XLADA را بالا می‌آورد.

بررسی​

# پنل پاسخ می‌دهد
curl -s -o /dev/null -w '%{http_code}\n' https://panel.example.com/api/auth/status

# پایگاه داده کاربران را می‌بیند — تعداد پیش و پس باید یکسان باشد
docker exec remnawave-db psql -U "$POSTGRES_USER" -d "$POSTGRES_DB" -tAc "SELECT count(*) FROM users;"

# مهاجرت‌ها اعمال شدند
docker exec remnawave-db psql -U "$POSTGRES_USER" -d "$POSTGRES_DB" -c \
'SELECT migration_name FROM _prisma_migrations ORDER BY finished_at DESC LIMIT 5;'

در فهرست مهاجرت‌ها باید 20260912120000_add_admin_audit_log و 20260912130000_add_admin_totp باشند. سپس با همان اطلاعات ورود مدیر قبلی وارد پنل شوید و بررسی کنید که نودها در صفحهٔ Nodes متصل هستند.

کارهایی که نباید انجام داد​

خطر
  • docker compose down -v — پرچم -v والیوم را همراه با پایگاه داده حذف می‌کند. این تنها دستوری است که واقعاً کاربران را نابود می‌کند.
  • تغییر APP_SECRET — هش رمزهای عبور، امضای JWT و رمزنگاری اسرار TOTP به آن وابسته‌اند. پس از تغییر، هیچ‌کس نمی‌تواند وارد پنل شود.
  • تغییر نام والیوم‌ها، سرویس‌ها و شبکه‌ها — compose نمونه‌های خالی جدید می‌سازد و قدیمی‌ها کنار همان می‌مانند. DATABASE_URL به هاست remnawave-db اشاره می‌کند.
  • بالا بردن نسخهٔ ماژور PostgreSQL روی والیوم موجود و ویرایش مهاجرت‌های اعمال‌شده — Prisma چک‌سام‌ها را در _prisma_migrations تطبیق می‌دهد.

پشتیبان و نسخهٔ پشتیبان .env را حذف نکنید تا مطمئن شوید ورود، نودها و اشتراک‌ها کار می‌کنند.

گام بعدی​