داده‌های آنالیتیکس‌تان را مالک شوید: خودمیزبان در برابر SaaS خصوصی اروپایی در 2026

آنالیتیکس وب خودمیزبان در 2026 یک بازنگری است، نه یک انتخاب حاشیه‌ای

تقریباً در تمام دههٔ گذشته، «آنالیتیکس خودمیزبان» موضعی بود که از سرِ اعتقاد می‌گرفتید؛ یک پرچم Plausible یا Matomo که در برابر پیش‌فرض GA4 می‌کاشتید. اما در 2026 ماجرا چیز دیگری است: قانون داده کمیسیون اروپا (Data Act) که از 12 سپتامبر 2025 اجرایی شده، صراحتاً قفل‌شدن مشتری به فروشندهٔ SaaS از طریق قالب‌های ذخیره‌سازی انحصاری را ممنوع کرده است. علاوه بر این، یک خروج عمومی و مستند از SaaS در جریان است؛ کسب‌وکارهای اروپایی بارِ کاری خود را از پلتفرم‌های ابریِ زیر کنترل آمریکا به خانه برمی‌گردانند؛ به تعبیر MassiveGRID، «تولیدکنندگان Mittelstand آلمان، نهادهای دولتی فرانسه، ارائه‌دهندگان خدمات درمانی هلند». رصدِ صنعتی حالا حاکمیت داده را این‌طور توصیف می‌کند: «یک پاسخ عمل‌گرایانه به فشار قانونی، واقعیت سیاسی، و این درک روزافزون که حاکمیت داده دیگر اختیاری نیست.»

Statnive Live در دو شکل عرضه می‌شود: یک باینری Go که خودتان به‌صورت خودمیزبان اجرا می‌کنید، و یک SaaS خصوصی اروپایی در نورنبرگ. این نوشته نسخهٔ صادقانهٔ پرسشی است که هر گردانندهٔ حریم‌خصوصی‌محوری امروز باید به آن پاسخ دهد: کدام یک واقعاً به من می‌خورد؟ هرجا این نوشته ادعایی قانونی یا محصولی مطرح کند، یک منبع پانوشت‌شده پیدا می‌کنید؛ و هرجا یک سبک‌سنگین واقعی در کار باشد، آن سبک‌سنگین را به‌اسم می‌آوریم.

این سومین مقاله از یک سری کوتاه برای معرفی Statnive Live است. مقالهٔ اول تصمیم بین افزونهٔ وردپرس و Statnive Live را گام‌به‌گام بررسی کرد؛ مقالهٔ دوم چشم‌انداز قانونی اتحادیه اروپا در 2026 را پوشش داد. این یکی دربارهٔ شکل استقرار است؛ کنترل‌کننده در برابر پردازنده، شعاع انفجار، و مدل تهدید در هر سو.

خودمیزبانی دقیقاً از چه چیزی محافظت‌تان می‌کند

خودمیزبانی پنج تهدید رایجِ آنالیتیکس SaaS را در یک سرور که از قبل مال خودتان است جمع می‌کند:

1. ورشکستگی فروشنده، تغییر مسیر او، یا تغییر دلبخواهی قیمت. SmartSaaS و Sharp Hue این را ریسک کلاسیک SaaS می‌دانند؛ اگر مجموعهٔ آنالیتیکس شما روی سرور یک نفر دیگر زندگی کند، داده‌های تاریخی‌تان هم روی نقشهٔ راه آن نفر زندگی می‌کند.
2. خریداری‌شدن فروشنده. مالکان جدید می‌توانند سیاست حریم خصوصی را عوض کنند، قیمت را بالا ببرند، یا شما را به مهاجرت اجباری به پلتفرم دیگری وادار کنند. J. Chang Law سویهٔ قراردادی این دعواها را رصد می‌کند.
3. در معرض نشت داده قرار گرفتن فروشنده. وقتی داده‌های بازدیدکننده در یک SaaS چندمستأجری بنشیند، هر نشتی نزد فروشنده، نشت داده‌های شما هم هست (چارچوب Kiteworks). خودمیزبانی شعاع انفجار را به سرور خودتان محدود می‌کند.
4. ریسک انتقال فرامرزی. میزبانی بیرون از منطقه اقتصادی اروپا (EEA) فصل پنجم GDPR (مواد 44 تا 49) را فعال می‌کند. تمیزترین پاسخ این است که داخل EEA بمانید؛ برای استدلال قانونی، مقالهٔ دوم این سری را ببینید.
5. افشای اجباری به‌دستور رگولاتور. CLOUD Act آمریکا به‌علاوهٔ FISA 702 به هر داده‌ای که یک ارائه‌دهندهٔ ثبت‌شده در آمریکا کنترلش می‌کند دست می‌یابند، فارغ از این‌که آن داده فیزیکاً کجا قرار دارد. به تعبیر Civo: «ذخیرهٔ داده در فرانکفورت یا دوبلین آن را از دسترس مجریان قانون آمریکا خارج نمی‌کند. اگر ارائه‌دهنده یک شرکت آمریکایی باشد، مقامات آمریکا می‌توانند دسترسی به هر داده‌ای را که آن شرکت کنترل می‌کند، هرجا که ذخیره شده باشد، الزام کنند.» قرار بود FISA 702 در آوریل 2026 منقضی شود و در زمان نگارش این متن، فشار برای تمدیدش هم در جریان بود؛ دامنهٔ پس از تمدید نشان خواهد داد که تصویر عوض می‌شود یا نه، اما پاسخ معماری به آن وابسته نیست.

یک باینری خودمیزبان روی زیرساختِ زیر کنترل گرداننده که یک نهاد حقوقیِ غیرآمریکایی اجرایش می‌کند، هر پنج تهدید را در یک مسئله که گرداننده از قبل آن را مدیریت می‌کند جمع می‌کند: سرور خودش.

خودمیزبانی از چه چیزی محافظت‌تان نمی‌کند

این هم فهرست همراهِ صادقانه. خودمیزبانی ریسک را جابه‌جا می‌کند؛ آن را حذف نمی‌کند. چهار چیز همچنان مسئلهٔ خودتان می‌ماند:

به‌خطرافتادن سرور خودتان. سیستم‌عامل میزبان، ClickHouse، باینری Go، شبکه؛ همهٔ این‌ها حالا داخل شعاع انفجار شما می‌نشینند. اگر وضعیت مدیریت سیستم‌تان ضعیف باشد، خودمیزبانی می‌تواند اوضاع را بدتر کند، نه بهتر. چارچوب Slimstat / TeamUpdraft که خودمیزبانی را به‌عنوان بارِ سرور می‌بیند، همین سبک‌سنگین را این‌بار از زاویهٔ عملکرد روایت می‌کند.

ازدست‌رفتن کلید رمزنگاری. دیسک‌های رمزنگاری‌شده با LUKS و پشتیبان‌های رمزنگاری‌شده با age تا وقتی کلیدها وجود دارند کار می‌کنند. آن‌ها را گم کنید و داده رفته است؛ درست مثل یک کلید SSH یا کیف‌پول بیت‌کوین. ما داستان بازیابی LUKS را در docs/luks.md مستند کرده‌ایم؛ بقیه‌اش مسئلهٔ مدیر رمزهای عبور شماست.

ریسک درون‌سازمانی در تیم خودتان. یک مدیر بدخواه یا سهل‌انگار می‌تواند رویدادهای خام را پیش از هش‌شدن بخواند، جدول‌ها را حذف کند، یا گزارش‌های حسابرسی را برباید. سیستم نقش‌محور دسترسی (RBAC) با نقش‌های مدیر / بیننده / فقط-API به تفکیک حوزه‌ها کمک می‌کند؛ ریسک باقی‌مانده مال خودتان است.

خطای گرداننده. حذف داده، پیکربندی نادرست پشتیبان‌ها، رهاکردن داشبورد به‌صورت کاملاً باز. همان تمرین بازیابی-در-هر-انتشار که در برابر نشت دفاع می‌کند، در برابر خطای گرداننده هم دفاع می‌کند؛ اما فقط اگر واقعاً آن را اجرا کرده باشید.

اگر این چهار مورد همچنان برایتان از فهرستِ بالاییِ فروشندهٔ SaaS قابل‌قبول‌تر است، خودمیزبانی کنید. اگر نه، مسیر SaaS خصوصی اروپایی بیشترشان را پوشش می‌دهد و در عین حال داستان اقامت داده فقط در اروپا را هم سالم نگه می‌دارد.

معماری تک‌باینری

هر دو مسیر همان باینری Go را روی همان اسکیمای ClickHouse اجرا می‌کنند. هیچ انشعابی نیست، هیچ پایگاه کد دومی نیست. همهٔ دارایی‌ها؛ اسکریپت آماری ردیاب، داشبورد SPA، مهاجرت‌های ClickHouse، و وابستگی‌های Go که داخل پروژه آورده شده‌اند، همگی از طریق go:embed تعبیه شده‌اند. نه CDN خارجی، نه npm install در زمان اجرا، نه go mod download در زمان اجرا.

ایزولهٔ کامل از شبکه (Air-gap) یک هدف غیرقابل‌مذاکرهٔ پروژه است، نه یک آرزو. باینری باید بتواند به‌صورت کاملاً ایزوله زیر iptables -P OUTPUT DROP و با صفر اتصال خروجیِ لازم اجرا شود. دروازهٔ انتشار، آزمون ایزولهٔ شبکه را در هر انتشار اجرا می‌کند: رویدادها وارد می‌شوند، تجمیع‌ها ساخته می‌شوند، داشبورد رندر می‌شود، همه زیر همان قطع iptables. ترافیک خروجیِ ویژگی‌های اختیاری (مثلاً به‌روزرسانی اختیاری پایگاه دادهٔ GeoIP) از مسیر internal/httpclient/guarded.go عبور می‌کند؛ فهرست مجازِ FQDN، رد کردن آدرس‌های RFC-1918 / loopback / CGNAT پس از تحلیل DNS، و اجبارِ HTTPS. فهرست مجازِ پیش‌فرض خالی است.

در CI، قاعدهٔ air-gap-validator ساخت خامِ *http.Client، DNS/HTTP در زمان اجرا، واردکردن CDN در داشبورد یا ردیاب، پینگ‌های تله‌متری، و آدرس‌های خارجیِ فونت و اسکریپت را رد می‌کند. این قرارداد را هم بازبینی کد و هم Semgrep تضمین می‌کنند، نه یک سیاههٔ کنترل.

دفاع لایه‌لایه؛ ادعاهای مشخص

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

• هویت بازدیدکننده: HMAC(master_secret, site_id || YYYY-MM-DD)، کلید-شده با BLAKE3، درون‌فرایندی مشتق می‌شود، هرگز ذخیره نمی‌شود، و روزانه می‌چرخد. همان بازدیدکننده ← هر روز یک هش متفاوت. در ClickHouse به‌صورت FixedString(16) ذخیره می‌شود (BLAKE3-128 بریده‌شده به 16 بایت). SHA-256 و BLAKE3 تنها خانواده‌های هشِ موجود در هر جای این باینری‌اند؛ نه MD5، نه SHA-1.
• احراز هویت داشبورد: هش رمز عبور با bcrypt هزینهٔ 12، توکن‌های نشستِ 32 بایتیِ crypto/rand (256 بیت، رمزگذاری‌شده با hex)، طول عمر 14 روز، کوکی‌های SameSite=Lax HttpOnly Secure. هزینهٔ 12 در bcrypt روی هر ماشینی که اجرایش کند حدود 50 میلی‌ثانیه یا بیشتر زمان می‌برد؛ و دقیقاً همین هدف است.
• گزارش حسابرسی: JSONL از طریق slog گو، فقط افزایشی، در نسخهٔ v1 فقط با خروجی فایل، با انضباط chattr +a و logrotate copytruncate=off. خروجی Syslog و سینک‌های راه دور به v1.1 موکول شده‌اند؛ همین کار، پیش‌فرض ایزولهٔ شبکه را حفظ می‌کند.
• رمزنگاری در حالت سکون: LUKS2 با aes-xts-plain64، اندازهٔ کلید 512، تابع argon2id به‌عنوان PBKDF، و iter-time 2000. روی VPS ابریِ چندمستأجری الزامی است (از جمله Netcup VPS 2000 G12 NUE D1)؛ روی سخت‌افزار اختصاصیِ قفسه‌ای اختیاری است. افت ورودی/خروجیِ اندازه‌گیری‌شده روی ext4-روی-LUKS1 حدود 40 تا 50% است؛ AES-NI به‌علاوهٔ AVX2 آن را نصف می‌کند.
• پشتیبان‌های رمزنگاری‌شده: clickhouse-backup به‌علاوهٔ age و zstd، زمان‌بندی‌شده با cron. آزمونِ بازیابی در هر انتشار. برای SaaS، پشتیبان‌ها به یک مکان دومِ فقط-اروپایی فرستاده می‌شوند؛ برای خودمیزبان، انتخاب مکان با گرداننده است.
• سخت‌سازی systemd: NoNewPrivileges، ProtectSystem=strict، PrivateTmp، CapabilityBoundingSet=CAP_NET_BIND_SERVICE. یونیت سرویس در کنار قواعد iptables برای ایزولهٔ شبکه از طریق make airgap-bundle عرضه می‌شود.
• اتصال‌کوتاهِ Sec-GPC: وقتی Sec-GPC: 1 یا DNT: 1 تنظیم شده باشد، درخواست پیش از محاسبهٔ شناسهٔ بازدیدکننده حذف می‌شود. برای بازدیدکننده‌ای که اجازه نمی‌دهد هیچ شناسهٔ مستعاری ساخته نمی‌شود؛ چیزی برای حذف وجود ندارد، چون چیزی ساخته نشده است.

چه زمانی خودمیزبانی کنیم و چه زمانی SaaS خصوصی اروپایی را برداریم

پنج عامل واقعاً این تصمیم را می‌گیرند. بیشتر خواننده‌ها خیلی زود خودشان را در یکی از ستون‌ها می‌بینند.

1. نیروی عملیاتی. خودمیزبانی زمانِ عملیات می‌خواهد. گرداننده مالکِ چرخش TLS، نصب به‌روزرسانی‌های پایگاه دادهٔ GeoIP، ارتقاهای ClickHouse، وصله‌های هسته، و عبارت عبور LUKS است. اگر کسی را ندارید که شغلش از قبل شامل یک سرور لینوکس باشد، SaaS را انتخاب کنید.

2. حجم ترافیک. سقفِ طراحی Statnive Live برابر 200 میلیون رویداد در روز به ازای هر گره روی یک ماشین 8 هسته‌ای / 32 گیگابایتی است. زیر حدود 10 میلیون رویداد در روز هر دو مسیر یکسان کار می‌کنند؛ بالای حدود 50 میلیون رویداد در روز، پختگیِ عملیاتیِ لازم برای خودمیزبانی کم‌کم به‌خودیِ‌خود معقول به نظر می‌رسد.

3. وضعیت حسابرسی و انطباق. صنایع مقررات‌گذاری‌شده اغلب هم یک قرارداد پردازش داده (DPA) امضاشده مطابق مادهٔ 28(3) لازم دارند و هم زیرساختی که خودشان هدایتش کنند. مسیر SaaS خصوصی نیمهٔ DPA را پوشش می‌دهد؛ خودمیزبانی هر دو نیمه را پوشش می‌دهد، اما بارِ عملیاتی را روی دوش تیم شما می‌گذارد.

4. جغرافیا. SaaS در نورنبرگ آلمان پردازش می‌شود (Netcup VPS 2000 G12 NUE)؛ فقط اتحادیه اروپا و EEA، بدون انتقالِ فصل پنجم. خودمیزبانی داده را هرجا که سرورتان باشد می‌گذارد. قواعد اقامت داده مختصِ کشور (FADP سوئیس، تدارکات بخش عمومی آلمان) گاهی یک شهر مشخص را لازم دارند؛ تنها خودمیزبانی این سطح از کنترل را به شما می‌دهد.

5. هزینه در مقیاس. SaaS بر اساس ترافیک قیمت‌گذاری می‌شود (پلن‌های Starter / Growth / Business از 9 تا 339 دلار در ماه در میان تعرفه‌های منتشرشده؛ Enterprise بالاتر). خودمیزبانی، صورت‌حساب SaaS را با یک Hetzner CX43 (حدود €14 در ماه) یا Netcup VPS 2000 G12 (€25.48 در ماه ماهانه) به‌علاوهٔ زمانِ گرداننده عوض می‌کند. در ترافیک پایین، SaaS در هزینهٔ کل مالکیت برنده است؛ در ترافیک خیلی بالا، خودمیزبانی برنده است.

اگر سه عامل یا بیشتر به یک سمت متمایل شوند، همان جواب شماست. اگر تقسیم شدند، برای 6 ماه اول پیش‌فرض را SaaS بگذارید؛ بعداً می‌توانید بدون از دست دادن داده به خودمیزبانی بروید، چون باینری و اسکیما یکی‌اند.

میانه‌راهِ «SaaS خصوصی»

یک نکتهٔ دقیق دربارهٔ این‌که «خصوصی» در این زمینه چه معنایی دارد. SaaSِ Statnive Live از نظر منطقی به‌تفکیک مستأجر ایزوله شده است؛ هر ردیف رویداد یک site_id حمل می‌کند، هر پرس‌وجوی داشبورد از مسیر whereTimeAndTenant() با WHERE site_id = ? به‌عنوان نخستین گزاره عبور می‌کند، و یک قاعدهٔ گلوگاهِ مستأجری در CI هر پرس‌وجوی جدیدی را که از آن دور بزند رد می‌کند. این به معنای تک‌مستأجریِ فیزیکی نیست؛ یک خوشهٔ ClickHouse به همهٔ مشتری‌ها سرویس می‌دهد. مشتری‌هایی که تک‌مستأجریِ فیزیکی می‌خواهند مسیر خودمیزبانی را برمی‌دارند.

اما SaaS این‌ها را به‌صورت آماده عرضه می‌کند:

• قرارداد پردازش داده (DPA) مطابق مادهٔ 28(3) روی هر پلن (از جمله رایگان)، امضاشده با تاریخ 2026-04-24. این DPA هر هشت زیربندِ مادهٔ 28(3) را پوشش می‌دهد؛ فقط بر اساس دستورات، رازداری، امنیت مادهٔ 32، مجوز پردازندهٔ فرعی، کمک به حقوق صاحب داده، کمک به تعهدات کنترل‌کننده برای مواد 32 تا 36، حذف یا بازگرداندن داده هنگام خاتمه، و حقوق حسابرسی.
• فهرست پردازنده‌های فرعی، ظرف 7 روز از هر تغییر بالادستی به‌روز می‌شود، با 14 روز اعلان پیشاپیش به مشتری‌ها از طریق صفحهٔ حریم خصوصی؛ مشتری می‌تواند در همان بازه به‌صورت کتبی اعتراض کند.
• پنجرهٔ 30 روزهٔ خروجی‌گیری مشتری هنگام خاتمه؛ خروجی کامل CSV/JSON از طریق نقطه پایانیِ استانداردِ خروجی. پس از 30 روز، جدول‌های خام، جدول‌های تجمیع، پشتیبان‌ها (چرخهٔ پشتیبان بعدی، حداکثر ظرف 24 ساعت)، و گزارش‌های حسابرسی حذف می‌شوند، مگر جایی که قانون اتحادیه یا کشورهای عضو نگهداری را الزام کند.
• توافق سطح خدمات 48 ساعته برای اعلان نشت از لحظهٔ آگاهی، هم‌سو با مادهٔ 33 GDPR.
• پردازش فقط در اتحادیه اروپا و EEA. هیچ انتقالِ فصل پنجمی از داده‌های شخصیِ ذخیره‌شده به بیرون از EEA انجام نمی‌شود. دو پردازندهٔ فرعیِ مقیمِ آمریکا که در این زنجیره ظاهر می‌شوند؛ Cloudflare فقط برای DNS و Let’s Encrypt برای گواهی‌های DV، در بند 6 از DPA زیر کفایتِ DPF افشا شده‌اند. آن‌ها فقط فراداده‌ی DNS و فراداده‌ی گواهی را دریافت می‌کنند، نه هرگز محتوای کاربردی را.

آن بند آخر، پاسخِ بارِ اصلیِ پرسش CLOUD Act / FISA 702 است. «هیچ طرفِ ثبت‌شده در آمریکا در زنجیرهٔ پردازش نیست» نسخهٔ سفت‌وسخت ماجراست، و همان چیزی است که Civo و SoftwareSeni در منابع بالا برایش استدلال می‌کنند. «گفتن فرانکفورت یا دوبلین یک ارائه‌دهندهٔ آمریکایی را حاکمیت‌دار نمی‌کند» همان چیزی است که معماری باید واقعاً پاسخش را بدهد؛ و «اجراشده به دست یک مشتریِ مقیم آلمان از یک نهاد حقوقیِ آلمانی روی زیرساخت در نورنبرگ» همان پاسخ است.

مسیر مهاجرت میان این دو

این بخش کوتاه است، چون عمداً بی‌حادثه طراحی شده.

همان باینری، همان اسکیما. مهاجرت‌ها در clickhouse/migrations/ زندگی می‌کنند و از روز اول از قالب‌های گوی {{if .Cluster}} استفاده می‌کنند؛ گذار از تک‌گره به Distributed یک تغییر پیکربندی است، نه مهاجرت به پلتفرم دیگر.

بدون قفل‌شدن داده. ClickHouse از قالب‌های باینریِ استاندارد (Parquet / Native / RowBinary) به‌علاوهٔ قالب آرشیوِ clickhouse-backup استفاده می‌کند. مهاجرت از Statnive Live به ClickHouse Cloud یا یک خوشهٔ خود-مدیریت، یک بازیابیِ clickhouse-backup است، نه یک واردکردنِ دوباره.

خروجی‌گیری و حذف در محدودهٔ بازدیدکننده. GET /api/privacy/access ردیف‌های گره‌خورده به کوکی روی سایتِ تشخیص‌داده‌شده را برمی‌گرداند (مادهٔ 15)؛ POST /api/privacy/erase نقطه پایانیِ حذفِ متناظر است (مادهٔ 17). مسیر حذف، system.columns را به‌صورت پویا شمارش می‌کند، بنابراین هر جدول جدیدی که یک cookie_id حمل کند خودبه‌خود در محدوده قرار می‌گیرد؛ و عبارت WHERE برابر cookie_id = ? AND site_id = ? است، پس یک درخواست حذف روی یک سایت هرگز نمی‌تواند به ردیف‌های مستأجری دیگر برسد. DSAR از روز اول، نه چیزی که بعداً سرِهم شده باشد.

اگر روی SaaS خصوصی شروع کنید و بعداً بخواهید خودمیزبانی کنید، باینری به‌علاوهٔ یک آرشیوِ clickhouse-backup از داده‌هایتان را درخواست کنید. خط لولهٔ انتشار یک statnive-live-<VERSION>-linux-amd64-airgap.tar.gz بازتولیدپذیر به‌علاوهٔ SHA256SUMS (و یک امضای اختیاریِ Ed25519) می‌سازد؛ تاربال را کپی می‌کنید، با clickhouse-backup restore داده‌هایتان را بازمی‌گردانید، و همان داشبورد را روی همان اسکیما اجرا می‌کنید، فقط این‌بار روی سخت‌افزار خودتان.

پرسش‌های رایج

اگر Statnive Live تعطیل شود چه می‌شود؟

همان باینری را دارید و به اجرایش ادامه می‌دهید. مشتری‌های خودمیزبان از قبل آن را دارند. مشتری‌های SaaS می‌توانند هنگام خروج، باینری به‌علاوهٔ یک آرشیوِ clickhouse-backup از داده‌هایشان را درخواست کنند. خط لولهٔ انتشار یک بستهٔ ایزولهٔ شبکهٔ بازتولیدپذیر با مجموع‌های SHA256 می‌سازد؛ هیچ‌چیز از این به ادامهٔ فعالیت Statnive وابسته نیست.

می‌توانم داده‌ام را به ClickHouse Cloud منتقل کنم؟

بله. داده در قالب استاندارد ClickHouse است؛ clickhouse-backup restore روی یک مقصد ClickHouse Cloud مسیر پشتیبانی‌شده است. اگر می‌خواهید داده را با ابزار کاملاً دیگری استفاده کنید، نقطه پایانیِ خروجی، CSV/JSON تولید می‌کند.

آیا CI من می‌تواند روی یک نمونهٔ Statnive اجرا شود؟

بله. make ci-local ClickHouse را بالا می‌آورد، باینری Go را بالا می‌آورد، آزمون‌های یکپارچگی را اجرا می‌کند، و همه‌چیز را پایین می‌آورد. اجراکنندهٔ CIِ هر PR از قبل همین کار را می‌کند؛ همان تمرینی است که خودتان به‌صورت محلی استفاده می‌کنید.

پشتیبان‌های رمزنگاری‌شده را کجا نگه دارم؟

در خودمیزبان انتخاب با گرداننده است؛ هر فضای ذخیره‌سازیِ سازگار با S3، هر دیسک راه دور، هر نوار. برای SaaS، یک مکان دومِ فقط-اروپایی پاسخ قراردادی است. بازیابی، فارغ از این‌که پشتیبان‌ها کجا فرود بیایند، در هر انتشار آزموده می‌شود.

CLOUD Act / FISA 702؛ آیا نورنبرگ کمک می‌کند؟

بله، وقتی ارائه‌دهنده هم زیر کنترل آمریکا نباشد. SaaSِ Statnive Live را یک مشتریِ مقیم آلمان از Netcup (یک نهاد حقوقیِ آلمانی) روی زیرساخت Netcup در نورنبرگ اجرا می‌کند. هیچ طرفِ ثبت‌شده در آمریکا در زنجیرهٔ پردازش نیست ← هیچ دسترسیِ CLOUD Act / FISA 702 روی محتوای کاربردی وجود ندارد. دو پردازندهٔ فرعیِ مقیمِ آمریکا زیر کفایتِ DPF ظاهر می‌شوند؛ Cloudflare فقط برای DNS و Let’s Encrypt، که فقط فراداده‌ی DNS و فراداده‌ی گواهی را دریافت می‌کنند. این سطحی متفاوت از «دیتابیس روی AWS-فرانکفورت زندگی می‌کند» است.

بازیابی پس از فاجعه چطور؟

همان آزمونِ بازیابی در هر انتشار، روی همان قالبِ پشتیبانِ رمزنگاری‌شده اجرا می‌شود؛ رمزنگاری‌شده با age، فشرده‌شده با zstd، آرشیوِ clickhouse-backup. ما همچنین مسیر بازیابی LUKS را در docs/luks.md برای لایهٔ رمزنگاری در حالت سکون مستند کرده‌ایم. هیچ جادویی در کار نیست؛ یک تمرین در کار است که واقعاً اجرا شده.

جمع‌بندی نهایی

خودمیزبانی در 2026 یک پرچم‌کاشتن نیست؛ تمیزترین پاسخ به یک روند قابل‌اندازه‌گیری در فشار قانونی و تدارکاتی اتحادیه اروپاست. Statnive Live همان باینری Go به‌علاوهٔ همان اسکیمای ClickHouse را در دو شکل عرضه می‌کند: خودمیزبان، که همهٔ مسئولیت عملیاتی را به دوش می‌کشید و ریسک‌های فروشندهٔ SaaS را از دست می‌دهید؛ و SaaS خصوصی اروپایی در نورنبرگ، که در آن یک DPA مطابق مادهٔ 28(3)، اقامت داده فقط در اروپا، و یک توافق سطح خدمات 7 روزه برای پردازندهٔ فرعی می‌گیرید، اما شعاع انفجار چندمستأجری را هم که معماری برای مهارش طراحی شده.

مسیری را انتخاب کنید که با نیروی عملیاتی، ترافیک، و وضعیت حسابرسی‌تان جور باشد. اگر مردد هستید، روی SaaS شروع کنید؛ مهاجرت به خودمیزبانی فقط یک بازیابیِ clickhouse-backup فاصله دارد.

Statnive Live به‌زودی روی statnive.com/live می‌آید. تا آن زمان، افزونهٔ وردپرس روی WordPress.org قرار دارد، مقالهٔ مقایسه درخت تصمیمِ وردپرس در برابر Live را گام‌به‌گام بررسی می‌کند، راهنمای GDPR سویهٔ قانونی را پوشش می‌دهد، و صفحهٔ قیمت‌گذاری هر دو محصول را کنار هم می‌چیند. اگر به‌طور مشخص دنبال مقایسهٔ جایگزین‌های GA هستید، آن جمع‌بندیِ رتبه‌بندی‌شده هفت جایگزین حریم‌خصوصی‌محور را با یادداشت‌هایی دربارهٔ یکپارچگی با وردپرس پوشش می‌دهد. اگر معلوم شد یک واقعیت در این نوشته اشتباه است، برای من بنویسید؛ هر ادعا یک پانوشت دارد، و ما ترجیح می‌دهیم یکی را اصلاح کنیم تا این‌که یک نیمه‌حقیقتِ صیقل‌خورده عرضه کنیم.