Docker-এ Nextcloud ফাইল কোথায় জমা থাকে?

Docker-এ Nextcloud যেখানে ফাইল সংরক্ষণ করে

Docker-এ Nextcloud কন্টেইনারের ভেতরে একটি ডেটা ডিরেক্টরিতে ফাইল সংরক্ষণ করে, আর আপনার সার্ভারে এর প্রকৃত অবস্থান হলো সেই ভলিউম বা বাইন্ড মাউন্ট যা আপনি এর সাথে যুক্ত করেছেন। linuxserver.io ইমেজ ব্যবহারের ক্ষেত্রে, lscr.io/linuxserver/nextcloud, ব্যবহারকারীর ফাইলগুলো /data-এ থাকে এবং config.php সহ Nextcloud ইন্সটলেশনটি /config-এ থাকে। এই দুটিই হলো কন্টেইনারের পাথ। একটি কমান্ডের মাধ্যমেই এদের পেছনের হোস্ট পাথটি দেখা সম্ভব, এবং এই গাইডের বাকি অংশে প্রশ্নের কঠিনতর দিকটি আলোচনা করা হয়েছে: ডেটা ডিরেক্টরির বাইরে যা কিছু থাকে।

ইমেজ ট্যাগটি পিন করে রাখুন। পাথগুলো Nextcloud-এর চেয়ে ইমেজের ওপর বেশি নির্ভরশীল, এবং একটি ফ্লোটিং ট্যাগ যেকোনো সময় পরিবর্তিত হতে পারে। আগস্ট 2026 অনুযায়ী এই ইমেজের বর্তমান স্টেবল ট্যাগ হলো 34.0.3।

services:
  nextcloud:
    image: lscr.io/linuxserver/nextcloud:34.0.3
    container_name: nextcloud
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Etc/UTC
    volumes:
      - nextcloud_config:/config
      - nextcloud_data:/data
    ports:
      - 443:443
    restart: unless-stopped

  nextcloud-db:
    image: mariadb:11.8
    container_name: nextcloud-db
    environment:
      - MARIADB_ROOT_PASSWORD=${MARIADB_ROOT_PASSWORD}
      - MARIADB_DATABASE=nextcloud
      - MARIADB_USER=nextcloud
      - MARIADB_PASSWORD=${NEXTCLOUD_DB_PASSWORD}
    volumes:
      - nextcloud_db:/var/lib/mysql
    restart: unless-stopped

volumes:
  nextcloud_config:
  nextcloud_data:
  nextcloud_db:

দুটি পাসওয়ার্ডই compose ফাইলের পাশে থাকা একটি .env ফাইল থেকে আসে, যাতে সেগুলো মূল compose ফাইলের ভেতরে না থাকে। উত্তরের মধ্যে তিনটি ভলিউম রয়েছে, যার মধ্যে কেবল একটি ব্যবহারকারীর ফাইল ধারণ করে।

এই কন্টেইনার পাথগুলো নির্দিষ্ট ইমেজের ডকুমেন্টেশন থেকে আসে। অন্য কোনো Nextcloud ইমেজ তার ফাইলসিস্টেম ভিন্নভাবে সাজাতে পারে এবং ইন্সটলেশনটিকে তার নিজস্ব ওয়েব রুটের অধীনে রাখতে পারে, তাই ফোরাম পোস্ট থেকে কপি করা পাথ কেবল একটি অনুমান মাত্র। আপনার চলমান কন্টেইনার থেকে সঠিক তথ্যটি জেনে নিন।

docker inspect nextcloud

সেই আউটপুটের Mounts সেকশনে প্রতিটি মাউন্টের তালিকা থাকে, যেখানে হোস্ট সাইডে Source এবং কন্টেইনার সাইডে Destination থাকে। আপনি যে ইমেজই বেছে নিন না কেন, এই তালিকাটি আপনার সেটআপের জন্য প্রশ্নের উত্তর প্রদান করে।

ভলিউমের পেছনে থাকা প্রকৃত হোস্ট পাথ কীভাবে খুঁজে পাব?

একটি named volume ডকার (Docker) দ্বারা পরিচালিত হয়, তাই আপনি এর পাথ নির্ধারণ করতে পারেন না। আপনাকে এটি ডকারের কাছে জানতে হবে।

docker volume ls
docker volume inspect nextcloud_nextcloud_data

নামটি গুরুত্বপূর্ণ। Docker Compose ভলিউমের নামের শুরুতে প্রজেক্টের নাম যুক্ত করে, যা সাধারণত আপনার compose ফাইলটি যে ডিরেক্টরিতে আছে তার নাম থেকে আসে। তাই ফাইলে nextcloud_data হিসেবে লেখা একটি ভলিউম সাধারণত ডিস্কে nextcloud_nextcloud_data হিসেবে থাকে। docker volume ls কমান্ডটি প্রকৃত নামগুলো দেখায়। inspect কমান্ডের আউটপুটটি সংক্ষেপে নিচে দেওয়া হলো:

[
    {
        "CreatedAt": "2026-08-18T09:12:44Z",
        "Driver": "local",
        "Mountpoint": "/var/lib/docker/volumes/nextcloud_nextcloud_data/_data",
        "Name": "nextcloud_nextcloud_data",
        "Scope": "local"
    }
]

Mountpoint হলো এর উত্তর। অনুমান না করে কমান্ড থেকে এটি পড়ুন, কারণ এটি পরিবর্তিত হতে পারে। rootless ডকারের ক্ষেত্রে পুরো ডকার ডেটা রুটটি ডেমোন (daemon) চালানো ব্যবহারকারীর হোম ডিরেক্টরির ভেতরে থাকে, তাই সেই পাথটি অন্য কোথাও থেকে শুরু হয়।

একটি bind mount ব্যবহার করলে এই প্রশ্নটি আর থাকে না। compose ফাইলে - /srv/nextcloud/data:/data লিখুন এবং হোস্ট পাথটি হবে সেটিই যা আপনি টাইপ করেছেন, যা docker inspect কমান্ডে Source হিসেবে রিপোর্ট করা হয়। এই পছন্দটি শুধু পাথের চেয়েও বেশি কিছু পরিবর্তন করে, কারণ named volumes and bind mounts মালিকানা (ownership) এবং ব্যাকআপের ক্ষেত্রে ভিন্নভাবে কাজ করে।

কেন শুধুমাত্র data directory ব্যাকআপ যথেষ্ট নয়

Nextcloud ম্যানুয়ালে পাঁচটি বিষয়ের কথা উল্লেখ করা হয়েছে যা ব্যাকআপে থাকা আবশ্যক: config ফোল্ডার, custom apps ফোল্ডার, data ফোল্ডার, theme ফোল্ডার এবং ডাটাবেস। এই ইমেজের ক্ষেত্রে config, apps এবং theme ফোল্ডারগুলো /config-এর অধীনে থাকে, আর ডাটাবেসটি তার নিজস্ব ভলিউমসহ আলাদা একটি কন্টেইনারে চলে। শুধুমাত্র /data কপি করলে আপনি সমস্যার সবচেয়ে কম গুরুত্বপূর্ণ অংশটি সংরক্ষণ করছেন।

ডাটাবেসটি গুরুত্বপূর্ণ কারণ ওয়েব ইন্টারফেস কখনোই ডিরেক্টরি তালিকাভুক্ত করে না। এটি ফাইল ক্যাশ থেকে সারি (rows) প্রদর্শন করে, আর এই কারণেই ম্যানুয়ালে বলা হয়েছে যে ম্যানুয়ালি data directory-তে ফাইল কপি করার পর একটি স্ক্যান চালাতে হবে। একটি খালি ডাটাবেসের পাশে /data রিস্টোর করলে আপনি কেবল ইনডেক্সবিহীন কিছু বাইট পাবেন: কোনো ইউজার নেই, কোনো শেয়ার নেই, ফাইল তালিকায় কিছুই নেই। আবার একটি খালি /data-এর পাশে ডাটাবেস রিস্টোর করলে প্রতিটি সারি এমন ফাইলের দিকে নির্দেশ করবে যা আসলে নেই।

config.php-এ ডাটাবেসের ক্রেডেনশিয়াল এবং ট্রাস্টেড ডোমেইনগুলো থাকে। এতে instance id-ও থাকে, যা data directory-র ভেতরে থাকা অ্যাপ ডাটা ফোল্ডারের নাম। স্মৃতি থেকে কোনো মান বিশ্বাস করার চেয়ে চলমান instance-কে জিজ্ঞাসা করাই শ্রেয়।

docker exec -it nextcloud occ config:system:get datadirectory
docker exec -it nextcloud occ config:system:get instanceid

প্রথম কমান্ডটি সেই data directory প্রিন্ট করে যা এই instance বর্তমানে ব্যবহার করছে, যা এখানে /data। এই ইমেজটি পাথে একটি occ র‍্যাপার প্রদান করে, তাই সরাসরি docker exec-এর মাধ্যমে এটি চালান। Nextcloud ম্যানুয়ালের দীর্ঘ sudo এবং php occ ফরম্যাটটি কপি করবেন না, কারণ সেটি কন্টেইনারের বাইরে ইন্সটলেশনের জন্য লেখা হয়েছে।

ডেটা ভলিউমটি কীসের কারণে পূর্ণ হয়ে যাচ্ছে?

প্রিভিউ (previews) এবং ব্যবহারকারীর নিজস্ব হিস্ট্রি মূল ফাইলের সাথে একই ভলিউমে থাকে। ওয়েব ইন্টারফেসে ব্যবহারকারী যে স্টোরেজ পরিসংখ্যান দেখেন, সেখানে এগুলোর হিসাব থাকে না।

• প্রিভিউ হলো জেনারেট করা থাম্বনেইল। এগুলো ডেটা ডিরেক্টরির ভেতরে অ্যাপ ডেটা ফোল্ডারে থাকে, যার নাম appdata_ এবং এর সাথে ইনস্ট্যান্স আইডি যুক্ত থাকে।
• ডিলিট করা ফাইলগুলো ট্র্যাশে জমা থাকে। trashbin_retention_obligation-এর ডিফল্ট মান হলো auto, যা ফাইলগুলোকে 30 দিন পর্যন্ত সংরক্ষণ করে এবং এরপর শুধুমাত্র জায়গা প্রয়োজন হলেই সেগুলো মুছে ফেলে। ডিলিট করা ফাইলগুলো ব্যবহারকারীর কোটার অন্তর্ভুক্ত থাকে। কোটা পূর্ণ হয়ে গেলে রিটেনশন সেটিংস উপেক্ষা করা হয় এবং কোটার মধ্যে জায়গা না হওয়া পর্যন্ত ট্র্যাশ থেকে ফাইল মুছে ফেলা হয়।
• পুরনো ভার্সনগুলোও থেকে যায়। versions_retention_obligation-এর ডিফল্ট মানও auto। ভার্সন অ্যাপটি ব্যবহারকারীর বর্তমান ফ্রি স্পেসের 50%-এর বেশি কখনোই ব্যবহার করে না। জায়গা খালি করার সময় এটি সবচেয়ে পুরনো ভার্সনগুলো আগে মুছে ফেলে এবং সর্বশেষ দুটি ভার্সন রেখে দেয়। ব্যবহারকারী নিজে কোনো ভার্সনের নাম দিলে তা কখনোই মুছে ফেলা হয় না।

কিছু ডিলিট করার আগে পরিমাপ করে নিন।

docker exec -it nextcloud sh -c 'du -sh /data/*'
docker exec -it nextcloud sh -c 'du -sh /data/appdata_*'

প্রথম লাইনটি প্রতিটি ব্যবহারকারীর ফোল্ডার এবং অ্যাপ ডেটা ফোল্ডারের জন্য আলাদা আলাদা সংখ্যা প্রদান করে। যদি অ্যাপ ডেটার সংখ্যা অনেক বড় হয়, তবে বুঝতে হবে প্রিভিউয়ের কারণেই জায়গা পূর্ণ হচ্ছে। নিচের ক্লিনআপ কমান্ডগুলো ডকুমেন্ট করা আছে এবং এগুলোর প্রতিটিই ইচ্ছাকৃতভাবে ডেটা মুছে ফেলে।

docker exec -it nextcloud occ trashbin:cleanup --all-users
docker exec -it nextcloud occ versions:cleanup alice
docker exec -it nextcloud occ preview:cleanup

preview:cleanup সমস্ত জেনারেট করা প্রিভিউ মুছে ফেলে। ব্যবহারকারীরা যখন ফাইলগুলো ওপেন করেন, তখন Nextcloud পুনরায় সেগুলো জেনারেট করে। ফলে জায়গা ধীরে ধীরে ফিরে আসে, তবে এর জন্য CPU-এর ওপর চাপ পড়ে। যদি ভলিউমটি বড় কোনো ডিস্ক সমস্যার একটি অংশ মাত্র হয়, তবে পুরনো ইমেজ এবং অব্যবহৃত বিল্ড ক্যাশ সাধারণত অন্য কারণ হিসেবে কাজ করে।

হোস্টে কপি করা ফাইলগুলো কেন Nextcloud-এ দেখা যাচ্ছে না?

কারণ Nextcloud তার ফাইল ক্যাশ ডাটাবেস থেকে পড়ে, ডিরেক্টরি থেকে নয়। আপনার কপি করা ফাইলটি ডিস্কে থাকলেও ডাটাবেসে এর কোনো এন্ট্রি নেই, তাই ওয়েব ইন্টারফেসে দেখানোর মতো কিছু নেই। ম্যানুয়ালে এই বিষয়টি স্পষ্টভাবে উল্লেখ আছে: সরাসরি ডাটা ডিরেক্টরিতে ফাইল কপি করার পর একটি স্ক্যান প্রয়োজন।

docker exec -it nextcloud occ files:scan --path="/alice/files/Photos"
docker exec -it nextcloud occ files:scan --unscanned -v
docker exec -it nextcloud occ files:scan --all

--path আর্গুমেন্টটি ডাটা ডিরেক্টরির গঠনও দেখায়: প্রতিটি ইউজারের নামে একটি ফোল্ডার থাকে এবং তার ভেতরে থাকা files ফোল্ডারটিই ইউজার ওয়েব ইন্টারফেসে দেখতে পান। ফাইলগুলো কোথায় রাখা হয়েছে তা জানা থাকলে নির্দিষ্ট একটি পাথ স্ক্যান করুন। --all প্রতিটি ইউজারকে চেক করে, তাই বড় ইনস্ট্যান্সের ক্ষেত্রে এটি অনেক সময় নিতে পারে। --unscanned শুধুমাত্র সেই ফাইলগুলো নিয়ে কাজ করে যেগুলো এখনো পুরোপুরি স্ক্যান করা হয়নি। -v প্রসেস করার সময় প্রতিটি ফাইলের নাম প্রিন্ট করে, যা কমান্ডটি আটকে আছে নাকি কাজ করছে তা বোঝার জন্য সহায়ক।

ফাইলের মালিকানা (ownership) নির্ধারণ করে যে স্ক্যানটি যথেষ্ট কি না। কন্টেইনার ইউজার যদি ফাইলটিতে লিখতে না পারে, তবে সেটি ইনডেক্স হওয়ার পর আর সরানো যায় না। ফলে ওয়েব ইন্টারফেসে ফাইলটি দেখা গেলেও সেখান থেকে রিনেম বা ডিলিট করার চেষ্টা করলে তা ব্যর্থ হয়।

PUID এবং PGID সেট করার পর রাইট (write) অপারেশন ব্যর্থ হয় কেন?

কারণ কার্নেল নামের পরিবর্তে সংখ্যা তুলনা করে। PUID এবং PGID সেই সংখ্যাসূচক ইউজার আইডি (uid) এবং গ্রুপ আইডি (gid) নির্ধারণ করে, যা দিয়ে কন্টেইনার প্রসেসটি চলে। হোস্টের প্রতিটি ফাইলেরও একটি সংখ্যাসূচক মালিকানা থাকে। যখন এই দুটি সংখ্যা মেলে না, তখন রাইট অপারেশন প্রত্যাখ্যান করা হয়, তা উভয় পাশে নাম যাই দেখা যাক না কেন।

docker exec -it nextcloud id abc
sudo ls -ln /var/lib/docker/volumes/nextcloud_nextcloud_data/_data

id abc কমান্ডটি কন্টেইনার প্রকৃতপক্ষে যে uid এবং gid ব্যবহার করছে তা প্রিন্ট করে, যা আপনার সেট করা PUID এবং PGID। ls -ln কমান্ডটি সংখ্যাসূচক মালিকদের প্রিন্ট করে এবং -n ফ্ল্যাগটি গুরুত্বপূর্ণ: সাধারণ ls -l কমান্ডটি হোস্টের নিজস্ব ইউজার তালিকার মাধ্যমে সেই সংখ্যাগুলোকে অনুবাদ করে এবং এমন একটি নাম দেখায় যার কন্টেইনারের ভেতরে কোনো অর্থ নেই। এই দুটি সংখ্যা তুলনা করুন।

এরপর অনুমান না করে রাইট অপারেশনটি পরীক্ষা করুন।

docker exec -u abc -it nextcloud touch /data/writetest

একটি Permission denied কমান্ড যা /data ফাইলকে নির্দেশ করে, তা নিশ্চিতকরণ হিসেবে কাজ করে। কন্টেইনারের ভেতর থেকে মালিকানা ঠিক করুন, তারপর একই পরীক্ষা পুনরায় চালান।

docker exec -u 0 -it nextcloud chown -R abc:abc /data
docker exec -u abc -it nextcloud touch /data/writetest
docker exec -u abc -it nextcloud rm /data/writetest

ভেতর থেকে এটি করার একটি কারণ আছে। রুটলেস (rootless) Docker-এর ক্ষেত্রে কন্টেইনারের ইউজার আইডিগুলো /etc/subuid-এ থাকা সাবঅর্ডিনেট রেঞ্জের মাধ্যমে ম্যাপ করা হয়, তাই কন্টেইনারের ভেতরের uid 1000 হোস্টের অনেক বড় একটি uid-এর অন্তর্ভুক্ত। হোস্ট-সাইড chown 1000:1000 কমান্ড তখন এমন একজন মালিক সেট করে যা কন্টেইনার ব্যবহার করতে পারে না, ফলে রাইট অপারেশন ব্যর্থ হয়। কন্টেইনারের ভেতরে chown কমান্ডটি চালানো হলে তা একই ম্যাপিংয়ের মধ্য দিয়ে যায় যা Nextcloud প্রসেসটি নিজে ব্যবহার করে, তাই সংখ্যাগুলো গঠনগতভাবেই মিলে যায়। এই কারণেই অন্য কোনো কিছু ডিবাগ করা শুরু করার আগে PUID এবং PGID-কে ডিস্কের মালিকের সাথে মিলতে হবে।

কিভাবে ব্যাকআপ নিলে তা সঠিকভাবে রিস্টোর করা সম্ভব?

একই মুহূর্তের ডেটাবেস এবং ফোল্ডারগুলো সংগ্রহ করুন। মেইনটেন্যান্স মোড চালু থাকলে লগইন বন্ধ থাকে, ফলে ডাম্প এবং কপি করার মধ্যবর্তী সময়ে কোনো নতুন ফাইল আপলোড হওয়ার সুযোগ থাকে না।

docker exec -it nextcloud occ maintenance:mode --on
docker exec nextcloud-db mariadb-dump --single-transaction -u nextcloud -p"$NEXTCLOUD_DB_PASSWORD" nextcloud > nextcloud-sqlbkp.sql
docker run --rm -v nextcloud_nextcloud_data:/data:ro -v "$PWD":/backup alpine:3.22 tar czf /backup/nextcloud-data.tgz -C /data .
docker run --rm -v nextcloud_nextcloud_config:/config:ro -v "$PWD":/backup alpine:3.22 tar czf /backup/nextcloud-config.tgz -C /config .
docker exec -it nextcloud occ maintenance:mode --off

লক্ষ্য করুন যে ডাম্প কমান্ডে একটি -t ফ্ল্যাগ নেই। একটি TTY লাইন এন্ডিং পরিবর্তন করে দেয়, যার ফলে SQL ডাম্পটি এমনভাবে ক্ষতিগ্রস্ত হয় যা কেবল রিস্টোর করার সময় ধরা পড়ে। আরও লক্ষ্য করুন যে, কমান্ড লাইনে পাসওয়ার্ড লিখলে তা ps আউটপুটে দৃশ্যমান হয়, তাই সরাসরি টাইপ না করে আপনার .env ফাইল থেকে তা শেল-এ রিড করুন। পুরনো ডেটাবেস ইমেজগুলোতে mariadb-dump-এর পরিবর্তে mysqldump থাকে এবং ম্যানুয়ালে উভয়ই উল্লেখ করা আছে।

রিস্টোর করার জন্য, একটি খালি ডেটাবেসে ডাম্পটি লোড করুন, দুটি আর্কাইভই নতুন ভলিউমে আনপ্যাক করুন, কন্টেইনারগুলো চালু করুন এবং তারপর মেইনটেন্যান্স মোড বন্ধ করুন। যদি ফোল্ডার এবং ডাম্প ভিন্ন ভিন্ন সময়ের হয়, তবে ফাইল ক্যাশে এবং ডিস্কের তথ্যের মধ্যে অমিল দেখা দেয় এবং occ files:scan --all কেবল একদিকের সমস্যার সমাধান করতে পারে। এটি এমন ফাইল খুঁজে পায় যার কোনো ডেটাবেস এন্ট্রি নেই, কিন্তু ডেটাবেস এন্ট্রিতে থাকা কোনো ফাইল হারিয়ে গেলে তা ফিরিয়ে আনতে পারে না।

ব্যাকআপ কপি সার্ভারের বাইরে রাখুন। একই VPS-এর ভেতরে রাখা কপি সেই VPS নষ্ট হয়ে গেলে নিজেও নষ্ট হয়ে যায়, আর এই কারণেই সার্ভারের বাইরের রিপোজিটরিতে restic ব্যবহার এই প্রক্রিয়ার অংশ হওয়া উচিত এবং প্রোভাইডার স্ন্যাপশট ব্যাকআপের বিকল্প নয়। আপনি যদি এখনো স্ট্যাকটি তৈরি করে থাকেন, তবে VPS-এ সম্পূর্ণ Nextcloud ইনস্টলেশন গাইডটি দেখুন, যেখানে রিভার্স প্রক্সি এবং TLS (ট্রান্সপোর্ট লেয়ার সিকিউরিটি) সার্টিফিকেটের বিষয়গুলো আলোচনা করা হয়েছে যা এই গাইডে বাদ দেওয়া হয়েছে।

FAQ

Docker কন্টেইনারে Nextcloud-এর ডেটা ডিরেক্টরি কোথায় থাকে?

linuxserver.io ইমেজ ব্যবহারের ক্ষেত্রে কন্টেইনারের ভেতরে এটি থাকে /data-তে, এবং config.php দিয়ে ইনস্টল করলে তা থাকে /config-তে। এগুলো হলো কন্টেইনারের অভ্যন্তরীণ পাথ। হোস্ট মেশিনের পাথ জানতে docker inspect nextcloud কমান্ডটি চালান এবং Mounts সেকশনে Source মানটি দেখুন, অথবা ভলিউমের ওপর docker volume inspect চালিয়ে Mountpoint পড়ুন। অন্যান্য Nextcloud ইমেজে ভিন্ন পাথ থাকতে পারে, তাই আপনার ব্যবহৃত ট্যাগের ডকুমেন্টেশন দেখুন এবং docker exec -it nextcloud occ config:system:get datadirectory দিয়ে নিশ্চিত হয়ে নিন।

ভলিউমে কপি করা ফাইলগুলো কেন Nextcloud-এ দেখা যাচ্ছে না?

Nextcloud সরাসরি ডিরেক্টরি পড়ার পরিবর্তে তার ডেটাবেসে থাকা ফাইল ক্যাশের সারিগুলো প্রদর্শন করে। তাই Nextcloud-এর মাধ্যমে আপলোড না করা কোনো ফাইলের এন্ট্রি ডেটাবেসে না থাকায় তা অদৃশ্য থাকে। একটি ফোল্ডারের জন্য docker exec -it nextcloud occ files:scan --path="/alice/files/Photos" অথবা সব ইউজারের জন্য occ files:scan --all কমান্ডটি চালান। যদি ফাইলগুলো দেখা যায় কিন্তু সরানো বা ডিলিট করা না যায়, তবে সমস্যাটি মালিকানা বা পারমিশনের: কন্টেইনারের ইউজারকে অবশ্যই ফাইলগুলো লেখার অনুমতি রাখতে হবে।

Nextcloud রিস্টোর করার জন্য কি শুধু ডেটা ভলিউমের কপি যথেষ্ট?

না। ডেটা ভলিউমে কেবল ফাইলের বিষয়বস্তু থাকে। ডেটাবেসে থাকে ফাইলের ইনডেক্স, ইউজার এবং শেয়ারের তথ্য, আর config.php-এ থাকে ডেটাবেসের ক্রেডেনশিয়াল এবং ইনস্ট্যান্স আইডি। একটি সফল রিস্টোরের জন্য ডেটা ফোল্ডার, কনফিগ ফোল্ডার, ডেটাবেস এবং আপনি যদি কাস্টম অ্যাপ বা থিম ব্যবহার করেন তবে সেই ফোল্ডারগুলোও প্রয়োজন। সবগুলোর ব্যাকআপ একই সময়ের হতে হবে, কারণ ফাইলের চেয়ে নতুন ডেটাবেস এমন ফাইলের দিকে নির্দেশ করবে যা হয়তো অস্তিত্বহীন।

আমার ডেটা ভলিউম কেন ইউজারদের দেখা ফাইলের চেয়ে অনেক বড়?

প্রিভিউ, ডিলিট করা ফাইল এবং পুরনো ভার্সনগুলো একই ভলিউমে থাকে, যা ইউজাররা দেখতে পায় না। docker exec -it nextcloud sh -c 'du -sh /data/*' দিয়ে পরিমাপ করুন। ট্র্যাশ ফোল্ডার ডিফল্টভাবে 30 দিন পর্যন্ত ডিলিট করা ফাইল রাখে এবং জায়গা প্রয়োজন হলে কেবল তখনই তা পরিষ্কার করে। এছাড়া, ভার্সন অ্যাপ ইউজারের বর্তমান ফ্রি স্পেসের অর্ধেক পর্যন্ত জায়গা নিতে পারে। এগুলো পরিষ্কার করতে occ trashbin:cleanup --all-users, occ versions:cleanup alice এবং occ preview:cleanup ব্যবহার করুন। মনে রাখবেন, ইউজাররা ফাইল ওপেন করলে প্রিভিউ আবার তৈরি হতে শুরু করবে।

আমি কি Nextcloud-এর ডেটা ডিরেক্টরি অন্য ডিস্কে সরাতে পারি?

Nextcloud-এর জানা পাথ পরিবর্তন না করে নতুন লোকেশনটিকে একই কন্টেইনার পাথে মাউন্ট করুন। কন্টেইনারটি থামান, মালিকানা বজায় রেখে (cp -a বা rsync -aAX ব্যবহার করে) পুরনো ফাইলগুলো নতুন ডিস্কে কপি করুন, আপনার compose ফাইলে ভলিউম বা বাইন্ড মাউন্টকে নতুন লোকেশনে নির্দেশ করুন এবং পুনরায় কন্টেইনার চালু করুন। Nextcloud তখনও /data-কেই দেখবে, তাই ডেটাবেসের কোনো সারি পরিবর্তনের প্রয়োজন হবে না। docker exec -it nextcloud occ config:system:get datadirectory এবং একটি টেস্ট আপলোডের মাধ্যমে বিষয়টি যাচাই করুন।