VPS पर Matrix Synapse कैसे host और manage करें

Matrix Synapse homeserver को चालू रखने के लिए आवश्यक चीजें

Matrix Synapse को install करना आसान है और इसे नजरअंदाज करना भी उतना ही आसान। इसका installation केवल एक apt repository, एक config file, एक reverse proxy block और एक DNS record का काम है। एक साल तक homeserver को स्वस्थ बनाए रखना एक अलग तरह का काम है: इसमें एक वास्तविक database, media store जिसे समय-समय पर prune किया जाए, registration जिसे अनजान लोग इस्तेमाल न कर सकें, और एक ऐसा backup जो सर्वर के दोनों हिस्सों को सुरक्षित रखे, शामिल हैं।

यह guide Ubuntu 24.04 LTS को लक्षित करती है और Synapse को matrix.org apt repository से install करती है, जो कि वह package source है जिसे Synapse project, Debian और Ubuntu के लिए maintain करता है। Package versions हर कुछ हफ्तों में बदलते रहते हैं, इसलिए यहाँ किसी version number का उल्लेख नहीं किया गया है। नीचे दिए गए सभी paths और options वर्तमान Synapse documentation से लिए गए हैं।

Sizing: 1 vCPU और 2 GB RAM वास्तव में आपको क्या प्रदान करते हैं

अगस्त 2026 तक प्रकाशित Sizing पृष्ठ, आमतौर पर Synapse homeserver के लिए 1 vCPU और 2 GB RAM का सुझाव देते हैं। यह एक स्थिति के लिए सही है: एक निजी सर्वर, कुछ उपयोगकर्ता, छोटे rooms और कोई व्यस्त public room न होना। Synapse documentation अन्य स्थितियों के बारे में स्पष्ट है। यह कहता है: "यदि आप #matrix:matrix.org जैसे बड़े public rooms में शामिल होना चाहते हैं, तो कम से कम 1GB free RAM की आवश्यकता है।" यह free RAM, Python, Postgres और kernel के उपयोग के अतिरिक्त होनी चाहिए।

एक single room आपकी sizing बदल सकता है, क्योंकि joining की प्रक्रिया इसी तरह काम करती है। जब कोई local user किसी room में शामिल होता है, तो आपका homeserver उस room का पूर्ण भागीदार बन जाता है। यह उस room के हर अन्य सर्वर से आने वाले हर event को प्राप्त करता है, प्रत्येक के signature को verify करता है, और room की state को स्थानीय रूप से store करता है। एक बड़े public room में सैकड़ों सर्वरों पर फैले हजारों सदस्य होते हैं, इसलिए आपका सर्वर यह काम लगातार करता रहता है, चाहे आपका उपयोगकर्ता उस room को दोबारा खोले या न खोले। बाद में room छोड़ने से वह history delete नहीं होती जिसे आप पहले ही store कर चुके हैं।

Synapse की अधिकांश RAM caches में जाती है। caches section में एक global_factor है जो एक साथ सभी caches को scale करता है, और SYNAPSE_CACHE_FACTOR environment variable भी यही काम करता है। इसे बढ़ाने पर database queries से बचने के लिए RAM का उपयोग होता है। इसे घटाने पर RAM बचाने के लिए CPU और Postgres के समय का उपयोग होता है। Postgres को अपनी अलग memory चाहिए होती है, इसलिए 2 GB वाले सर्वर पर ये दोनों एक ही megabytes के लिए प्रतिस्पर्धा करते हैं।

छोटे plan के लिए दो व्यावहारिक नियम हैं। Swap जोड़ें: swap से Synapse तेज़ नहीं होगा, लेकिन यह बड़े join के दौरान kernel को process को kill करने से रोकता है। फिर पहले सप्ताह से ही disk पर नज़र रखें, क्योंकि media store और room state tables ही वे दो चीजें हैं जो बिना किसी सीमा के बढ़ती हैं, और दोनों disk पर ही रहती हैं।

Postgres क्यों चुनें, और SQLite एक विकल्प क्यों नहीं रह जाता

Debian पैकेज SQLite पर शुरू होता है। यह पहली बार बूट करने के लिए ठीक है, लेकिन उन सर्वर के लिए गलत है जिनका उपयोग अन्य लोग करते हैं। SQLite एक समय में केवल एक राइटर (writer) की अनुमति देता है। फेडरेशन ट्रैफिक और क्लाइंट रिक्वेस्ट एक ही समय पर डेटा लिखते हैं, इसलिए एक सस्ती रिक्वेस्ट एक धीमी रिक्वेस्ट के पीछे प्रतीक्षा करती है, और आपके उपयोगकर्ता यह रिपोर्ट करते हैं कि ऐप कुछ सेकंड के लिए अचानक हैंग हो जाता है।

दूसरा कारण संरचनात्मक है। Synapse की वर्कर प्रोसेस एक से अधिक CPU कोर का उपयोग करने का समर्थित तरीका है, और वर्कर के लिए Postgres की आवश्यकता होती है। SQLite पर बने रहने का मतलब है कि आप अपग्रेड पाथ और प्रदर्शन दोनों को खो देते हैं।

बाद में माइग्रेट करना समर्थित है और इसमें डाउनटाइम शामिल है, इसलिए इसे तब करें जब आपके पास उपयोगकर्ता न हों। Synapse में synapse_port_db शामिल है, जो एक SQLite डेटाबेस को एक तैयार Postgres डेटाबेस में कॉपी करता है:

synapse_port_db --sqlite-database homeserver.db --postgres-config homeserver-postgres.yaml

यदि आप डेटाबेस को Synapse के साथ एक कंटेनर में चलाना पसंद करते हैं, तो इसके फायदे और नुकसान Docker में या होस्ट पर अपना डेटाबेस चलाना में दिए गए हैं।

Ubuntu 24.04 पर Synapse इंस्टॉल करना

sudo apt install -y lsb-release wget apt-transport-https
sudo wget -O /usr/share/keyrings/matrix-org-archive-keyring.gpg https://packages.matrix.org/debian/matrix-org-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/matrix-org-archive-keyring.gpg] https://packages.matrix.org/debian/ $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/matrix-org.list
sudo apt update
sudo apt install matrix-synapse-py3

Ubuntu 24.04 पर lsb_release -cs कमांड noble आउटपुट देती है, और matrix.org रिपॉजिटरी एक noble सुइट प्रकाशित करती है। Ubuntu के अपने आर्काइव से matrix-synapse पैकेज का उपयोग न करें। Synapse प्रोजेक्ट आपसे ऐसा न करने का आग्रह करता है, क्योंकि वे बिल्ड इसके releases से पीछे रहते हैं और उनमें ज्ञात security bugs होते हैं।

इंस्टॉलर आपसे एक server name मांगता है और उत्तर को /etc/matrix-synapse/conf.d/server_name.yaml में लिखता है। इसका उत्तर सावधानीपूर्वक दें। server_name प्रत्येक user ID (@alice:example.com) में कोलन के बाद का हिस्सा होता है और यह आपके सर्वर द्वारा बनाए गए प्रत्येक room में एम्बेडेड होता है। इसे बाद में बदलने से कोई डेटा माइग्रेट नहीं होता: यह एक अलग homeserver बना देता है। अपने bare domain, example.com का उपयोग करें, भले ही Synapse स्वयं matrix.example.com पर चले। Delegation इन दोनों को जोड़ता है, और वह अगला सेक्शन है।

यह पैकेज Synapse को matrix-synapse यूजर के रूप में चलाता है, इसके डेटा को /var/lib/matrix-synapse के अंतर्गत रखता है, और /etc/matrix-synapse/homeserver.yaml के बाद /etc/matrix-synapse/conf.d/ में मौजूद प्रत्येक फाइल को पढ़ता है। अपनी सेटिंग्स को conf.d में छोटी फाइलों के रूप में रखें। पैकेज अपग्रेड के दौरान इन्हें नहीं बदला जाता है।

sudo systemctl restart matrix-synapse
systemctl status matrix-synapse
sudo journalctl -u matrix-synapse -n 100 --no-pager

एक सफल शुरुआत listeners को सक्रिय करती है और फिर शांत हो जाती है। systemd यूनिट किसी भी exit के कुछ सेकंड बाद सर्विस को रीस्टार्ट करती है, इसलिए यदि Synapse किसी कॉन्फ़िगरेशन को अस्वीकार करता है, तो यूनिट बार-बार start और die होती दिखाई देगी। जर्नल की अंतिम पंक्तियाँ उस key का नाम बताती हैं जिसे अस्वीकार किया गया है।

Synapse को Postgres से जोड़ना

sudo apt install -y postgresql
sudo -u postgres createuser --pwprompt synapse_user
sudo -u postgres createdb --encoding=UTF8 --locale=C --template=template0 --owner=synapse_user synapse

Locale केवल दिखावे के लिए नहीं होता है। यदि database अलग COLLATE और CTYPE मानों के साथ बनाया गया है, तो Synapse start होने से मना कर देगा, जब तक कि आप database config में allow_unsafe_locale सेट न करें। इसके बाद का एकमात्र समाधान database का dump लेना और उसे सही तरीके से बनाए गए database में फिर से load करना है। इसलिए इसे पहली बार में ही सही तरीके से बनाएँ।

database:
  name: psycopg2
  txn_limit: 10000
  args:
    user: synapse_user
    password: secretpassword
    dbname: synapse
    host: localhost
    port: 5432
    cp_min: 5
    cp_max: 10

अपनी सभी config फाइलों में केवल एक ही database: key रखें। conf.d के नीचे दूसरी copy जोड़ने के बजाय homeserver.yaml के अंदर मौजूद SQLite block को बदलें, ताकि यह सवाल ही न रहे कि कौन सी config सक्रिय है। Restart करें, फिर पुष्टि करें कि Synapse वास्तव में Postgres पर चल रहा है:

sudo -u postgres psql synapse -c "SELECT count(*) FROM users;"

एक संख्या का मतलब है कि Synapse ने इस database में अपना schema बना लिया है। missing relation के बारे में कोई error आने का मतलब है कि यह अभी भी SQLite फाइल में लिख रहा है, जिसका अर्थ है कि जिस config को आपने edit किया है, वह पढ़ी नहीं जा रही है।

Reverse proxy, TLS और .well-known फाइलों की federation आवश्यकताएं

Synapse localhost पर port 8008 पर plain HTTP सुनता है। TLS और public port इसके सामने स्थित reverse proxy के अंतर्गत आते हैं।

listeners:
- port: 8008
  tls: false
  type: http
  x_forwarded: true
  bind_addresses:
  - '::1'
  - '127.0.0.1'
  resources:
  - names:
    - client
    - federation
    compress: false

x_forwarded: true Synapse को यह निर्देश देता है कि वह proxy द्वारा सेट किए गए X-Forwarded-For header पर भरोसा करे। इसके बिना, हर client ऐसा दिखता है जैसे वह 127.0.0.1 से आया हो, इसलिए rate limiting एक ही अत्यंत व्यस्त local user को देखती है और सभी को एक साथ throttle कर देती है।

location ~ ^(/_matrix|/_synapse/client) {
    proxy_pass http://localhost:8008;
    proxy_set_header X-Forwarded-For $remote_addr;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header Host $host:$server_port;
    client_max_body_size 50M;
    proxy_http_version 1.1;
}

Synapse documentation इस block के बारे में एक चेतावनी देती है जिसमें लोगों के कई दिन बर्बाद हो जाते हैं। proxy_pass में port के बाद कोई path न जोड़ें, यहाँ तक कि एक अकेला / भी नहीं। nginx तब URI को canonicalise कर देता है, जिससे भेजने वाले सर्वर द्वारा हस्ताक्षरित bytes बदल जाते हैं, और federation requests का signature verification विफल हो जाता है जबकि सामान्य client requests काम करते रहते हैं।

client_max_body_size का मान कम से कम Synapse के max_upload_size जितना बड़ा होना चाहिए। यदि nginx में छोटी संख्या है, तो उससे ऊपर के uploads को nginx द्वारा 413 Request Entity Too Large के साथ अस्वीकार कर दिया जाता है, इससे पहले कि Synapse उन्हें देख सके, इसलिए विफलता को समझाने के लिए कोई Synapse log line नहीं होती है।

Certificate के लिए, Certbot and Let's Encrypt on Ubuntu 24.04 का पालन करें। यदि proxy अभी भी तय नहीं है, तो reverse proxy comparison यह बताता है कि कौन सा आपके लिए TLS का काम करेगा।

Delegation वह प्रक्रिया है जो server_name को example.com रहने देती है जबकि Synapse matrix.example.com पर चलता है। bare domain से दो फाइलें serve करें:

location /.well-known/matrix/server {
    default_type application/json;
    return 200 '{"m.server": "matrix.example.com:443"}';
}

location /.well-known/matrix/client {
    default_type application/json;
    add_header Access-Control-Allow-Origin '*';
    return 200 '{"m.homeserver": {"base_url": "https://matrix.example.com"}}';
}

Server फाइल अन्य homeservers को बताती है कि federation traffic कहाँ भेजना है, इसी तरह federation default port 8448 के बजाय 443 पर चलता है। Client फाइल Matrix clients को बताती है कि कौन सा URL @alice:example.com को support करता है। Client फाइल पर Access-Control-Allow-Origin header महत्वपूर्ण है क्योंकि browser-based clients इसे cross-origin fetch करते हैं, इसलिए header के बिना browser response को block कर देता है और client रिपोर्ट करता है कि उसे आपका homeserver नहीं मिल रहा है।

दोनों फाइलें example.com से ही valid TLS पर serve की जानी चाहिए। उन्हें जांचें, फिर देखें कि बाहरी दुनिया क्या देखती है:

curl -s https://example.com/.well-known/matrix/server
curl -s https://matrix.example.com/_matrix/federation/v1/version

पहली फाइल वह JSON लौटाती है जिसे आपने लिखा है। दूसरी फाइल एक JSON object लौटाती है जो server implementation और उसके version का नाम बताती है, जो यह साबित करता है कि proxy federation path पर Synapse तक पहुँचता है। फिर https://federationtester.matrix.org पर Matrix federation tester के माध्यम से domain को चलाएं, जो उसी मार्ग का अनुसरण करता है जिसे एक वास्तविक remote server अपनाता है।

Federate करें या न करें: इसे सोच-समझकर तय करें

Federation ही Matrix का मुख्य उद्देश्य है और यही इसकी अधिकांश लागत का कारण भी है। एक federating homeserver उन सर्वर्स से कनेक्शन स्वीकार करता है जिनके बारे में आपने कभी सुना भी नहीं होगा, उनके events प्राप्त करता है, उनके media को cache करता है, और आपके users द्वारा छुए गए हर room के लिए state स्टोर करता है। यह एक threat model का निर्णय है, न कि कोई default सेटिंग।

Federate तब करें जब आपके users को अन्य homeservers पर मौजूद लोगों तक पहुँचने की आवश्यकता हो, या जब portable identity ही वह कारण हो जिसके लिए आपने Matrix को चुना है। Federate तब न करें जब सर्वर केवल एक टीम के लिए हो और उस पर मौजूद हर account आपका अपना हो। एक closed सर्वर कम डेटा स्टोर करता है, कम डेटा प्राप्त करता है, और दुरुपयोग के लिए बहुत कम आकर्षक होता है।

Federation को disable करने के बजाय उसे restrict करने के लिए, Synapse एक allow list का उपयोग करता है:

federation_domain_whitelist:
- lon.example.com
- nyc.example.com

Documentation यह सलाह देती है कि federation listener को firewall के पीछे रखें, ताकि अवांछित traffic Python के अंदर आने के बजाय network स्तर पर ही रुक जाए। Federation को पूरी तरह से बंद करने के लिए, listener resources list से federation को हटा दें, /.well-known/matrix/server को publish न करें, और port 8448 को बंद रखें।

यदि Matrix चलाने का कारण निजी टीम चैट था और federation कभी भी उसका हिस्सा नहीं था, तो Synapse के साथ आगे बढ़ने से पहले अन्य self-hosted Slack alternatives के साथ इसकी running cost की तुलना करें। Rocket.Chat on Docker Compose एक छोटे machine पर टीम चैट की सुविधा देता है, क्योंकि इसे कभी भी किसी अन्य संगठन के room state को स्टोर करने की आवश्यकता नहीं होती है।

मीडिया रिपॉजिटरी वह है जो चुपचाप डिस्क को भर देती है

आपके अपने उपयोगकर्ताओं द्वारा अपलोड की गई फाइलें स्थायी रूप से आपकी डिस्क पर रहती हैं। अन्य homeservers पर उपयोगकर्ताओं द्वारा पोस्ट की गई फाइलें जैसे ही आपका कोई क्लाइंट उन्हें दिखाता है, वैसे ही फेच (fetch) होकर आपकी डिस्क पर कैश (cache) हो जाती हैं। इसके अलावा Synapse छवियों के लिए थंबनेल भी बनाता है, इसलिए एक फोटो कई फाइलों में बदल जाती है। डिफ़ॉल्ट रूप से इनमें से कुछ भी एक्सपायर नहीं होता है।

स्टोर को खोजें और उसका आकार मापें:

grep media_store_path /etc/matrix-synapse/homeserver.yaml
sudo du -sh /var/lib/matrix-synapse/media_store

उस पाथ (path) को मापें जिसे आपका अपना कॉन्फ़िगरेशन प्रिंट करता है। Debian पैकेज Synapse के डेटा को /var/lib/matrix-synapse के अंतर्गत रखता है, इसलिए स्टोर सामान्यतः वहीं स्थित होता है। फिर conf.d में एक रिटेंशन पॉलिसी सेट करें:

media_retention:
  local_media_lifetime: 90d
  remote_media_lifetime: 14d

उन दो लाइनों को ध्यान से पढ़ें, क्योंकि वे एक ही प्रकार की सेटिंग नहीं हैं। remote_media_lifetime एक कैश को एक्सपायर करता है, और यह जो कुछ भी डिलीट करता है उसे उस सर्वर से फिर से फेच किया जा सकता है जिसके पास वह फाइल है। local_media_lifetime आपके अपने उपयोगकर्ताओं के अपलोड को एक निश्चित आयु तक पहुँचने पर स्थायी रूप से डिलीट कर देता है। जो टीम चैट में दस्तावेज़ साझा करती है और उन्हें अगले साल भी खोजने की उम्मीद रखती है, वे उन्हें खो देगी। कई सर्वर केवल रिमोट वैल्यू सेट करते हैं।

एक बार की सफाई (one-off cleanup) के लिए, एडमिन API मिलीसेकंड में Unix टाइमस्टैम्प लेता है:

BEFORE_TS=$(date -d '30 days ago' +%s%3N)
curl -X POST -H "Authorization: Bearer $ADMIN_TOKEN" \
  "https://matrix.example.com/_synapse/admin/v1/purge_media_cache?before_ts=$BEFORE_TS"

POST /_synapse/admin/v1/purge_media_cache उस कैश किए गए रिमोट मीडिया को हटा देता है जिसे उस टाइमस्टैम्प से पहले अंतिम बार एक्सेस किया गया था। POST /_synapse/admin/v1/media/delete?before_ts=<ms> उसी नियम से लोकल मीडिया को डिलीट करता है। पहले रिमोट पर्ज (remote purge) चलाएं और फिर से मापें, क्योंकि फेडरेटिंग सर्वर पर रिमोट कैश आमतौर पर बड़ा हिस्सा होता है।

दो सेटिंग्स एक ही डिस्क को प्रभावित करती हैं। max_upload_size एक सिंगल अपलोड की सीमा तय करता है और इसे nginx में client_max_body_size के साथ तालमेल में रहना चाहिए। url_preview_enabled: true आपके सर्वर को रिमोट पेज फेच करने के लिए कहता है ताकि क्लाइंट लिंक प्रीव्यू दिखा सकें, जो बैंडविड्थ खर्च करता है और ऐसी सामग्री के थंबनेल स्टोर करता है जिसे किसी ने आपको अपलोड नहीं किया है।

किसी के आपके homeserver को खोजने से पहले registration बंद करें

Scanners कुछ ही दिनों में खुले homeserver को ढूँढ लेते हैं। एक बार जब accounts बनाना मुफ्त हो जाता है, तो आपका सर्वर हर उस room में spam का स्रोत बन जाता है जिसके साथ वह federate करता है, और दूसरी तरफ के administrators आपके पूरे domain को block कर देते हैं। वह reputation damage सफाई के बाद भी बना रहता है, क्योंकि block lists को हाथ से manage किया जाता है।

Synapse बंद स्थिति में ही आता है। enable_registration का default false है और registration_requires_token का default false है। Synapse registration enabled होने और verification step न होने पर start होने से भी मना कर देता है, जब तक कि आप अतिरिक्त रूप से enable_registration_without_verification: true set न करें। यह मनाही जानबूझकर की गई है, इसलिए startup error को दूर करने के लिए इसे चालू न करें।

अपने इच्छित accounts को हाथ से बनाएँ:

sudo register_new_matrix_user -c /etc/matrix-synapse/homeserver.yaml http://localhost:8008

यह user name, password और यह पूछता है कि क्या account एक server admin है। यह आपके द्वारा -c के साथ pass की गई config से registration_shared_secret पढ़ता है, इसलिए यदि यह report करता है कि उसे shared secret नहीं मिल रहा है, तो -c को उस file की ओर point करें जिसमें वह मौजूद है।

जब accounts को हाथ से बनाना मुश्किल हो जाए, तो registration tokens बीच का रास्ता हैं। Token एक string है जिसे नए user को signup के दौरान प्रस्तुत करना होता है, और प्रत्येक token पर यह limit हो सकती है कि वह कितनी बार काम करेगा:

enable_registration: true
registration_requires_token: true

curl -X POST -H "Authorization: Bearer $ADMIN_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"uses_allowed": 1}' \
  https://matrix.example.com/_synapse/admin/v1/registration_tokens/new

token को body से बाहर रखें और Synapse एक token generate करके return करेगा। GET /_synapse/admin/v1/registration_tokens उन tokens को list करता है जो live हैं। दोनों calls के लिए server admin account के access token की आवश्यकता होती है, जिसे आप ऊपर बनाए गए admin user के रूप में login करके प्राप्त करते हैं।

जो संस्था पहले से ही कहीं और accounts manage करती है, वह local passwords को पूरी तरह से छोड़ सकती है, क्योंकि Synapse login को OIDC (OpenID Connect) provider को delegate कर सकता है, उदाहरण के लिए Authentik as a self-hosted SSO provider। इसके बाद नए जुड़ने वालों और छोड़ने वालों को एक ही जगह से manage किया जाता है।

ऐसा बैकअप जो सर्वर को वास्तव में पुनर्निर्मित कर सके

Synapse बैकअप के तीन भाग होते हैं, और यदि इनमें से एक भी भाग गायब हो, तो सर्वर को रिस्टोर करने के बाद भी कोई उसका उपयोग नहीं कर पाएगा।

• Postgres डेटाबेस, जिसमें प्रत्येक इवेंट, अकाउंट और रूम की जानकारी होती है।
• मीडिया स्टोर डायरेक्टरी, जिसमें सभी अपलोड की गई फाइलें होती हैं।
• /etc/matrix-synapse, जिसमें आपकी कॉन्फ़िगरेशन और सर्वर की साइनिंग की (signing key) होती है।

साइनिंग की वह हिस्सा है जिसे लोग अक्सर भूल जाते हैं। यह वह प्राइवेट की है जिससे आपका होमसर्वर इवेंट्स को साइन करता है, और रिमोट सर्वर इसी से मेल खाने वाली पब्लिक की के आधार पर इवेंट्स को सत्यापित करते हैं। आपकी की कहाँ स्थित है, यह देखने के लिए grep signing_key_path /etc/matrix-synapse/homeserver.yaml चलाएँ। यदि आप इसे खो देते हैं, तो आप एक ऐसा सर्वर रिस्टोर करेंगे जो यह साबित नहीं कर पाएगा कि वह वही सर्वर है जिसे आपके रूम्स पहले से जानते हैं।

sudo -u postgres pg_dump --format=custom --file=/var/backups/synapse-$(date +%F).dump synapse
sudo tar czf /var/backups/synapse-etc-$(date +%F).tgz -C /etc matrix-synapse

सबसे पहले डेटाबेस का डंप लें, उसके बाद मीडिया स्टोर को कॉपी करें। मीडिया फाइलें एक बार लिखी जाती हैं और आईडी द्वारा संदर्भित की जाती हैं, इसलिए डंप के बाद ली गई मीडिया कॉपी में केवल अतिरिक्त फाइलें हो सकती हैं, कोई फाइल गायब नहीं हो सकती। यदि आप इसके विपरीत क्रम में बैकअप लेते हैं, तो रिस्टोर किया गया डेटाबेस ऐसी फाइल को पॉइंट कर सकता है जिसे आपके बैकअप ने कभी कैप्चर ही नहीं किया था।

इन तीनों भागों को VPS से बाहर भेजें। restic with off-site snapshots इस कार्य के लिए उपयुक्त है, क्योंकि मीडिया स्टोर का आकार बड़ा होता है और यह रन के बीच बहुत कम बदलता है, इसलिए डिडुप्लीकेशन (deduplication) प्रत्येक स्नैपशॉट को छोटा रखता है।

इसके बाद रिस्टोर का अभ्यास करें, क्योंकि जिस बैकअप को आपने कभी रिस्टोर नहीं किया, वह केवल एक परिकल्पना मात्र है। एक दूसरा VPS बनाएँ, वही पैकेज इंस्टॉल करें, कॉन्फ़िगरेशन रिस्टोर करें, समान एन्कोडिंग और लोकेल के साथ डेटाबेस बनाएँ, डंप को pg_restore के माध्यम से उसमें डालें, मीडिया स्टोर को वापस कॉपी करें, और लॉग इन करें। इसमें कितना समय लगा, इसे नोट कर लें। यही संख्या आपका वास्तविक रिकवरी समय है।

जब state tables बढ़ती हैं: compaction

Synapse room state को state groups के रूप में store करता है, और एक federating server पर state_groups_state अक्सर database का सबसे बड़ा object बन जाता है। कुछ भी बदलने से पहले मापें:

sudo -u postgres psql synapse -c "SELECT pg_size_pretty(pg_database_size('synapse'));"
sudo -u postgres psql synapse -c "SELECT pg_size_pretty(pg_total_relation_size('state_groups_state'));"

यदि वह एक table आपके database का अधिकांश हिस्सा है, तो project इसके लिए एक compressor प्रकाशित करता है, rust-synapse-compress-state, जो किसी भी room के state का अर्थ बदले बिना state group hierarchy को कम पंक्तियों (rows) में फिर से लिखता है। इसे Rust के साथ बनाया गया है:

sudo apt install -y build-essential libssl-dev pkg-config git
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
git clone https://github.com/matrix-org/rust-synapse-compress-state.git
cd rust-synapse-compress-state/synapse_auto_compressor
cargo build --release

./target/release/synapse_auto_compressor -p postgresql://synapse_user:secretpassword@localhost/synapse -c 500 -n 100

-c यह है कि यह एक बार में कितने state groups पर काम करता है और -n यह है कि यह run उन chunks में से कितनों को process करता है। auto compressor यह record करता है कि वह कहाँ तक पहुँचा, इसलिए अगली run वहीं से जारी रहती है, जो इसे schedule करने के लिए सुरक्षित बनाता है। इसका documentation नोट करता है कि बदलाव append-only tables के विरुद्ध transactions में लागू किए जाते हैं, इसलिए यह Synapse के चालू रहने के दौरान चल सकता है। पहली run से पहले हर हाल में database का backup लें।

यहाँ एक Postgres विवरण लोगों को हैरान करता है। पंक्तियों को delete करने से Postgres को पुनः उपयोग के लिए space वापस मिलता है, न कि file system को, इसलिए एक बड़े compaction के बाद df शायद बिल्कुल न घटे। VACUUM FULL इसे वापस लौटाता है, और यह table पर एक exclusive lock लेता है और साथ ही table के आकार के बराबर खाली disk space की आवश्यकता होती है, इसलिए इसे बिना सोचे-समझे चलाने के बजाय maintenance के रूप में schedule करें।

सर्वर के स्वस्थ होने की जाँच

systemctl status matrix-synapse
curl -s https://example.com/.well-known/matrix/server
curl -s https://matrix.example.com/_matrix/federation/v1/version
sudo -u postgres psql synapse -c "SELECT pg_size_pretty(pg_database_size('synapse'));"
sudo du -sh /var/lib/matrix-synapse/media_store

स्वस्थ होने का अर्थ है कि unit सक्रिय है और restart नहीं हो रही है, delegation file आपका m.server मान लौटाती है, federation version endpoint JSON लौटाता है, और दो size संख्याओं की तुलना पिछले महीने के आंकड़ों से की जा सकती है। size की जाँच वह प्रक्रिया है जिसे लोग अक्सर छोड़ देते हैं, और disk का भर जाना वह विफलता है जो बिना किसी चेतावनी के Synapse सर्वर को बंद कर देती है: एक full volume Postgres को लिखने से रोक देता है, और फिर Synapse डेटाबेस से संबंधित हर request को विफल कर देता है।

FAQ

Matrix Synapse सर्वर को कितनी RAM की आवश्यकता होती है?

कुछ उपयोगकर्ताओं, छोटे कमरों और किसी भी बड़े सार्वजनिक कमरे के बिना एक निजी homeserver के लिए 2 GB RAM पर्याप्त है, और अगस्त 2026 तक अधिकांश प्रकाशित sizing पेज यही अनुशंसा करते हैं। यदि आपके उपयोगकर्ता #matrix:matrix.org जैसे बड़े सार्वजनिक कमरों में शामिल होते हैं, तो Synapse दस्तावेज़ीकरण बाकी आवश्यकताओं के अतिरिक्त कम से कम 1 GB खाली RAM की मांग करता है, क्योंकि आपका सर्वर तब उस कमरे की स्थिति (state) को संग्रहीत करता है और उसके ट्रैफ़िक को लगातार प्रोसेस करता है। 2 GB वाले प्लान पर swap जोड़ें ताकि एक बड़े join के कारण kernel द्वारा process को kill न किया जाए।

क्या मुझे SQLite के बजाय PostgreSQL का उपयोग करना चाहिए?

कुछ उपयोगकर्ताओं से अधिक होने पर, हाँ। SQLite एक समय में केवल एक writer की अनुमति देता है, इसलिए लोड के तहत federation ट्रैफ़िक और client requests एक-दूसरे को ब्लॉक करते हैं और requests कई सेकंड तक लटक (hang) जाती हैं। Synapse की worker processes, जो एक से अधिक CPU core का उपयोग करने का समर्थित तरीका है, के लिए Postgres की आवश्यकता होती है। बाद में migration synapse_port_db के साथ काम करता है और इसमें downtime लगता है, इसलिए उपयोगकर्ताओं के आने से पहले --encoding=UTF8 --locale=C --template=template0 के साथ डेटाबेस बनाएँ।

Synapse का डिस्क उपयोग लगातार क्यों बढ़ रहा है?

एक निर्देशिका (directory) और एक तालिका (table) इसके कारण हैं। media store उन सभी फ़ाइलों को रखता है जो आपके सर्वर वाले कमरों में अपलोड की जाती हैं, जिसमें दूरस्थ उपयोगकर्ताओं के मीडिया की cached प्रतियां और उत्पन्न thumbnails शामिल हैं, और जब तक आप media_retention सेट नहीं करते, तब तक कुछ भी expire नहीं होता। state_groups_state तालिका एक federating सर्वर पर कमरे की स्थिति के साथ बढ़ती है, और rust-synapse-compress-state इसे कम करती है। निर्णय लेने से पहले कि किस पर काम करना है, अपने media_store_path पर du -sh के साथ और SELECT pg_size_pretty(pg_total_relation_size('state_groups_state')); के साथ दोनों को मापें।

मैं अजनबियों को अपने homeserver पर पंजीकरण करने से कैसे रोकूँ?

enable_registration को इसके डिफ़ॉल्ट false पर छोड़ दें और register_new_matrix_user के साथ खाते बनाएँ। जब यह स्केल करना बंद कर दे, तो registration_requires_token: true के साथ enable_registration: true सेट करें, और POST /_synapse/admin/v1/registration_tokens/new के माध्यम से बनाए गए tokens वितरित करें। केवल Synapse के स्टार्टअप इनकार को शांत करने के लिए enable_registration_without_verification: true सेट न करें, क्योंकि एक खुला homeserver स्पैम का स्रोत बन जाता है और अन्य प्रशासक आपके पूरे डोमेन को ब्लॉक करके प्रतिक्रिया देते हैं।

क्या मेरे homeserver को federate करना चाहिए?

Federation एक्सपोज़र के बारे में एक निर्णय है, न कि कोई डिफ़ॉल्ट सेटिंग। यदि आपके उपयोगकर्ताओं को अन्य homeservers पर लोगों तक पहुँचने की आवश्यकता है, तो ही federate करें। यदि सर्वर एक टीम की सेवा करता है, तो इसे बंद रखें, क्योंकि एक non-federating सर्वर कम डेटा संग्रहीत करता है, कम ट्रैफ़िक प्राप्त करता है और बहुत कम दुरुपयोग को आकर्षित करता है। बीच के मामलों के लिए, federation_domain_whitelist federation को नामित पार्टनर डोमेन तक सीमित करता है, और Synapse दस्तावेज़ीकरण केवल उस application-layer जांच पर भरोसा करने के बजाय federation listener को firewall करने की भी अनुशंसा करता है।