Jinsi ya Kuhifadhi na Kurejesha Vaultwarden kwenye VPS

Kile ambacho nakala rudufu ya Vaultwarden lazima iwe nacho

Nakala rudufu ya Vaultwarden ni nakala ya folda nzima ya data, na database iliyo ndani yake lazima inakiliwe kwa njia sahihi. Tumia sqlite3 db.sqlite3 ".backup out.sqlite3" badala ya cp, kwa sababu kunakili database moja kwa moja wakati inaandikwa kunaweza kukupa faili ambayo haitafunguka. Kisha hifadhi faili zinazoandamana nayo. Hii ndiyo sehemu ambayo watu wengi husahau.

Kwenye usakinishaji wa Docker, folda ya data ni ile uliyoweka kwenye /data. Hii inaweza kuwa path kwenye host au named volume. tofauti kati ya bind mounts na named volumes huamua mahali vault yako halisi ilipo kwenye diski. Folda hiyo ina vitu vifuatavyo.

• db.sqlite3: kila akaunti, kila kipengee cha vault, kila folda na kila organisation. Ukipoteza faili hii, unapoteza vault.
• db.sqlite3-wal na db.sqlite3-shm: write-ahead log (WAL) na shared memory index yake. Maandishi ya hivi karibuni hubaki hapa hadi SQLite iyajumuishe kwenye faili kuu.
• attachments/: faili ambazo watumiaji waliambatisha kwenye vipengee vya vault, zikiwa zimesimbwa kwa njia fiche, katika folda moja kwa kila kipengee.
• sends/: faili zilizo nyuma ya viungo vya Bitwarden Send.
• config.json: kila setting uliyohifadhi kwenye ukurasa wa usimamizi.
• rsa_key.pem, pamoja na rsa_key.der na rsa_key.pub.der kwenye usakinishaji wa zamani: key inayotia sahihi login tokens.
• icon_cache/: icons za tovuti zilizopakuliwa. Hii ndiyo folda pekee unayoweza kuacha, kwa sababu Vaultwarden huzipakua tena inapozihitaji.

Je, hifadhidata yangu ya Vaultwarden iko salama? Faili hii ina nini hasa

Amri mbili zinajibu swali hilo, na unaweza kuziendesha zote sasa hivi.

sudo apt update && sudo apt install -y sqlite3
sudo sqlite3 /opt/vaultwarden/data/db.sqlite3 "select email from users;"
sudo sqlite3 /opt/vaultwarden/data/db.sqlite3 "select name from ciphers limit 1;"

Ya kwanza huchapisha anwani za barua pepe za watumiaji wako katika maandishi wazi. Ya pili huchapisha jina la kipengee kimoja, na huonekana hivi:

2.k9Qw1nQ0y7Yy2Xw==|E1r0J3l5s7d9f1g3h5j7k9==|Lm4nOp6qRs8tUv0wXy2zAb4cDe6fGh8i=

Majina ya vipengee, majina ya watumiaji, nywila na maelezo husimbwa na client kabla hayajatumwa, kwa hiyo seva huhifadhi ciphertext ambayo haiwezi kusoma. Kiambishi 2. ni aina ya usimbaji ya Bitwarden, kikifuatiwa na initialisation vector (IV), ciphertext na MAC (message authentication code), kila kimoja kikiwa katika base64 na kutenganishwa na |. Key inayofungua usimbaji huo hutokana na master password ya akaunti, ambayo haifiki kwenye seva ikiwa katika hali inayoweza kutumiwa. Sehemu hii ni ileile bila kujali kama unaendesha Vaultwarden au server rasmi, kama ulinganisho wa Vaultwarden na Bitwarden ya self-hosted unavyoeleza.

Sehemu iliyobaki ya hifadhidata haijasimbwa. Anwani za barua pepe, majina ya akaunti, vidokezo vya nywila na recovery codes za two-factor huhifadhiwa kama maandishi wazi, pamoja na metadata kama nyakati za kuunda na ni organisation gani inayomiliki kipengee. Kwa hiyo, faili ya backup yenyewe ni siri. Mtu yeyote aliye nayo hujua watumiaji wako ni akina nani, na anaweza kushambulia blobs zilizosimbwa offline kwa kasi yoyote inayoruhusiwa na hardware yake. Jambo hili moja ndilo linaloongoza sheria za storage zilizo hapa chini: nakala husimbwa kabla haijaondoka kwenye seva. Admin token ni nusu nyingine ya tatizo hilohilo, na hatua za kuimarisha usalama wa Vaultwarden ya self-hosted hushughulikia mambo yote mawili.

Kwa nini kunakili db.sqlite3 wakati Vaultwarden inaendelea kufanya kazi si nakala rudufu

Vaultwarden hutumia SQLite katika hali ya WAL kwa chaguo-msingi (ENABLE_DB_WAL=true). Uandishi huwekwa kwanza kwenye db.sqlite3-wal, na checkpoint pekee ndiyo huuingiza kwenye db.sqlite3. Ukifanyia nakala db.sqlite3 pekee, utapata hifadhidata ya wakati wa checkpoint ya mwisho. Kwa hiyo, nenosiri lililohifadhiwa dakika kumi zilizopita linaweza kukosekana kwenye kumbukumbu yako bila kuwepo kwa onyo lolote.

Kunakili faili zote tatu kwa kutumia cp pia si suluhisho. Nakala hizo huchukuliwa katika nyakati tofauti kidogo. Kwa hiyo, WAL uliyohifadhi inaweza kueleza matoleo ya kurasa ambayo hayalingani tena na faili kuu uliyohifadhi. SQLite kisha hujaribu kurejesha moja kwa kutumia nyingine, na matokeo huwa si sahihi. Utagundua tatizo hilo baadaye sana:

Error: database disk image is malformed

.backup huepuka tatizo hili kwa kutumia SQLite Online Backup API. SQLite inaeleza API hiyo kuwa njia ya kunakili hifadhidata ambayo inaweza kuwa inatumika. Husoma kurasa chini ya read lock. Ikiwa writer atabadilisha faili wakati wa mchakato, huanza tena. Kwa hiyo, kinachohifadhiwa kwenye diski ni hali moja thabiti ya wakati.

Chukua nakala ya database kwa sqlite3 .backup

sudo apt update && sudo apt install -y sqlite3
sudo install -d -m 700 /var/backups/vaultwarden
OUT=/var/backups/vaultwarden/db-$(date '+%Y%m%d-%H%M').sqlite3
sudo sqlite3 /opt/vaultwarden/data/db.sqlite3 ".backup '$OUT'"
sudo sqlite3 "$OUT" "PRAGMA integrity_check;"

Command ya mwisho huchapisha ok kwenye mstari wake. Matokeo mengine yoyote yanamaanisha kuwa nakala hiyo haiwezi kutumika. Usiihifadhi wala usifute nakala ya awali. Mfuatano mzima hutekelezwa dhidi ya server inayofanya kazi. Kwa hiyo, hakuna mtu anayelog out na hakuna container inayoanzishwa upya.

Tool ya sqlite3 haipo ndani ya Vaultwarden container. Image imejengwa kwenye debian:trixie-slim kwa kutumia ca-certificates, curl, libmariadb3, libpq5 na openssl. Kwa hiyo, docker exec vaultwarden sqlite3 ... hushindwa kwa kutoa:

exec: "sqlite3": executable file not found in $PATH

Iendeshe kwenye host dhidi ya path iliyomountiwa. Hivyo ndivyo commands zilizo hapo juu zinavyofanya. Ikiwa data iko kwenye named volume, docker volume inspect <name> huchapisha path ya host chini ya /var/lib/docker/volumes/.

Vaultwarden pia imetoa command yake ya backup tangu version 1.32.1. Kwenye server yako:

docker exec -it vaultwarden /vaultwarden backup

Command hiyo hutekeleza VACUUM INTO na huandika db_YYYYMMDD_HHMMSS.sqlite3 kwenye data folder. Mambo mawili yanafuata. Nakala huwekwa karibu na ya awali kwenye disk hiyo hiyo. Kwa hiyo, hii ni hatua ya staging, wala bado si backup. Pia inatumika kwa SQLite pekee. Kwenye MariaDB au PostgreSQL, husimama na The database type is not SQLite. Backups only works for SQLite databases.

Mafaili ambayo watu husahau

attachments/ huhifadhi ciphertext chini ya majina yasiyoeleza yaliyomo. Safu ya database ya kila attachment ina jina la faili lililosimbwa kwa njia fiche na key material ambayo client anahitaji ili kufungua faili hilo. Attachments bila database haziwezi kusomeka, na database bila attachments huwapa watumiaji vipengee ambavyo upakuaji wake hushindwa. Chukua vyote viwili katika run moja.

config.json huhifadhi kila kitu ulichosave kutoka admin page, na thamani zake hutangulia environment variables zinazolingana. Hili lina athari pande zote mbili: kurejesha config.json ya zamani hubadilisha bila taarifa settings zilizo kwenye compose file, na faili yenyewe ni nyeti kwa sababu inaweza kuwa na SMTP password na admin token yako. Hifadhi token hiyo kama string ya Argon2id PHC (password hashing competition), badala ya plain text. docker run --rm -it vaultwarden/server /vaultwarden hash hukuchapishia moja.

rsa_key.pem husaini JSON web tokens (JWT) zinazowafanya clients wabaki wameingia. Ikiwa faili haipo wakati wa kuanza, Vaultwarden hutengeneza key mpya. Kwa hiyo, kila token iliyosainiwa na key ya zamani huacha kuthibitishwa, na clients wote hutolewa kwenye akaunti. Vault contents hubaki salama kwa sababu zimesimbwa kwa keys zinazotokana na master password. Kurejesha key file huepuka kuwatoa watumiaji wote kwenye akaunti.

sends/ huhifadhi mafaili yaliyo nyuma ya Send links. Kukosekana kwa mafaili hayo huvunja upakuaji huo pekee, bila kuathiri kitu kingine.

Weka kila kitu katika script moja

#!/bin/bash
set -euo pipefail

DATA=/opt/vaultwarden/data
DEST=/var/backups/vaultwarden
STAMP=$(date '+%Y%m%d-%H%M%S')
STAGE=$(mktemp -d /tmp/vw-stage.XXXXXX)

install -d -m 700 "$DEST"
sqlite3 "$DATA/db.sqlite3" ".backup '$STAGE/db.sqlite3'"
test "$(sqlite3 "$STAGE/db.sqlite3" 'PRAGMA integrity_check;')" = "ok"
cp -a "$DATA"/rsa_key* "$STAGE/"
for extra in config.json attachments sends; do
  if [ -e "$DATA/$extra" ]; then cp -a "$DATA/$extra" "$STAGE/"; fi
done
tar -C "$STAGE" -czf "$DEST/vw-$STAMP.tar.gz" .
chmod 600 "$DEST/vw-$STAMP.tar.gz"
rm -rf "$STAGE"
tar -tzf "$DEST/vw-$STAMP.tar.gz"

Ihifadhi kama /usr/local/sbin/vw-backup.sh, ipe ruhusa ya kutekelezwa kwa chmod 700, kisha iendeshe kama root. Mstari wa test unafanya kazi muhimu: sqlite3 hutoka kwa hali 0 hata wakati PRAGMA integrity_check inaripoti uharibifu. Kwa hiyo, kulinganisha matokeo na ok ndiko kunakofanya nakala mbaya isababishe script ishindwe. Kisha set -euo pipefail husimamisha kila kitu, badala ya kuruhusu tar itengeneze archive iliyopangika kuzunguka database iliyoharibika.

tar -tzf ya mwisho huorodhesha data uliyokusanya kwa kweli. Isome mara ya kwanza unapoiendesha. Unatafuta ./db.sqlite3, ./rsa_key.pem, ./config.json na ./attachments/, pamoja na kutokuwepo kwa ./db.sqlite3-wal. Iendeshe kila usiku kwa kutumia service na timer ya systemd badala ya cron ikiwa unataka journalctl ya matokeo na unit inayoonyesha failure.

Thibitisha nakala rudufu kwa kuirejesha kwenye saraka ya muda

Nakala rudufu ambayo haijajaribiwa ni makisio. Kuirejesha kwenye saraka ya muda huchukua dakika moja na hakugusi chochote kinachoendelea kutumika.

sudo install -d -m 700 /tmp/vw-check
sudo tar -C /tmp/vw-check -xzf /var/backups/vaultwarden/vw-20260805-030000.tar.gz
ls -l /tmp/vw-check
sudo sqlite3 /tmp/vw-check/db.sqlite3 "PRAGMA integrity_check;"
sudo sqlite3 /tmp/vw-check/db.sqlite3 "select count(*) from users;"
sudo sqlite3 /tmp/vw-check/db.sqlite3 "select count(*) from ciphers;"
sudo du -sh /tmp/vw-check/attachments

Matokeo manne ni muhimu. integrity_check huchapisha ok. Idadi ya watumiaji inalingana na idadi ya akaunti unazozijua. Idadi ya cipher inakaribia thamani ya moja kwa moja kutoka sudo sqlite3 /opt/vaultwarden/data/db.sqlite3 "select count(*) from ciphers;", na haiwezi kuwa sifuri kwenye vault inayotumika. Saraka ya attachments ina ukubwa unaokaribia unaotarajia. Unaweza kuruka ukaguzi huu ikiwa hakuna anayepakia attachments. Kisha endesha sudo rm -rf /tmp/vw-check, kwa sababu saraka hiyo sasa ina nakala ya pili ya kila kitu.

Kuna kanuni moja unaporejesha saraka yoyote ya data iliyonakiliwa kwa mkono: futa db.sqlite3-wal na db.sqlite3-shm kabla ya kuanzisha server. Vinginevyo, SQLite itajaribu kurejesha database iliyorejeshwa kwa kutumia logi inayohusiana na nakala nyingine yake. Hilo huharibu database iliyofika ikiwa salama. Archives zilizoundwa na script iliyo hapo juu huwa hazina mafaili hayo, kwa sababu .backup huandika database moja kamili.

Rejesha kwenye seva

Tekeleza amri hizi kwenye seva yako mwenyewe, huku container ikiwa imesimamishwa. Vaultwarden haipaswi kuandika wakati folder ya data inabadilishwa chini yake.

cd /opt/vaultwarden
docker compose stop vaultwarden
sudo mv data data.old.$(date '+%Y%m%d-%H%M%S')
sudo install -d -m 700 data
sudo tar -C data -xzf /var/backups/vaultwarden/vw-20260805-030000.tar.gz
sudo chown -R root:root data
docker compose start vaultwarden
docker compose logs --tail 20 vaultwarden

chown lazima itaje user ambaye container inaendesha kama. Image ya kawaida huendesha kama root, kwa hiyo root:root inafaa isipokuwa umeweka user: kwenye compose file yako. Katika hali hiyo, tumia uid na gid hiyo. Folder ya data ambayo seva haiwezi kuiandikia husababisha ukurasa wa kuingia ukatae kila ombi. Logs zitaonyesha sababu hiyo.

Uanzishaji wenye afya huisha kwa mstari wa Rocket:

[INFO] Rocket has launched from http://0.0.0.0:80

Kisha ingia kupitia browser, fungua item moja, na upakue attachment moja. Kuingia kunapofaulu lakini download za attachments zikashindikana, hiyo inamaanisha archive ilikuwa na database lakini haikuwa na attachments/. Weka data.old.* hadi kila kitu hiki kithibitishwe, kisha uifute. Kurudisha hali ya awali kunafuata hatua hizo hizo tatu, lakini directories hubadilishwa kwa mwelekeo mwingine.

Ikiwa paths zako hazilingani na zilizo hapa, mwongozo wa kusakinisha Vaultwarden kwenye VPS unaonyesha compose file ambayo amri hizi zinategemea.

Mahali ambapo hupaswi kuweka hifadhi rudufu

• Si kwenye diski hiyo hiyo iliyo na folda ya data. Volumu moja ikifeli, nakala zote mbili hupotea; hali hiyo hutokea pia kwa rm -rf moja kwenye path isiyo sahihi.
• Si kwenye seva hiyo hiyo, hata ikiwa iko kwenye volumu ya pili. Mshambulizi anayefikia root hufikia pia hifadhi rudufu zako katika session hiyo hiyo.
• Si kwenye object storage bila encryption, kwa sababu archive ina anwani za barua pepe, vidokezo vya password, recovery codes na vault ciphertext ambazo zinaweza kushambuliwa offline.
• Si katika snapshots za provider wako pekee. Hurejeshwa haraka, jambo ambalo ni muhimu, lakini ziko kwenye account hiyo hiyo na seva. Tatizo la account huiathiri pia.

Nakala ya offsite ndipo restic inapofaa, kwa sababu repository ya restic husimbwa kwa encryption kwenye mashine kabla ya chochote kupakiwa. Kwenye seva yako:

sudo apt install -y restic
export RESTIC_REPOSITORY=s3:https://s3.example.com/vaultwarden-backups
export RESTIC_PASSWORD_FILE=/root/.restic-password
restic init
restic backup /var/backups/vaultwarden --tag vaultwarden
restic snapshots --tag vaultwarden
restic forget --tag vaultwarden --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

Elekeza restic kwenye directory ya archive, si kwenye live data folder, ili kinachopakiwa kiwe nakala thabiti ambayo tayari umeikagua. Weka password ya repository mahali pengine, si kwenye seva inayolindwa nayo: ukipoteza password hiyo, snapshots hazitasomeka, kwa muundo wa mfumo. Ikiwa storage inaunga mkono hilo, ipatie seva credentials zenye ruhusa ya kuandika lakini si kufuta, ili compromise ya mashine isiweze kufuta historia yake yenyewe. Kusanidi hifadhi rudufu za restic kwenye VPS inaeleza repository na schedule kwa ukamilifu, na restic ikilinganishwa na BorgBackup inaeleza uchaguzi huo ikiwa bado hujaufanya.

Jaribu kurejesha kwenye ratiba

Chagua siku moja kila mwezi. Vuta snapshot mpya zaidi kwenye directory ya majaribio kwa kutumia restic restore latest --tag vaultwarden --target /tmp/vw-check, endesha PRAGMA integrity_check ileile, endesha row counts zilezile, kisha andika tarehe na counts. Backup ambayo haijawahi kurejeshwa kwa miezi sita iko katika hali isiyojulikana, na utajifunza hali yake wakati wa outage, ambao ndio wakati mbaya zaidi wa kujifunza hilo.

Mara moja kwa mwaka, fanya toleo kamili. Anzisha container ya pili ya Vaultwarden kwenye port ya ziada ukitumia data folder iliyorejeshwa, kisha ingia kwa account halisi. Hilo linathibitisha mchakato wa master password kutoka mwanzo hadi mwisho, jambo ambalo row count haiwezi kufanya. restic check --read-data-subset=10% kwenye ratiba hiyo hiyo huthibitisha kwamba data iliyohifadhiwa inaweza kusomeka badala ya kuorodheshwa tu.

FAQ

Je, ninaweza kunakili db.sqlite3 kwa kutumia cp wakati Vaultwarden inaendelea kufanya kazi?

Hapana. Vaultwarden hutumia SQLite katika hali ya WAL, kwa hiyo maandishi ya hivi karibuni huwa kwenye db.sqlite3-wal na bado hayajawekwa kwenye db.sqlite3. cp ya faili kuu pekee huyapoteza kimya kimya, na kunakili faili hizo mbili kando kunaweza kuacha jozi isiyolingana ambayo baadaye hujitokeza kama Error: database disk image is malformed. Tumia sqlite3 /path/db.sqlite3 ".backup '/path/out.sqlite3'" badala yake. Hutumia SQLite Online Backup API na hutengeneza faili moja thabiti huku seva ikiendelea kutoa huduma.

Je, ni lazima nisitishe Vaultwarden container ili kutengeneza backup?

Hapana, na huo ndio umuhimu wa .backup. Kunakili database ni salama kwenye seva inayoendelea kufanya kazi. Attachments na Send files huandikwa mtumiaji anapopakia faili, kwa hiyo faili iliyoongezwa kati ya kunakili database na tar inaweza kukosekana kwenye archive ya usiku huo. Kwa hali hiyo, unaweza kupoteza attachment moja tu. Ikiwa sekunde chache za downtime si tatizo, docker compose stop kabla ya script na docker compose start baada yake huondoa hata uwezekano huo.

Nini hutokea nikirejesha bila files za rsa_key?

Vaultwarden hutengeneza key mpya wakati wa startup. Key hiyo husaini JSON web tokens (JWT) zinazoweka sessions zikiwa hai, kwa hiyo token zote zilizopo hushindwa kuthibitishwa na clients zote hutolewa kwenye akaunti, kisha lazima ziingie tena. Yaliyomo kwenye vault hayaathiriki, kwa sababu yamesimbwa kwa keys zinazotokana na master password ya kila mtumiaji badala ya RSA key. Rejesha rsa_key.pem pamoja na data folder yote, na hakuna mtu atakayegundua kuwa restore imefanyika.

Je, backup archive iko salama kupakiwa kwenye object storage bila kubadilishwa?

Hapana. Majina ya vitu, passwords na notes ni ciphertext, lakini email addresses, account names, password hints na two-factor recovery codes ziko plain text kwenye database. Mshambulizi anayefanya mashambulizi offline anaweza kujaribu ciphertext hiyo kwa kasi yake mwenyewe. Simba archive kwa encryption kabla haijaondoka kwenye mashine. restic repository hufanya hivyo kwa ajili yako, na gpg --symmetric --cipher-algo AES256 vw-20260805-030000.tar.gz hutengeneza faili moja iliyosimbwa unayoweza kuikabidhi kwa storage yoyote.

Ninawezaje kufanya backup ya Vaultwarden kwenye PostgreSQL au MariaDB?

Hatua za SQLite hazitumiki, na built-in command hukataa kwa The database type is not SQLite. Backups only works for SQLite databases. Fanya dump ya database kwa kutumia native tool yake, pg_dump au mysqldump, kisha fuata sheria nyingine zote kama zilivyo. Dump hiyo iwe kwenye archive moja pamoja na attachments/, sends/, config.json na files za rsa_key. Zichukuliwe katika run hiyo hiyo, zisimbwe kwa encryption, na zihifadhiwe mahali tofauti na seva iliyotengeneza backup.