VPS-ல் Paperless-ngx நிறுவுவது எப்படி: முழுமையான வழிகாட்டி

நீங்கள் உருவாக்குவது என்ன

VPS-ல் இயங்கும் Paperless-ngx, ஸ்கேன் செய்யப்பட்ட ஆவணங்களின் தொகுப்பை தேடக்கூடிய காப்பகமாக மாற்றுகிறது. நீங்கள் ஒரு PDF-ஐ குறிப்பிட்ட directory-ல் பதிவேற்றினால், server அதில் OCR (optical character recognition) செய்து, உரையை பிரித்தெடுத்து, தேதி மற்றும் தொடர்புடைய நபரை ஊகித்து, கோப்புகளை வகைப்படுத்தும். இந்த நிறுவல் நான்கு services-ஐக் கொண்ட ஒரு Docker Compose கோப்பாகும். இதற்குப் பிந்தைய அனைத்தும் configuration சார்ந்தவை; இந்த வழிகாட்டியின் பெரும்பகுதி இதற்கே ஒதுக்கப்பட்டுள்ளது, ஏனெனில் நிறுவல்கள் பெரும்பாலும் இங்குதான் தோல்வியடைகின்றன. இது புகைப்படங்களுக்கான library அல்ல: OCR மற்றும் correspondent guessing போன்றவை புகைப்படங்களுக்குப் பயன்படாது, எனவே அவற்றை புகைப்படங்களுக்காகவே உருவாக்கப்பட்ட server-ல் சேமித்து, காகித ஆவணங்களுக்கு மட்டும் Paperless-ஐப் பயன்படுத்தவும்.

Paperless-ngx என்பது அசல் Paperless project-ன் பராமரிக்கப்படும் community fork ஆகும். இது இலவசமானது, self-hosted ஆக இயங்குகிறது, மேலும் உங்கள் documents-ஐ disk-ல் plain files ஆக சேமிக்கிறது. எனவே உங்கள் சொந்த archive-க்கான அணுகல் உங்களிடமிருந்து ஒருபோதும் பறிக்கப்படாது. இதை வீட்டிலுள்ள computer-க்கு பதிலாக VPS-ல் இயக்கினால், home router-ல் port திறக்காமல் எங்கிருந்தும் உங்கள் scans-ஐ அணுகலாம். மேலும், paper அல்லாத files-க்கான private Nextcloud instance உடன் இதை நன்றாக இணைத்துப் பயன்படுத்தலாம். உங்கள் scanner இணைக்கப்பட்டுள்ள desktop-க்கும் இதே அணுகுமுறை பொருந்தும். அந்த machine-ஐ வேறு இடத்திலிருந்து இயக்க, router-ல் port திறக்காமல், அந்த VPS-ல் உங்களுக்கென அமைத்த RustDesk relay போதுமானது.

இந்த stack உண்மையில் எதை இயக்குகிறது

அதிகாரப்பூர்வ compose கோப்பு நான்கு containers-ஐத் தொடங்குகிறது. ஒவ்வொன்றும் என்ன செய்கிறது என்பதைத் தெரிந்துகொள்வது, logs-ஐப் புரிந்துகொள்ள உதவும்.

• webserver: paperless-ngx image. இது web interface, API, உங்கள் input folder-ஐக் கண்காணிக்கும் consumer மற்றும் OCR செய்யும் Celery task workers ஆகியவற்றை இயக்குகிறது.
• db: PostgreSQL. இது metadata, tags, correspondents மற்றும் full-text search index அட்டவணைகளைச் சேமிக்கிறது. இது உங்கள் PDF கோப்புகளைச் சேமிப்பதில்லை.
• broker: Valkey, இது Redis-உடன் இணக்கமான key-value store. இது web process மற்றும் workers-க்கு இடையிலான task queue ஆகும்.
• gotenberg மற்றும் tika: இவை விருப்பத்தேர்வு, -tika compose வகைகளில் மட்டுமே இருக்கும். இவை Office ஆவணங்களை (.docx, .xlsx, .odt) PDF-ஆக மாற்றுகின்றன, அப்போதுதான் paperless அவற்றை index செய்ய முடியும்.

ஜூலை 2026 நிலவரப்படி, postgres compose கோப்பு docker.io/library/postgres:18 மற்றும் docker.io/valkey/valkey:9-alpine ஆகியவற்றை pin செய்கிறது, மேலும் ghcr.io/paperless-ngx/paperless-ngx:latest-லிருந்து app-ஐப் பெறுகிறது.

முன்நிபந்தனைகள்

• sudo அணுகல் கொண்ட Ubuntu 24.04 KVM VPS மற்றும் ஏற்கனவே நிறுவப்பட்ட Docker Compose plugin. இது உங்களுக்குப் புதியது என்றால், முதலில் VPS-க்கான Docker Compose அடிப்படைகள் என்பதைப் படித்துவிட்டு மீண்டும் வரவும்.
• உங்கள் VPS-ஐச் சுட்டிக்காட்டும் A record கொண்ட ஒரு domain name. தனக்குத் தெரியாத hostname-ல் இயங்க Paperless மறுத்துவிடும் என்பதால், இது நீங்கள் எதிர்பார்ப்பதை விட முன்னதாகவே முக்கியமாகிறது.
• நினைவகம் (Memory) தான் உண்மையான கட்டுப்பாடு. PostgreSQL, Valkey, gunicorn மற்றும் Tesseract OCR worker ஆகிய அனைத்தும் ஒரே நேரத்தில் இயங்க, குறைந்த பயன்பாட்டிற்கு 2 GB போதுமானது. நீங்கள் நூற்றுக்கணக்கான ஸ்கேன் செய்யப்பட்ட கோப்புகளை இறக்குமதி செய்யத் திட்டமிட்டால் 4 GB நினைவகத்தை ஒதுக்கவும்; ஏனெனில் பெரிய multi-page PDF கோப்புகளில் OCR செய்யும்போது ஏற்படும் நினைவகத் தேவை, kernel-ன் out-of-memory killer மூலம் worker-ஐ நிறுத்தச் செய்துவிடும்.
• வட்டு (Disk): உங்கள் ஆவணங்கள் இரண்டு முறை சேமிக்கப்படும்; அசல் கோப்பு மற்றும் OCR செய்யப்பட்ட archive PDF. எனவே, உங்கள் ஸ்கேன் கோப்புகளின் அளவைப் போல இருமடங்கு வட்டு இடத்தை ஒதுக்கீடு செய்யவும்.

அதிகாரப்பூர்வ compose கோப்புகளைப் பெறுதல்

இதற்கென ஒரு interactive installer உள்ளது:

bash -c "$(curl --location --silent --show-error https://raw.githubusercontent.com/paperless-ngx/paperless-ngx/main/install-paperless-ngx.sh)"

இது உங்களிடம் கேள்விகளைக் கேட்டு, உங்களுக்காகக் கோப்புகளை உருவாக்கும். நீங்களாகவே கைகளால் செய்வது நான்கு கட்டளைகளை உள்ளடக்கியது; இது உங்கள் server-ல் உள்ள அனைத்தும் எங்குள்ளது என்பதைத் தெளிவாகப் புரிந்துகொள்ள உதவும், பராமரிப்புப் பணிகளுக்கு இதுவே சிறந்தது.

mkdir -p ~/paperless && cd ~/paperless
curl -fsSL -o docker-compose.yml https://raw.githubusercontent.com/paperless-ngx/paperless-ngx/main/docker/compose/docker-compose.postgres.yml
curl -fsSL -o docker-compose.env https://raw.githubusercontent.com/paperless-ngx/paperless-ngx/main/docker/compose/docker-compose.env
curl -fsSL -o .env https://raw.githubusercontent.com/paperless-ngx/paperless-ngx/main/docker/compose/.env

இதன் பல்வேறு வகைகள் ஒரே directory-ல் உள்ளன: docker-compose.sqlite.yml, docker-compose.mariadb.yml, மற்றும் ஒவ்வொன்றிலும் ஒரு -tika பதிப்பு. புதிய நிறுவலுக்கு (install) postgres-ஐத் தேர்ந்தெடுக்கவும். சில நூறு ஆவணங்களுக்கு SQLite போதுமானது, ஆனால் PostgreSQL-ஐ விட இதில் full-text search index மெதுவாகச் செயல்படும்.

.env கோப்பில் ஒரே ஒரு வரி மட்டுமே இருக்கும், அது COMPOSE_PROJECT_NAME=paperless. அந்தப் பெயரே ஒவ்வொரு container மற்றும் volume-க்கும் prefix-ஆக அமையும், எனவே அதை நீக்கிவிட்டு, ஏன் docker compose down -v உங்கள் தரவைக் கண்டறிய முடியவில்லை என்று குழப்பமடைய வேண்டாம்.

முதல் முறை தொடங்குவதற்கு முன் docker-compose.env-ஐ உள்ளமைக்கவும்

இரண்டு அமைப்புகள் கட்டாயமானவை. திட்ட ஆவணத்தில் குறிப்பிடப்பட்டுள்ள கட்டளையைப் பயன்படுத்தி secret key-ஐ உருவாக்கவும்:

python3 -c "import secrets; print(secrets.token_urlsafe(64))"

பின்பு docker-compose.env-ஐத் திருத்தவும்:

PAPERLESS_SECRET_KEY=<the long string you just generated>
PAPERLESS_URL=https://paperless.example.com
PAPERLESS_TIME_ZONE=Europe/Berlin
PAPERLESS_OCR_LANGUAGE=deu+eng
USERMAP_UID=1000
USERMAP_GID=1000

PAPERLESS_SECRET_KEY என்பது change-me என்ற literal மதிப்பைக் கொண்டுள்ளது. இது session cookies-ஐ கையொப்பமிடுகிறது (sign), எனவே இதை மாற்றாமல் விட்டால், இயல்புநிலை மதிப்பைத் தெரிந்த எவரும் session-ஐப் போலியாக உருவாக்க முடியும். முதல் முறை தொடங்குவதற்கு முன்பே இதை அமைக்கவும், ஏனெனில் பிறகு மாற்றினால் அனைத்து பயனர்களும் வெளியேற்றப்படுவார்கள் (log out).

PAPERLESS_URL என்பது உங்கள் நேரத்தை மிச்சப்படுத்தும் ஒரு அமைப்பாகும். Paperless என்பது ஒரு Django application ஆகும், மேலும் Django ஒவ்வொரு கோரிக்கையின் Host header-ஐயும் சரிபார்க்கிறது. PAPERLESS_URL-ஐ அமைத்தால், அது தானாகவே ALLOWED_HOSTS, CORS_ALLOWED_HOSTS மற்றும் CSRF_TRUSTED_ORIGINS ஆகியவற்றை நிரப்புகிறது. இதை காலியாக விட்டுவிட்டு, ஒரு domain-ஐ server-க்குச் சுட்டிக்காட்டினால், ஒவ்வொரு பக்கமும் Bad Request (400) பிழையைத் தரும், மேலும் container log-ல் DisallowedHost என்ற பிழை பதிவாகும். இதை எழுதும் போது இறுதியில் slash (/) இல்லாமல் மற்றும் path இல்லாமல் எழுதவும்.

USERMAP_UID மற்றும் USERMAP_GID ஆகியவை container எந்த பயனர் கணக்கில் இயங்க வேண்டும் என்பதைத் தீர்மானிக்கின்றன. இவற்றை உங்கள் சொந்த கணக்குடன் பொருத்தவும்; இதை id -u மற்றும் id -g கட்டளைகள் மூலம் சரிபார்க்கலாம். இவை பொருந்தவில்லை என்றால், நீங்கள் consume folder-க்குள் நகலெடுக்கும் கோப்புகளை consumer-ஆல் படிக்க முடியாது, மேலும் log-ல் import பிழைக்கு பதிலாக permission பிழை தோன்றும்.

Stack-ஐத் தொடங்கி முதல் பயனரை உருவாக்கவும்

docker compose pull
docker compose up -d
docker compose run --rm webserver createsuperuser
docker compose logs -f webserver

createsuperuser ஒரு username, email மற்றும் password-ஐக் கேட்கும். இதில் default login எதுவும் இல்லை, எனவே இந்த நிலையைத் தவிர்த்தால், எதையும் ஏற்காத ஒரு sign-in பக்கத்தில் நீங்கள் இருப்பீர்கள். Browser-ல் முயற்சிக்கும் முன், server port 8000-ல் listening நிலையில் இருப்பதாக log-ல் வரும் வரை காத்திருக்கவும். முதல்முறை தொடங்கும் போது database migrations நடைபெறும், இதற்கு ஒன்று அல்லது இரண்டு நிமிடங்கள் ஆகலாம்.

Domain-ஐ இணைக்கும் முன் உள்ளூர் அளவில் சரிபார்க்கவும்:

curl -I http://127.0.0.1:8000

302-லிருந்து /accounts/login/-க்கு redirect ஆவது, stack சரியாக இயங்குவதைக் குறிக்கிறது.

இதற்கு முன்னால் HTTPS-ஐ அமைக்கவும்

வழக்கமான compose file 8000:8000-ஐ வெளியிடுகிறது, இது அனைத்து interface-களிலும் இணைகிறது. பொதுவான VPS-ல் இது உங்கள் முழு ஆவணக் காப்பகத்தையும் plain HTTP மூலம், முகவரியைக் கண்டறியும் எவருக்கும் வழங்குகிறது. Port வரியை loopback-ல் மட்டும் இணைக்கும்படி மாற்றவும்:

    ports:
      - "127.0.0.1:8000:8000"

பின்பு, ஒரு reverse proxy-ல் TLS (transport layer security)-ஐ முடித்துவிட்டு, 127.0.0.1:8000-க்கு அனுப்பவும். இந்த server-ல் இது மட்டுமே இயங்கும் application என்றால், ACME (automatic certificate management environment) client கொண்ட எந்த proxy-யும் போதுமானது. ஒரே certificate அமைப்பின் கீழ் பல container-களை இயக்கினால், பல Docker Compose application-களுக்கான Traefik reverse proxy முறையைப் பின்பற்றவும். மேலும், webserver service-ஐ எந்த port-ம் வெளியிடாமல் proxy network-உடன் இணைக்கவும்.

நீங்கள் எந்த proxy-யைப் பயன்படுத்தினாலும், அது X-Forwarded-Proto: https-ஐ அனுப்ப வேண்டும். இது இல்லையெனில், கோரிக்கை HTTP வழியாக வந்ததாக Django கருதும். இதனால் login form-ல் உள்ள origin check தோல்வியடைந்து, சரியாகத் தோன்றும் பக்கத்தில் CSRF verification failed. Request aborted. பிழையைப் பெறுவீர்கள். இந்தத் தீர்வின் மற்றொரு பகுதி, PAPERLESS_URL-ஐ நீங்கள் browser-ல் தட்டச்சு செய்யும் சரியான https:// முகவரிக்கு அமைப்பதாகும்.

மேலும், proxy-ன் upload size limit-ஐ அதிகரிக்கவும். 40 MB அளவுள்ள scan, 1 MB வரை மட்டுமே அனுமதிக்கும் proxy வழியாக வரும்போது, paperless-க்குச் செல்லும் முன்பே நிராகரிக்கப்படும். இதனால் browser ஒரு பொதுவான upload failure பிழையைக் காட்டும்.

consume directory எவ்வாறு செயல்படுகிறது

Compose file, ./consume-ஐ compose directory-யிலிருந்து container-க்குள் bind-mount செய்கிறது. நீங்கள் அங்கு வைக்கும் எந்தவொரு கோப்பும் இறக்குமதி செய்யப்பட்டு, அந்த கோப்புறையிலிருந்து நீக்கப்படும். ஏனெனில், அந்த கோப்பு இப்போது paperless நிர்வாகத்தின் கீழ் உள்ள media volume-ல் சேமிக்கப்பட்டுவிடும்.

cp ~/scan-2026-07-14.pdf ~/paperless/consume/
docker compose logs -f webserver

Consumer கோப்பின் பெயரை எடுத்துக்கொண்டு, OCR-ஐ இயக்கி, ஆவணம் சேர்க்கப்பட்டதை உறுதிப்படுத்தும் வரியுடன் முடிப்பதை நீங்கள் காணலாம். ஒரு பக்க ஸ்கேனிற்கு இந்த முழு சுழற்சியும் சில நொடிகள் ஆகும், நீண்ட ஆவணங்களுக்கு ஒரு நிமிடம் அல்லது அதற்கு மேல் ஆகலாம்.

கோப்புகள் கண்டறியப்படும் விதத்தை இரண்டு அமைப்புகள் மாற்றுகின்றன. PAPERLESS_CONSUMER_RECURSIVE=true, paperless-ஐ subfolders-க்குள் தேட வைக்கிறது. PAPERLESS_CONSUMER_SUBDIRS_AS_TAGS=true, ஒவ்வொரு subfolder பெயரையும் ஒரு tag-ஆக மாற்றுகிறது. எனவே, ஒரு கோப்பை consume/invoices/2026/-க்குள் போட்டால், அது invoices மற்றும் 2026 என tag செய்யப்படும். இது நீங்கள் உருவாக்கக்கூடிய மிக எளிமையான கோப்பு மேலாண்மை முறையாகும்.

கண்டறிதல் என்பது மற்றொரு பகுதி. இயல்பாக PAPERLESS_CONSUMER_POLLING_INTERVAL என்பது 0 என இருக்கும். அதாவது, paperless kernel filesystem அறிவிப்புகளைப் பயன்படுத்துகிறது, இவை உடனடியாகச் செயல்படும். அந்த அறிவிப்புகள் network filesystem-ஐத் தாண்டிச் செயல்படாது. உங்கள் consume folder ஒரு NFS அல்லது SMB share-ஆக இருந்து, ஒரு network scanner அதில் கோப்புகளை எழுதினால், அவை கண்டறியப்படாது. இதற்கான தீர்வு, interval-ஐ ஒரு நேர்மறை வினாடி எண்ணாக அமைப்பதாகும்; அப்போதுதான் paperless அந்த கோப்புறையைத் தொடர்ந்து ஸ்கேன் செய்யும்.

OCR மொழிகள் மற்றும் அவற்றின் செலவுகள்

PAPERLESS_OCR_LANGUAGE ஒரு மூன்று எழுத்து Tesseract குறியீட்டை எடுத்துக்கொள்கிறது, இயல்பாக eng பயன்படுத்தப்படுகிறது. மொழிகளை இணைக்க பிளஸ் குறியீட்டைப் பயன்படுத்தவும், உதாரணமாக deu+eng. Tesseract ஒவ்வொரு மொழியையும் முயற்சி செய்து சிறந்த முடிவைத் தக்கவைக்கும், எனவே ஒவ்வொரு கூடுதல் மொழியும் ஒவ்வொரு பக்கத்திலும் செலவிடப்படும் CPU நேரத்தை பலமடங்கு அதிகரிக்கும். பகிரப்பட்ட vCPU கொண்ட VPS-ல், இது ஒரு ஸ்கேன் பத்து வினாடிகளில் முடிவதற்கும் ஒரு நிமிடத்தில் முடிவதற்கும் உள்ள வித்தியாசமாகும். உங்கள் ஆவணங்கள் எந்த மொழிகளில் எழுதப்பட்டுள்ளனவோ, அந்த மொழிகளை மட்டும் பட்டியலிடுங்கள்.

இந்த image-ல் English, German, Italian, Spanish மற்றும் French ஆகிய மொழிகள் உள்ளன. வேறு ஏதேனும் தேவைப்பட்டால், அந்த மொழியை PAPERLESS_OCR_LANGUAGES-ல் இடைவெளியால் பிரிக்கப்பட்ட பட்டியலாகச் சேர்க்கவும், உதாரணமாக PAPERLESS_OCR_LANGUAGES=tur ces, பிறகு restart செய்யவும். container தொடங்கும் போது Tesseract தரவுப் பொதிகளை (data packs) பதிவிறக்கம் செய்யும், எனவே அந்த மாற்றத்திற்குப் பிறகு நடக்கும் முதல் boot மெதுவாக இருக்கும்.

Database மற்றும் media-வை பேக்அப் செய்தல்

PostgreSQL இயங்கிக்கொண்டிருக்கும்போது Docker volumes-ஐ நகலெடுப்பது, சரியாக restore ஆகாத பேக்அப்-ஐ உருவாக்கலாம். Paperless-ல் இதற்கென பிரத்யேக exporter உள்ளது. இது ஆவணங்களையும், அனைத்து metadata-வையும் கொண்ட ஒரு JSON manifest-ஐ ./export bind mount-ல் எழுதும்:

docker compose exec webserver document_exporter ../export --delete --no-progress-bar

--delete தற்போதைய ஆவணங்களுடன் பொருந்தாத கோப்புகளை நீக்கிவிடும். இதனால் அந்த கோப்புறை எப்போதும் தற்போதைய நிலையின் பிரதிபலிப்பாக இருக்கும், தேவையற்ற கோப்புகளால் அளவு அதிகரிக்காது. --no-progress-bar, இதை cron மூலம் இயக்கும்போது வெளியீட்டைத் தெளிவாக வைத்திருக்கும்.

Restore செய்வது என்பது, புதிய stack-ல் அதே கோப்புறையைப் பயன்படுத்தி document_importer செய்வதாகும். அதாவது, இந்த export directory-ஐ மட்டும் பாதுகாப்பாக வைத்திருந்தால் போதுமானது. இதை ஒரு கால அட்டவணையின்படி உங்கள் VPS-லிருந்து encrypted, deduplicated restic backups மூலம் offsite-க்கு அனுப்பவும். பாதியிலேயே எழுதப்பட்ட archive-ஐ restic எடுக்காமல் இருக்க, முதலில் export-ஐ இயக்கவும்.

export/manifest.json இருப்பதையும், அதன் file count interface-ல் காட்டப்படும் document count-உடன் பொருந்துவதையும் சரிபார்த்து backup-ஐ verify செய்யவும். நீங்கள் ஒருபோதும் list செய்து சரிபார்க்காத backup, backup அல்ல. Nightly export அமைதியாக fail ஆகத் தொடங்குவது இன்னும் மோசமானது. எனவே, cron job தனது exit status-ஐ உங்கள் சொந்த ntfy server-க்கு அனுப்புமாறு அமைக்கவும். அப்போது restore தேவைப்படும் நாளில் அல்ல, அது fail ஆன வாரத்திலேயே உங்களுக்குத் தெரியவரும்.

FAQ

எனது டொமைனைச் சுட்டிக்காட்டிய பிறகு, ஒவ்வொரு பக்கமும் ஏன் "Bad Request (400)" என்று காட்டுகிறது?

உங்கள் டொமைன் ALLOWED_HOSTS-ல் இல்லாததால், Django Host header-ஐ நிராகரிக்கிறது. docker-compose.env-ல் PAPERLESS_URL=https://paperless.example.com-ஐ அமைக்கவும் (இறுதியில் slash இல்லாமல்), பின்னர் container-ஐ மீண்டும் உருவாக்க docker compose up -d-ஐ இயக்கவும். env கோப்பை மட்டும் திருத்துவதால் எந்த மாற்றமும் ஏற்படாது, ஏனெனில் இயங்கிக்கொண்டிருக்கும் container அது தொடங்கப்பட்டபோது இருந்த environment-ஐயே வைத்திருக்கும்.

நான் consume கோப்புறையில் ஒரு PDF-ஐப் போட்டேன், ஆனால் எதுவும் நடக்கவில்லை. என்ன தவறு?

முதலில் docker compose logs webserver-ஐச் சரிபார்க்கவும். அனுமதிப் பிழை (permission error) இருந்தால், USERMAP_UID மற்றும் USERMAP_GID ஆகியவை கோப்பின் உரிமையாளருடன் பொருந்தவில்லை என்று அர்த்தம்; எனவே அவற்றைச் சரிசெய்து container-ஐ மீண்டும் உருவாக்கவும். log-ல் எந்த வரியும் இல்லை என்றால், கோப்பு நிகழ்வு (file event) வந்து சேரவில்லை என்று அர்த்தம்; network shares-ல் kernel அறிவிப்புகள் செயல்படாததால் இது நிகழ்கிறது. PAPERLESS_CONSUMER_POLLING_INTERVAL-ஐ 30 போன்ற மதிப்பிற்கு மாற்றினால், paperless ஒவ்வொரு 30 வினாடிகளுக்கும் கோப்புறையை scan செய்யும்.

நான் PostgreSQL-க்கு பதிலாக SQLite-ஐப் பயன்படுத்தி paperless-ngx-ஐ இயக்க முடியுமா?

ஆம், docker-compose.sqlite.yml ஆதரிக்கப்படுகிறது மற்றும் இது குறைந்த நினைவகத்தையே பயன்படுத்துகிறது, இது சிறிய VPS-க்கு ஏற்றது. உங்கள் ஆவணக் காப்பகம் (archive) வளரும்போது இதன் குறைபாடு தெரியும்: ஆயிரக்கணக்கான ஆவணங்கள் இருக்கும்போது முழு-உரைத் தேடல் (full-text search) மற்றும் மொத்தமாக tag-களைத் திருத்துதல் ஆகியவை குறிப்பிடத்தக்க அளவில் மெதுவாகும். பிற்காலத்தில் இடம்பெயர்வது (migrating) என்பது export மற்றும் import செய்வதைக் குறிக்கும், எனவே உங்கள் காப்பகம் தொடர்ந்து வளரும் என்று எதிர்பார்த்தால் இப்போதே PostgreSQL-ஐத் தேர்ந்தெடுக்கவும்.

ஸ்கேன் செய்யப்பட்ட ஆவணக் காப்பகத்திற்கு எவ்வளவு வட்டு இடம் (disk space) தேவைப்படும்?

உங்கள் மூலக் கோப்புகளின் அளவைப் போல சுமார் இரண்டு மடங்கு தேவைப்படும். Paperless அசல் கோப்பை மாற்றாமல் அப்படியே வைத்திருக்கும், மேலும் தேடக்கூடிய உரை அடுக்குடன் (searchable text layer) கூடிய இரண்டாவது OCR செய்யப்பட்ட PDF-ஐயும், சிறிய thumbnails-களையும் சேமிக்கும். 200 KB அளவுள்ள உரை மட்டும் கொண்ட ஸ்கேன் சிறியதாகவே இருக்கும். ஒரு நீண்ட ஒப்பந்தத்தின் 30 MB வண்ண ஸ்கேன் சுமார் 60 MB-ஐச் சேமிக்கும். நீங்கள் export கோப்புறையை அதே வட்டில் வைத்திருந்தால், அதே காப்பகம் வட்டில் மூன்று முறை சேமிக்கப்படும்.

எனக்கு Tika மற்றும் Gotenberg containers தேவையா?

உங்கள் PDF-களுடன் சேர்த்து Word, Excel அல்லது OpenDocument கோப்புகளும் index செய்யப்பட வேண்டும் என்றால் மட்டுமே இவை தேவை. அவை அந்த வடிவங்களை PDF-ஆக மாற்றுகின்றன, அப்போதுதான் paperless-ஆல் அவற்றை OCR செய்து தேட முடியும். இவை மேலும் இரண்டு containers-ஐ இயக்குவதுடன் சில நூறு மெகாபைட் நினைவகத்தையும் எடுத்துக்கொள்ளும், எனவே நீங்கள் சேமிக்கும் அனைத்தும் ஏற்கனவே PDF அல்லது படங்களாக இருந்தால், சிறிய கணினிகளில் இவற்றைத் தவிர்க்கலாம்.