Cara Bina Pelayan CalDAV Sendiri di VPS

Apa yang anda sedang bina

Kalendar yang dihoskan sendiri ialah satu pelayan CalDAV pada VPS yang anda kawal, di sebalik TLS, dengan satu log masuk bagi setiap orang. Telefon di dalam poket anda dan komputer riba di atas meja anda memaparkan acara yang sama, begitu juga dengan komputer riba pasangan anda. Tiada akaun Google yang menjadi perantara.

Ini merupakan tugas yang berbeza daripada halaman tempahan yang dihoskan sendiri. Halaman tempahan adalah untuk orang asing: ia menerbitkan slot masa lapang anda dan membenarkan seseorang menuntut satu slot. Pelayan kalendar adalah untuk peranti anda sendiri: ia menyimpan acara dan memastikan setiap klien selaras. Pengguna sering menjalankan kedua-duanya, dan alat tempahan kemudian membaca ketersediaan daripada pelayan CalDAV yang anda bina di sini.

Pemasangannya kecil. Radicale ialah satu pakej Python dan kira-kira sepuluh baris konfigurasi. Perkara yang menentukan sama ada persediaan ini bertahan melepasi bulan pertama ialah TLS, penemuan (discovery), koleksi bagi setiap pengguna, dan sandaran. Perkara tersebut mendapat ruang paling banyak di bawah.

Apakah itu CalDAV, dan mengapa ia penting?

CalDAV ialah penyelarasan kalendar melalui HTTP. Ia ditakrifkan dalam RFC 4791 sebagai sambungan kepada WebDAV (web distributed authoring and versioning, satu set kaedah HTTP tambahan yang ditakrifkan dalam RFC 4918). Kalendar ialah koleksi yang berfungsi seperti direktori. Satu acara ialah satu fail di dalamnya, ditulis dalam format teks iCalendar (RFC 5545), format yang sama seperti .ics lampiran dalam e-mel anda.

Pelanggan menggunakan HTTP biasa dengan beberapa kaedah tambahan. PROPFIND bertanya apa yang ada di sini dan apakah sifatnya. REPORT meminta hirisan yang ditapis, seperti setiap acara dalam julat tarikh tertentu. PUT menulis satu acara dan DELETE memadamkannya. Setiap acara membawa baris UID, dan pengecam tersebut ialah cara dua peranti bersetuju bahawa mereka sedang melihat acara yang sama dan bukannya salinan.

Kebolehalihtanganan ialah ganjaran utamanya, dan itulah sebab sebenar untuk menggunakannya. iOS, macOS, Thunderbird, Evolution dan Android melalui DAVx⁵ semuanya menyokong CalDAV. Data anda tidak terikat dengan pelayan yang anda pilih hari ini. Pindahkan fail ke pelayan CalDAV yang berbeza, halakan pelanggan ke nama hos baharu, dan tiada perkara lain yang berubah.

CardDAV turut disertakan. Ia menggunakan konsep yang sama untuk kenalan, ditakrifkan dalam RFC 6352 dan menyimpan fail vCard dan bukannya acara. Setiap pelayan di bawah menyediakan kedua-dua protokol daripada akaun yang sama, jadi sebaik sahaja kalendar berfungsi, buku alamat hanya memerlukan satu tanda semak.

Pelayan CalDAV yang manakah perlu anda jalankan?

Radicale ialah perisian paling kecil yang berfungsi dengan baik. Ia berasaskan Python, tidak memerlukan pangkalan data, dan storannya hanyalah folder fail biasa. Panduan ini menggunakannya kerana kalendar isi rumah tidak memerlukan lebih daripada itu, dan kerana risiko kegagalan pada waktu awal pagi adalah sangat rendah.

Baikal ialah pilihan yang mempunyai panel pentadbir web. Ia berjalan menggunakan PHP dan pustaka sabre/dav, menyimpan pengguna serta kalendar dalam SQLite atau MySQL, dan membolehkan anda menambah pengguna melalui pelayar web dan bukannya baris perintah. Pilih perisian ini jika akaun pengguna sering berubah-ubah.

Nextcloud adalah pilihan yang tepat jika kalendar hanyalah satu daripada beberapa ciri yang diperlukan. Anda mendapat kalendar, kenalan, fail dan aplikasi mudah alih, namun perlu menanggung beban PHP-FPM, pangkalan data dan pelari kerja latar belakang. Jika ini kedengaran terlalu berat untuk keperluan sebenar anda, alternatif Nextcloud yang lebih ringan merangkumi pertimbangan tersebut, dan penyegerakan fail layan diri merangkumi separuh lagi sebab mengapa orang memasang Nextcloud.

DAViCal ialah pilihan PostgreSQL yang telah lama wujud. Ia hanya wajar dipertimbangkan jika anda sudah menjalankan PostgreSQL dan mahu data kalendar disimpan di dalamnya.

Memasang Radicale pada Ubuntu 24.04

Radicale 3.5.10 merupakan keluaran semasa setakat Ogos 2026. Pasangkannya ke dalam persekitaran maya (virtual environment) tersendiri.

sudo apt update
sudo apt install -y python3-venv apache2-utils nginx
sudo useradd --system --user-group --home-dir / --shell /usr/sbin/nologin radicale
sudo install -d -o radicale -g radicale -m 750 /var/lib/radicale/collections
sudo install -d -m 750 -o root -g radicale /etc/radicale
sudo python3 -m venv /opt/radicale/venv
sudo /opt/radicale/venv/bin/pip install --upgrade radicale

Persekitaran maya bukanlah pilihan gaya. sudo pip install radicale ke dalam Python sistem akan terhenti dengan error: externally-managed-environment, kerana Ubuntu menandakan Python miliknya sebagai hak milik apt supaya pip tidak boleh menulis ganti fail yang dipakejkan.

Tulis /etc/radicale/config:

[server]
hosts = 127.0.0.1:5232

[auth]
type = htpasswd
htpasswd_filename = /etc/radicale/users
htpasswd_encryption = autodetect

[storage]
filesystem_folder = /var/lib/radicale/collections

hosts mengikat pada loopback secara sengaja. nginx menamatkan TLS dan menghalakan trafik ke port tersebut, jadi Radicale tidak pernah berhadapan dengan internet secara terus. Contoh upstream bagi 0.0.0.0:5232 menerbitkan servis tanpa enkripsi yang menerima kata laluan, yang merupakan satu kesilapan yang penting di sini.

Sekarang untuk akaun. -5 memilih SHA-512 crypt, yang dibaca oleh Radicale dengan htpasswd_encryption = autodetect tanpa modul tambahan:

sudo htpasswd -5 -c /etc/radicale/users you
sudo htpasswd -5 /etc/radicale/users partner
sudo chown root:radicale /etc/radicale/users
sudo chmod 640 /etc/radicale/users

-c mencipta fail tersebut dan memotong apa sahaja kandungan yang ada di dalamnya. Gunakannya untuk pengguna pertama sahaja. Menjalankan htpasswd -5 -c sekali lagi beberapa bulan kemudian akan memadamkan setiap akaun yang ditambah selepas yang pertama, dan simptomnya ialah seorang pengguna boleh menyegerak dengan baik manakala orang lain mendapat gesaan kata laluan yang tidak berkesudahan. Bcrypt juga berfungsi, dan ia memerlukan pemasangan tambahan radicale[bcrypt].

Cipta /etc/systemd/system/radicale.service, yang diadaptasi daripada unit dalam dokumentasi Radicale:

[Unit]
Description=CalDAV and CardDAV server
After=network.target
Requires=network.target

[Service]
ExecStart=/opt/radicale/venv/bin/python -m radicale
Restart=on-failure
User=radicale
UMask=0027
PrivateTmp=true
ProtectSystem=strict
ProtectHome=true
PrivateDevices=true
ProtectKernelTunables=true
ProtectKernelModules=true
ProtectControlGroups=true
NoNewPrivileges=true
ReadWritePaths=/var/lib/radicale/

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload
sudo systemctl enable --now radicale
curl -i http://127.0.0.1:5232/

Hasil yang sihat adalah 401 Unauthorized dengan pengepala WWW-Authenticate: servis sedang mendengar dan pengesahan dihidupkan. Connection refused bermakna ia tidak pernah bermula, dan journalctl -u radicale -n 50 menamakan pilihan yang ditolaknya. ProtectSystem=strict melekapkan sistem fail sebagai baca sahaja (read only) untuk servis ini, jadi ReadWritePaths=/var/lib/radicale/ ialah baris yang membolehkannya menyimpan acara. Gugurkan baris tersebut dan bacaan akan terus berfungsi manakala setiap penulisan akan gagal.

TLS bukan pilihan, kerana klien menolak teks biasa

CalDAV melakukan pengesahan menggunakan HTTP Basic, yang menghantar user:password berkod base64 pada setiap permintaan. Base64 ialah pengekodan, bukan penyulitan. Melalui HTTP biasa, anda menyerahkan kata laluan kepada setiap rangkaian antara telefon dan pelayan, sepanjang hari, setiap kali penyelarasan berlaku.

Klien menguatkuasakan perkara ini untuk anda. Dokumentasi Radicale menyatakan bahawa macOS Calendar.app mungkin menolak untuk menghantar kelayakan melalui HTTP yang tidak selamat secara senyap, dan iOS berkelakuan sama. Akaun kelihatan telah dikonfigurasikan tetapi tidak pernah menyelaraskan data, tanpa sebarang ralat untuk dibaca.

Halakan rekod A untuk cal.example.com ke VPS terlebih dahulu, kerana pihak berkuasa sijil akan menyemaknya. Kemudian, cipta /etc/nginx/sites-available/cal.example.com:

server {
    listen 80;
    server_name cal.example.com;

    location / {
        proxy_pass        http://localhost:5232/;
        proxy_set_header  X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header  X-Forwarded-Proto $scheme;
        proxy_set_header  Host $http_host;
        proxy_pass_header Authorization;
    }

    location = /.well-known/caldav  { return 301 https://$host/; }
    location = /.well-known/carddav { return 301 https://$host/; }
}

Empat baris pengepala proksi datang daripada dokumentasi Radicale. Kekalkan ia seperti sedia ada.

sudo ln -s /etc/nginx/sites-available/cal.example.com /etc/nginx/sites-enabled/
sudo nginx -t && sudo systemctl reload nginx
sudo apt install -y certbot python3-certbot-nginx
sudo certbot --nginx -d cal.example.com
curl -i -u you https://cal.example.com/

nginx -t mencetak syntax is ok dan test is successful. Lakukan muat semula (reload) hanya selepas ia berjaya, kerana muat semula dengan fail yang rosak akan membiarkan konfigurasi lama berjalan dan menyembunyikan kesilapan sehingga but semula seterusnya. Certbot menyunting fail tapak secara terus: ia memasang sijil, menukar blok ke port 443 dan menambah ubah hala (redirect) daripada port 80. Perintah curl terakhir akan meminta kata laluan dan sepatutnya mengembalikan 200, iaitu antara muka web Radicale sendiri. 502 Bad Gateway bermaksud nginx sedang berjalan dan Radicale tidak mendengar pada port 5232.

Mengapa penambahan akaun gagal pada telefon?

Kegagalan ini berpunca daripada proses penemuan (discovery). RFC 6764 menerangkan cara klien menukar nama hos kepada URL kalendar. Klien akan mencari rekod SRV _caldavs._tcp, kemudian meminta https://cal.example.com/.well-known/caldav dan menjangkakan pengalihan (redirect) ke akar DAV. Dari situ, ia meminta current-user-principal, kemudian meminta calendar-home-set bagi prinsipal tersebut, dan hanya selepas itu ia dapat melihat kalendar anda. Telefon hanya menyediakan satu medan untuk pelayan, jadi setiap langkah perlu berfungsi tanpa campur tangan pengguna.

curl -sI https://cal.example.com/.well-known/caldav

Jawapan yang betul ialah HTTP/2 301 dengan pengepala location: https://cal.example.com/. Ralat 404 di situ adalah sebab mengapa iOS menyatakan ia tidak dapat mengesahkan maklumat akaun, sedangkan Thunderbird pada rangkaian yang sama berfungsi: Thunderbird menggunakan URL penuh yang anda taip, jadi ia tidak memerlukan pengalihan tersebut.

Sasaran pengalihan bergantung pada pelayan. Radicale yang dihoskan pada akar tapak akan mengalihkan ke /. Baikal menyediakan peraturan contoh yang mengalihkan ke /dav.php dengan status 308. Nextcloud pula mengalihkan ke /remote.php/dav/.

Cipta kalendar dan kongsi satu dengan pasangan anda

Banyak klien tidak boleh mencipta kalendar, hanya boleh melanggan kalendar sedia ada. Buka https://cal.example.com/ dalam pelayar web, log masuk sebagai you, dan cipta kalendar di sana. Pada cakera, ia disimpan di bawah /var/lib/radicale/collections/collection-root/you/, dengan pengecam yang dijana secara automatik sebagai nama folder.

Backend hak akses lalai Radicale ialah owner_only: akaun yang disahkan boleh membaca dan menulis koleksi sendiri di bawah /USERNAME/ dan tiada yang lain. Bagi kebanyakan isi rumah, ini adalah tetapan yang betul, dan cara paling mudah untuk berkongsi kalendar adalah dengan menggunakan akaun ketiga. Cipta household dengan htpasswd, buat kalendar kongsi di bawah log masuk tersebut, dan tambahkannya pada setiap peranti sebagai akaun CalDAV kedua. Ia berfungsi pada setiap klien, termasuk iOS, kerana kalendar tersebut terletak di dalam direktori utama akaun itu sendiri.

Apabila anda memerlukan kawalan yang lebih terperinci, beralih kepada hak akses berasaskan peraturan. Tambahkan ini ke dalam /etc/radicale/config:

[rights]
type = from_file
file = /etc/radicale/rights

Kemudian /etc/radicale/rights, berdasarkan contoh dalam dokumentasi Radicale:

[root]
user: .+
collection:
permissions: R

[principal]
user: .+
collection: {user}
permissions: RW

[own-calendars]
user: .+
collection: {user}/[^/]+
permissions: rw

[shared-household]
user: you|partner
collection: you/2f0a9c1e-1f4c-4c2b-9a1b-0d2f7a5c9e11
permissions: rw

Huruf besar dan huruf kecil membawa maksud yang berbeza. R dan W membaca dan menulis koleksi yang bukan kalendar atau buku alamat, iaitu apa yang dimaksudkan dengan folder prinsipal. r dan w membaca dan menulis kalendar itu sendiri. Gantikan pengecam tersebut dengan nama folder sebenar kalendar anda daripada laluan storan di atas.

Satu had yang perlu diketahui: klien yang hanya membaca direktori utama kalendar tidak akan memaparkan kalendar yang berada di bawah laluan pengguna lain, kerana proses penemuan (discovery) tidak akan mencapainya. Thunderbird dan DAVx⁵ boleh menambahkannya melalui URL penuh. iOS tidak boleh, itulah sebabnya corak akaun kongsi adalah kaedah yang sentiasa berkesan.

Sediakan klien, kerana di sinilah kalendar yang dihoskan sendiri sering gagal

iPhone dan iPad. Buka Settings, kemudian Calendar (disenaraikan di bawah Apps pada versi iOS terkini), kemudian Calendar Accounts, Add Account, Other, Add CalDAV Account. Server ialah cal.example.com, diikuti dengan nama pengguna dan kata laluan. Description hanyalah label. Jika ia enggan disimpan, buka akaun itu semula: paparan advanced mendedahkan Use SSL, port dan URL akaun penuh, dan menampal URL tersebut akan melangkau proses penemuan sepenuhnya.

Android. Tiada klien CalDAV terbina dalam. Pasang DAVx⁵ daripada F-Droid atau Google Play, tambah akaun menggunakan URL asas https://cal.example.com/ dengan nama pengguna anda, kemudian tandakan kalendar yang anda mahukan. DAVx⁵ menulis ke dalam penyedia kalendar Android, jadi acara akan muncul dalam mana-mana aplikasi kalendar yang anda gunakan.

Thunderbird. New Calendar, On the Network, kemudian masukkan nama pengguna anda dan lokasi https://cal.example.com/. Ia akan menyenaraikan apa yang ditemui dan bertanya kalendar mana yang ingin ditambah.

macOS. System Settings, Internet Accounts, Add Other Account, CalDAV, tetapkan Account Type kepada Manual, kemudian masukkan nama pengguna, kata laluan dan alamat server yang sama.

CalDAV ialah protokol polling. Tiada fungsi push dalam spesifikasi ini, jadi acara yang anda tambah pada komputer riba akan tiba pada telefon semasa penyelarasan seterusnya, bukan pada saat yang sama. Tetapkan selang masa dalam setiap klien yang sesuai dengan keperluan anda, dan ingat bahawa selang masa yang lebih singkat pada telefon akan menggunakan lebih banyak bateri.

Sandarkan stor, yang hanya terdiri daripada fail

Di bawah Radicale, kalendar anda merupakan direktori fail .ics, satu fail bagi setiap acara, berserta satu fail sifat kecil bagi setiap koleksi. Apa-apa sahaja yang menyalin direktori akan menyandarkannya, dan anda boleh membuka sandaran dengan less untuk mengesahkan bahawa ia mengandungi acara sebenar. Ini merupakan kelebihan yang nyata berbanding dump pangkalan data yang tidak boleh dibaca.

sudo systemctl stop radicale
sudo tar czf /root/radicale-$(date +%F).tar.gz -C /var/lib/radicale collections
sudo systemctl start radicale

Hentikan servis untuk beberapa saat sementara arkib dibuat, supaya tiada klien yang sedang dalam proses penulisan semasa fail dibaca. Salin arkib keluar dari kotak tersebut selepas itu, kerana sandaran pada VPS yang sama tidak akan terselamat daripada kegagalan yang anda sedang persiapkan. Pemulihan adalah sebaliknya: ekstrak, sudo chown -R radicale:radicale /var/lib/radicale/collections, mulakan servis. Setiap klien juga menyimpan salinan tempatan kalendar mereka, jadi komputer riba yang belum diselaraskan sejak kegagalan berlaku merupakan salinan kedua bagi data anda.

Bilakah Baikal atau Nextcloud menjadi pilihan yang lebih sesuai

Baikal 0.12.1 telah dikeluarkan pada 5 Ogos 2026 dan memerlukan PHP 8.2 atau lebih baharu. Nyahzip ia di luar web root dan dedahkan hanya direktori html miliknya:

sudo apt install -y php-fpm php-sqlite3 php-xml php-mbstring php-curl unzip
cd /tmp
curl -LO https://github.com/sabre-io/Baikal/releases/download/0.12.1/baikal-0.12.1.zip
sudo unzip -q baikal-0.12.1.zip -d /srv
sudo chown -R www-data:www-data /srv/baikal/Specific /srv/baikal/config

Dua direktori tersebut adalah satu-satunya lokasi yang ditulis oleh pelayan web, jadi tiada bahagian lain yang perlu mempunyai kebenaran menulis. Di dalam blok pelayan nginx anda, bahagian khusus untuk Baikal adalah seperti berikut:

root /srv/baikal/html;
index index.php;

location ~ /(\.ht|Core|Specific|config) { deny all; }

location ~ \.php$ {
    include snippets/fastcgi-php.conf;
    fastcgi_pass unix:/run/php/php8.3-fpm.sock;
}

location = /.well-known/caldav  { return 308 /dav.php; }
location = /.well-known/carddav { return 308 /dav.php; }

Muat semula nginx, buka laman tersebut dalam pelayar, dan wizard tetapan akan mencipta akaun pentadbir serta pangkalan data SQLite. Tetapan klien adalah sama seperti Radicale, dengan https://cal.example.com/ sebagai alamat pelayan, kerana peraturan well-known menghantar penemuan ke /dav.php.

Nextcloud hanya berbaloi digunakan jika anda juga mahukan fail dan aplikasi telefon dalam log masuk yang sama. Root DAV miliknya ialah /remote.php/dav/, dan peraturan penemuan yang sama juga terpakai. Bagi mana-mana servis ini, menjalankan servis di dalam kontena akan memastikan versi PHP tidak bercampur dengan host anda: Docker Compose pada VPS merangkumi fail compose dan reverse proxy di hadapannya, dan apa yang berbaloi untuk di-self-host pada tahun 2026 merupakan tempat yang sesuai untuk menentukan sejauh mana anda ingin meneruskan usaha ini.

Mod kegagalan dan rentetan yang akan anda lihat

Setiap penyelarasan mengembalikan 401. Sama ada fail kata laluan kehilangan akaunnya akibat htpasswd -c kedua, atau pengguna radicale tidak dapat membacanya. Semak dengan sudo -u radicale cat /etc/radicale/users; ralat permission denied di situ adalah jawapannya, dan penyelesaiannya ialah kumpulan radicale dengan mod 640. Radicale juga menunggu satu saat selepas setiap log masuk yang gagal secara lalai, jadi klien dengan kata laluan lapuk kelihatan perlahan dan bukannya ditolak.

nginx menjawab 405 pada PROPFIND. URL tersebut dihidangkan sebagai fail statik, jadi kaedah WebDAV tidak pernah sampai ke Radicale. Uji titik akhir (endpoint) secara terus:

curl -u you -X PROPFIND -H "Depth: 0" -i https://cal.example.com/you/

Koleksi DAV yang berfungsi akan menjawab 207 Multi-Status. Sebarang jawapan lain bermakna permintaan tersebut terhenti pada pelayan web.

Telefon tidak dapat mengesahkan akaun, tetapi pelayar web berfungsi dengan baik. Terdapat dua punca biasa. Ubah hala (redirect) well-known tiada, yang boleh diuji dengan curl di atas. Atau rantaian sijil tidak lengkap, yang biasanya ditutup oleh pelayar web dengan mengambil perantara yang hilang manakala iOS tidak melakukannya. Semak daripada shell:

openssl s_client -connect cal.example.com:443 -servername cal.example.com </dev/null

Cari Verify return code: 0 (ok). Jika ia gagal, konfigurasi nginx menghala ke cert.pem sedangkan ia sepatutnya menghala ke fullchain.pem.

Acara pendua selepas import. Setiap acara membawa UID, dan klien menganggapnya sebagai identiti. Import fail yang sama dua kali melalui alat yang menjana semula pengecam dan anda akan mendapat dua acara yang tidak akan dapat digabungkan oleh apa-apa pun. Padam salinan tambahan pada satu peranti dan biarkan pemadaman tersebut diselaraskan.

Semuanya berhenti berfungsi selepas but semula (reboot). Servis tersebut dimulakan secara manual. sudo systemctl is-enabled radicale memaparkan disabled, dan sudo systemctl enable --now radicale membaikinya secara kekal.

FAQ

Adakah saya benar-benar memerlukan TLS untuk pelayan CalDAV yang dihoskan sendiri?

Ya. CalDAV melakukan pengesahan menggunakan HTTP Basic, jadi kata laluan dihantar dalam bentuk pengekodan base64 pada setiap permintaan, dan base64 sangat mudah diterbalikkan. Pelanggan (client) juga menguatkuasakannya: macOS Calendar.app mungkin secara senyap enggan menghantar kelayakan melalui HTTP yang tidak selamat, dan iOS berkelakuan sama, jadi akaun kelihatan disimpan tetapi tidak pernah diselaraskan (sync). sudo certbot --nginx -d cal.example.com adalah keseluruhan tugasnya.

Mengapa telefon saya gagal menambah akaun sedangkan Thunderbird berfungsi?

Thunderbird menggunakan URL penuh yang anda taip. Telefon hanya memberikan satu medan pelayan, jadi ia mengikut penemuan RFC 6764: ia meminta https://cal.example.com/.well-known/caldav dan menjangkakan lencongan (redirect) ke akar DAV. Tanpa lencongan itu, telefon mendapat ralat 404 dan melaporkan bahawa ia tidak dapat mengesahkan akaun tersebut. Tambahkan location = /.well-known/caldav { return 301 https://$host/; } ke nginx, kemudian sahkan dengan curl -sI https://cal.example.com/.well-known/caldav bahawa anda mendapat 301 dan pengepala (header) location.

Bolehkah dua orang berkongsi satu kalendar?

Ya, dan cara yang boleh dipercayai adalah dengan menggunakan log masuk kongsi. Cipta akaun ketiga dengan htpasswd, letakkan kalendar kongsi di bawahnya, dan tambahkannya sebagai akaun CalDAV kedua pada setiap peranti. Fail hak milik Radicale sebaliknya boleh memberikan pengguna bernama kebenaran membaca dan menulis pada satu koleksi di bawah laluan pengguna lain, tetapi pelanggan yang hanya membaca set rumah kalendar sendiri tidak akan memaparkannya, jadi laluan itu lebih sesuai untuk Thunderbird dan DAVx⁵ berbanding iOS.

Apa yang berlaku kepada acara saya jika VPS mati?

Dengan Radicale, storannya adalah teks biasa: satu fail .ics bagi setiap acara di bawah /var/lib/radicale/collections/collection-root/, yang boleh anda sandarkan dengan tar dan baca dengan less. Pemulihan adalah dengan mengekstrak, chown -R radicale:radicale, dan memulakan servis. Setiap pelanggan yang diselaraskan juga menyimpan salinan tempatan, jadi komputer riba yang dikemas kini sebelum kegagalan berlaku memegang salinan kedua penuh kalendar anda.

Adakah pelayan CalDAV menyelaraskan kenalan saya juga?

Kenalan menggunakan CardDAV, protokol saudara yang ditakrifkan dalam RFC 6352 yang menyimpan fail vCard dan bukannya acara. Radicale, Baikal dan Nextcloud semuanya menyediakannya daripada akaun yang sama dan nama hos yang sama. Pada Android, DAVx⁵ menyelaraskan kalendar dan kenalan daripada satu akaun. Pada iOS, anda menambah akaun kedua jenis CardDAV dengan kelayakan yang sama, itulah sebabnya lencongan /.well-known/carddav perlu diletakkan dalam konfigurasi nginx anda bersebelahan dengan konfigurasi CalDAV.