Environment
- ConvertX v0.18.0,
ghcr.io/c4illin/convertx:v0.18.0, the compose file from the
README, /app/data on a volume, JWT_SECRET set.
What I did
Registered the first account, loaded the page, uploaded a file. Then restored two ways
into a fresh instance: the whole /app/data directory, and mydb.sqlite on its own.
What I observed
The directory restores everything - the account, the job, the uploaded file, and a
sign-in that works.
mydb.sqlite alone restores an instance where POST /login answers 403. Two
separate reasons:
-
The rows were in the write-ahead log. After registering one account and uploading one
file:
-rw-r--r-- 20480 mydb.sqlite
-rw-r--r-- 32768 mydb.sqlite-shm
-rw-r--r-- 16512 mydb.sqlite-wal
so a copy of mydb.sqlite is a copy of the database as it was at the last
checkpoint.
-
The uploaded and converted files are not in the database at all - they are in
uploads/<user>/<job>/ and output/<user>/<job>/, and the jobs rows point at them
by user and job id.
Because only the first account can register, the restored instance is then sitting on
the setup page waiting for whoever reaches it first - which the README already warns
about in a different context ("Don't leave it unconfigured and open, as anyone can
register the first account").
Suggested change
One line under Deployment:
Back up the whole data directory. It holds mydb.sqlite - together with its -wal
file, where recent rows live until SQLite checkpoints them - and the uploads/ and
output/ directories holding the files your conversion jobs refer to. Copying
mydb.sqlite alone gives you an instance you cannot log in to.
I would be glad to send a README PR with that. Thank you for ConvertX - the deployment
is one compose file and one volume, which is exactly why the one line is worth having.
Everything above, with the commands and the unedited output, is at https://github.com/spelingbee/drillback/tree/main/docs/drill/convertx - one leg of a restore drill across fifteen self-hosted applications, each one following its own backup documentation as written.
Environment
ghcr.io/c4illin/convertx:v0.18.0, the compose file from theREADME,
/app/dataon a volume,JWT_SECRETset.What I did
Registered the first account, loaded the page, uploaded a file. Then restored two ways
into a fresh instance: the whole
/app/datadirectory, andmydb.sqliteon its own.What I observed
The directory restores everything - the account, the job, the uploaded file, and a
sign-in that works.
mydb.sqlitealone restores an instance wherePOST /loginanswers 403. Twoseparate reasons:
The rows were in the write-ahead log. After registering one account and uploading one
file:
so a copy of
mydb.sqliteis a copy of the database as it was at the lastcheckpoint.
The uploaded and converted files are not in the database at all - they are in
uploads/<user>/<job>/andoutput/<user>/<job>/, and thejobsrows point at themby user and job id.
Because only the first account can register, the restored instance is then sitting on
the setup page waiting for whoever reaches it first - which the README already warns
about in a different context ("Don't leave it unconfigured and open, as anyone can
register the first account").
Suggested change
One line under Deployment:
I would be glad to send a README PR with that. Thank you for ConvertX - the deployment
is one compose file and one volume, which is exactly why the one line is worth having.
Everything above, with the commands and the unedited output, is at https://github.com/spelingbee/drillback/tree/main/docs/drill/convertx - one leg of a restore drill across fifteen self-hosted applications, each one following its own backup documentation as written.