مدیریت مصرف رم ZFS در سرورهای مجازی VPS

مزایای ZFS و هزینه‌های آن

سیستم ZFS در FreeBSD و Linux اکنون دارای یک codebase واحد به نام OpenZFS است، بنابراین قابلیت‌های آن در هر دو سیستم یکسان است. سروری که از ZFS استفاده می‌کند، از داده‌های checksum شده، snapshotهایی که تا زمان تغییر داده‌ها هزینه‌ای ندارند، قابلیت replication با zfs send و فشرده‌سازی که تنها با تنظیم یک property فعال می‌شود، بهره‌مند می‌گردد. هزینه‌ای که این سیستم تحمیل می‌کند، حافظه RAM است: ARC (حافظه کش تطبیقی) به‌طور پیش‌فرض بخش بزرگی از RAM را اشغال می‌کند و در یک VPS (سرور مجازی خصوصی) با 2 GB یا 4 GB حافظه، این دقیقاً همان مقداری است که برنامه شما به آن نیاز دارد.

این راهنما ZFS را از دیدگاه یک VPS اجاره‌ای با یک یا دو دیسک مجازی ارزیابی می‌کند، نه یک دستگاه ذخیره‌سازی با 40 جایگاه درایو. قابلیت‌هایی که در این انتقال کارآمد باقی می‌مانند، ارزش صرف وقت شما را دارند. بخش‌هایی که در این مقیاس کارایی ندارند، مواردی هستند که پیش از ساخت pool باید از آن‌ها آگاه باشید.

OpenZFS در FreeBSD و Linux: یک کد منبع، دو شیوه بسته‌بندی

سیستم‌عامل FreeBSD از سال 2008 و نسخه 7.0، ZFS را در سیستم پایه خود گنجانده است؛ در ابتدا این قابلیت به عنوان یک ویژگی آزمایشی ارائه شد. از زمان عرضه OpenZFS 2.0 در دسامبر 2020، FreeBSD و Linux از یک درخت کد منبع واحد برای ساخت استفاده می‌کنند، بنابراین zfs و zpool در هر دو سیستم رفتار یکسانی دارند و یک pool ایجاد شده در یکی، در دیگری قابل import است.

دلیل اینکه ZFS در Linux به صورت یک بسته (package) و در FreeBSD بخشی از سیستم پایه است، به مجوزها (licensing) برمی‌گردد. OpenZFS تحت مجوز CDDL (مجوز توسعه و توزیع مشترک) منتشر می‌شود. هسته Linux تحت مجوز GPL (مجوز عمومی همگانی) نسخه 2 است. پروژه هسته، این دو مجوز را ناسازگار می‌داند، بنابراین کد ZFS در خط اصلی (mainline) هسته Linux ادغام نمی‌شود و هر توزیع تصمیم می‌گیرد که چگونه آن را ارائه کند. FreeBSD چنین تداخلی ندارد، بنابراین ZFS به سادگی در آن موجود است. این تمام ماجرای عملی است: یک تفاوت در بسته‌بندی که نیازی نیست در مورد آن موضع‌گیری کنید.

سرویس SSD Nodes ایمیج‌های FreeBSD ارائه نمی‌دهد، بنابراین روی سروری که در اینجا اجاره می‌کنید، بخش Linux این راهنما کاربرد دارد. اگر در جای دیگری از FreeBSD استفاده می‌کنید، یک سرور FreeBSD بدون نیاز به ساخت ماژول یا نگرانی از ارتقای هسته، ZFS را در اختیار شما قرار می‌دهد.

نصب ZFS و ایجاد یک pool

در Ubuntu، ماژول ZFS درون بسته‌های هسته (kernel) قرار دارد، بنابراین شما فقط باید ابزارهای کاربری را نصب کنید.

sudo apt update
sudo apt install -y zfsutils-linux
zfs version

دستور zfs version دو خط را چاپ می‌کند: نسخه ابزارهای کاربری و نسخه ماژول هسته. اگر فقط یک خط چاپ شود، به این معنی است که ماژول بارگذاری نشده است. این بسته در بخش universe قرار دارد که در ایمیج‌های Ubuntu server به‌صورت پیش‌فرض فعال است؛ اگر apt آن را پیدا نکرد، ابتدا sudo add-apt-repository universe را اجرا کنید.

در Debian، بسته‌ها در بخش contrib قرار دارند و ماژول توسط DKMS (پشتیبانی پویا از ماژول هسته) روی سیستم شما ساخته می‌شود. عبارت contrib را به خط Components: در فایل /etc/apt/sources.list.d/debian.sources اضافه کنید، سپس sudo apt update را اجرا کرده و در نهایت:

sudo apt install -y linux-headers-$(dpkg --print-architecture) zfs-dkms zfsutils-linux

عملیات نصب، ماژول را کامپایل کرده و Building initial module for 6.12.0-... را چاپ می‌کند که چند دقیقه زمان می‌برد. به خاطر داشته باشید که با هر بار ارتقای هسته، این ماژول دوباره ساخته می‌شود و اگر ساخت آن با خطا مواجه شود، pool شما تا زمان رفع مشکل غیرقابل دسترس (unimported) باقی می‌ماند.

در FreeBSD نیازی به نصب چیزی نیست. فقط سرویس را فعال و اجرا کنید.

sysrc zfs_enable=YES
service zfs start

حالا نوبت ایجاد pool است. ابتدا مسیرهای پایدار دستگاه‌ها را بررسی کنید، زیرا /dev/vdb بر اساس ترتیب شناسایی اختصاص می‌یابد و ممکن است با اتصال یک درایو جدید، تغییر کند.

ls -l /dev/disk/by-id/
sudo zpool create -o ashift=12 tank /dev/disk/by-id/virtio-abc123def456
zpool status tank

دستور zpool status باید state: ONLINE را چاپ کند و دستگاه شما را زیر ستون tank نمایش دهد. پارامتر ashift=12 کوچک‌ترین بلاک pool را روی 4 KiB تنظیم می‌کند که با SSDهای امروزی مطابقت دارد و پس از ایجاد pool قابل تغییر نیست.

بیشتر ایمیج‌های اجاره‌ای از پارتیشن ریشه ext4 بوت می‌شوند، بنابراین ZFS در اینجا یک pool داده روی درایو دوم است، نه فایل‌سیستم ریشه. پیش از ساختن pool، مطمئن شوید که دستگاه همان چیزی است که تصور می‌کنید، زیرا تأیید درایو NVMe خریداری شده تنها یک دقیقه زمان می‌برد، اما بازسازی آن ممکن است یک بعدازظهر کامل وقت شما را بگیرد.

Checksumها تنها زمانی تعمیر را انجام می‌دهند که pool دارای افزونگی باشد

هر بلاکی که ZFS می‌نویسد دارای یک checksum است و هر خواندن، آن را تایید می‌کند. تشخیص خطا همیشه کار می‌کند، اما تعمیر به یک نسخه دوم نیاز دارد.

در یک pool تک‌دیسکی، ZFS حقیقت را به شما می‌گوید و در همان‌جا متوقف می‌شود. zpool status -v آن را به این صورت گزارش می‌دهد:

status: One or more devices has experienced an error resulting in data
        corruption.
action: Restore the file in question if possible.  Otherwise restore the
        entire pool from backup.
errors: Permanent errors have been detected in the following files:

        /tank/data/archive.tar

نام فایل خراب مشخص شده است. در ext4، آن بایت‌ها بدون هیچ هشداری بازگردانده می‌شدند، بنابراین این قابلیت ZFS ارزشمند است. با این حال، ZFS نمی‌تواند آن را تعمیر کند، زیرا نسخه دومی در pool وجود ندارد که بتوان از روی آن تعمیر را انجام داد.

در حالت mirror، همان خواندن از سمت سالم انجام می‌شود، بلاک خراب بازنویسی می‌گردد و رویداد در ستون CKSUM از zpool status ظاهر می‌شود. این همان خودترمیمی (self-healing) است و به دو دستگاه نیاز دارد.

sudo zpool create -o ashift=12 tank mirror /dev/disk/by-id/DISK1 /dev/disk/by-id/DISK2

در یک VPS، فضای ذخیره‌سازی میزبان معمولاً از قبل دارای افزونگی است که اغلب به صورت RAID 10 در سطح hypervisor پیاده‌سازی می‌شود. این کار از شما در برابر خرابی فیزیکی دیسک محافظت می‌کند، اما زمانی که یک بلاک به اشتباه بازگردانده شود، به شما اطلاع نمی‌دهد؛ زیرا آرایه راهی برای تشخیص اینکه کدام نسخه صحیح است ندارد. ZFS این موضوع را می‌داند، زیرا داده‌ها را با checksumای که خودش نوشته است مقایسه می‌کند.

اگر یک دیسک مجازی دارید و می‌خواهید قابلیت تعمیر داشته باشید، sudo zfs set copies=2 tank/important دو نسخه از هر بلاک آن dataset را روی همان دیسک ذخیره می‌کند. این کار فضای مصرفی آن dataset را دو برابر می‌کند، در برابر خرابی یک بلاک مقاوم است، اما اگر کل volume از دسترس خارج شود، هیچ کاری از دستش برنمی‌آید.

عملیات scrub تمام داده‌های موجود در pool را می‌خواند و آن‌ها را تایید می‌کند.

sudo zpool scrub tank
zpool status tank

یک pool سالم با خطی مشابه scan: scrub repaired 0B in 00:04:11 with 0 errors به پایان می‌رسد. آن را در یک زمان‌بندی قرار دهید؛ برای یک pool کوچک، ماهانه کافی است.

systemctl list-unit-files 'zfs-scrub*'
sudo systemctl enable --now zfs-scrub-monthly@tank.timer

دیتاست‌ها واحد سیاست‌گذاری هستند

یک دیتاست، یک سیستم فایل درون pool است و ایجاد آن هزینه کمی دارد؛ بنابراین برای هر وظیفه (job) یک دیتاست مجزا بسازید. ویژگی‌ها از pool به پایین به ارث می‌رسند، به این معنی که شما یک مقدار پیش‌فرض را یک‌بار تنظیم می‌کنید و در صورت نیاز، آن را برای موارد خاص بازنویسی (override) می‌کنید.

sudo zfs create tank/data
sudo zfs create tank/pg
sudo zfs set compression=lz4 tank
sudo zfs set atime=off tank
sudo zfs set quota=20G tank/data
sudo zfs set recordsize=16K tank/pg
zfs get -r compression,compressratio,quota tank

فشرده‌سازی (compression) ویژگی‌ای است که افراد به دلیل احتیاط از آن صرف‌نظر می‌کنند، در حالی که این رویکرد اشتباه است. lz4 مقدار کمی از CPU را مصرف می‌کند و تعداد بایت‌هایی که باید به دیسک برسند را کاهش می‌دهد؛ بنابراین در داده‌های قابل فشرده‌سازی، معمولاً سرعت خواندن و نوشتن را افزایش می‌دهد. zstd فشرده‌سازی قوی‌تری را با مصرف CPU بیشتر انجام می‌دهد که برای لاگ‌ها و آرشیوهایی که به‌ندرت بازخوانی می‌شوند، مناسب است. با استفاده از zfs get compressratio tank بررسی کنید که واقعاً چه نتیجه‌ای می‌گیرید و به یاد داشته باشید که نسبت فشرده‌سازی فقط شامل داده‌هایی می‌شود که پس از تنظیم این ویژگی نوشته شده‌اند.

recordsize بزرگ‌ترین بلاکی است که یک دیتاست می‌نویسد و مقدار پیش‌فرض آن 128K است. یک دیتابیس که صفحات 8 KiB را در رکوردهای 128 KiB می‌نویسد، یک نوشتن کوچک را به خواندن کل رکورد، اعمال تغییر و نوشتن مجدد تبدیل می‌کند. قبل از بارگذاری داده‌ها، recordsize=16K را روی دیتاست دیتابیس تنظیم کنید، زیرا این ویژگی فقط برای بلاک‌های جدید اعمال می‌شود.

quota روشی است که با آن از پر شدن pool توسط یک دیتاست جلوگیری می‌کنید. یک ZFS pool که نزدیک به 100% پر شده باشد، کند می‌شود و پاک‌سازی آن دشوار خواهد بود؛ بنابراین عمداً مقداری فضای خالی (headroom) باقی بگذارید.

هزینه اسنپ‌شات‌ها تا زمانی که داده‌ها تغییر نکنند، صفر است

سیستم فایل ZFS هرگز یک بلاک زنده را بازنویسی نمی‌کند. این سیستم یک بلاک جدید می‌نویسد و اشاره‌گرها را به‌روزرسانی می‌کند؛ این همان معنای کپی هنگام نوشتن (copy-on-write) است. اسنپ‌شات در واقع یادداشتی است که می‌گوید «بلاک‌هایی را که این دیتاست در حال حاضر به آن‌ها اشاره می‌کند، حفظ کن»، بنابراین ایجاد آن آنی و رایگان است.

sudo zfs snapshot tank/data@2026-08-11
zfs list -t snapshot -o name,used,refer -r tank/data

ستون USED برای یک اسنپ‌شات، نشان‌دهنده فضایی است که فقط توسط همان اسنپ‌شات اشغال شده است. این مقدار در ابتدا نزدیک به صفر است و با تغییر یا حذف داده‌ها افزایش می‌یابد، زیرا بلاک‌های قدیمی دیگر قابل آزادسازی نیستند.

بازیابی یک فایل به هیچ مرحله بازگردانی (restore) نیاز ندارد.

ls /tank/data/.zfs/snapshot/
cp /tank/data/.zfs/snapshot/2026-08-11/notes.txt /tank/data/notes.txt

دایرکتوری .zfs حتی از دید ls -a نیز پنهان است تا زمانی که دستور sudo zfs set snapdir=visible tank/data را اجرا کنید. اسنپ‌شات را پیش از آنکه به آن نیاز پیدا کنید بگیرید، زیرا بدون آن، یک دستور rm -rf اشتباه شما را به مسیر بازیابی ext4 می‌کشاند که با unmount کردن دیسک شروع شده و شرایط از آنجا بدتر می‌شود.

عملیات Rollback هر چیزی را که پس از اسنپ‌شات نوشته شده باشد، دور می‌ریزد.

sudo zfs rollback tank/data@2026-08-11

اگر اسنپ‌شات‌های جدیدتری وجود داشته باشد، این عملیات رد می‌شود و -r آن اسنپ‌شات‌های جدیدتر را برای ادامه کار از بین می‌برد. پیش از فشردن کلید Enter، نام دیتاست را دو بار بررسی کنید.

اسنپ‌شات یک نسخه پشتیبان (backup) نیست. اسنپ‌شات در همان pool، روی همان volume و روی همان سرور قرار دارد. خرابی یک volume یا یک zpool destroy، اسنپ‌شات‌ها را همراه با داده‌ها از بین می‌برد. اسنپ‌شات‌ها شما را در برابر rm خودتان و ارتقاهای ناموفق محافظت می‌کنند که بسیاری از حوادث واقعی را پوشش می‌دهد، اما در برابر آنچه برای خودِ pool رخ می‌دهد، هیچ محافظتی ارائه نمی‌دهند. استدلال کامل در اینجا آمده است: چرا اسنپ‌شات VPS یک نسخه پشتیبان نیست.

ارسال و دریافت: همانندسازی با یک دستور

zfs send یک اسنپ‌شات را به یک جریان بایت (byte stream) در خروجی استاندارد تبدیل می‌کند و zfs receive آن جریان را دوباره به یک دیتاست بازمی‌گرداند. اولین کپی، یک ارسال کامل (full send) است.

sudo zfs snapshot tank/data@daily-2026-08-11
sudo zfs send tank/data@daily-2026-08-11 | ssh backup.example.com "sudo zfs recv -F backup/data"

پس از آن، فقط تغییرات بین دو اسنپ‌شات را ارسال کنید.

sudo zfs snapshot tank/data@daily-2026-08-12
sudo zfs send -i tank/data@daily-2026-08-11 tank/data@daily-2026-08-12 | ssh backup.example.com "sudo zfs recv backup/data"

سمت گیرنده باید همچنان اسنپ‌شاتی که از آن ارسال می‌کنید را نگه دارد. اگر این‌طور نباشد، دریافت با خطای cannot receive incremental stream: most recent snapshot of backup/data does not match incremental source متوقف می‌شود، زیرا ZFS مبنایی برای اعمال تفاوت‌ها ندارد. از اسنپ‌شاتی ارسال کنید که هر دو سمت آن را دارند، یا با یک ارسال کامل دوباره شروع کنید.

به‌جای استفاده از root از راه دور، دسترسی‌ها را در مقصد اعطا کنید: sudo zfs allow -u backupuser create,mount,receive backup/data.

این یک پشتیبان‌گیری واقعی خارج از سایت (off-site) است، با یک شرط. مقصد نهایی باید یک ZFS pool باشد، زیرا ذخیره‌سازی شیء (object storage) نمی‌تواند یک جریان را دریافت کند. زمانی که مقصد شما یک فضای ذخیره‌سازی سازگار با S3 یا یک میزبان لینوکسی معمولی است، از ابزاری استفاده کنید که با آن ارتباط برقرار می‌کند، و پشتیبان‌گیری restic از یک VPS این مسیر را پوشش می‌دهد.

چرا ZFS از رم زیادی استفاده می‌کند؟ ARC

حافظه ARC (مخفف adaptive replacement cache) کش خواندن در ZFS است. این حافظه به‌جای استفاده از page cache معمولی لینوکس، در حافظه هسته (kernel memory) قرار می‌گیرد؛ بنابراین free -h آن را در بخش buff/cache گزارش نمی‌کند. این مقدار به‌عنوان حافظه در حال استفاده (in use) نمایش داده می‌شود. سروری که از ZFS استفاده می‌کند و رم آن تقریباً پر به نظر می‌رسد، معمولاً دارای یک کش گرم (warm cache) است و همین موضوع دلیل اکثر گزارش‌های «ZFS رم مرا بلعید» است.

محدودیت پیش‌فرض عمداً سخاوتمندانه در نظر گرفته شده است. در OpenZFS 2.3، حداکثر اندازه ARC برابر است با مقدار بزرگ‌تر بین «رم منهای 1 GiB» و «5/8 رم». در OpenZFS 2.2 و نسخه‌های قدیمی‌تر در لینوکس، از نصف رم استفاده می‌شد، در حالی که FreeBSD از قبل از قانون جدیدتر استفاده می‌کرد. دستور zfs version را اجرا کنید تا ببینید کدام قانون برای شما اعمال می‌شود.

[
  {
    "label": "2 GB VPS",
    "openzfs_2_2_linux_gib": 1,
    "openzfs_2_3_gib": 1.25
  },
  {
    "label": "4 GB VPS",
    "openzfs_2_2_linux_gib": 2,
    "openzfs_2_3_gib": 3
  },
  {
    "label": "8 GB VPS",
    "openzfs_2_2_linux_gib": 4,
    "openzfs_2_3_gib": 7
  },
  {
    "label": "16 GB VPS",
    "openzfs_2_2_linux_gib": 8,
    "openzfs_2_3_gib": 15
  }
]

این ارقام، قانون پیش‌فرض مستندشده برای اندازه‌های رایج نمونه‌ها (instances) هستند و نه اندازه‌گیری‌های واقعی از یک سرور در حال اجرا. در یک نمونه 4 GB، قانون نسخه 2.3 اجازه می‌دهد ARC تا 3 GiB باشد. همان سرور در نسخه 2.2 در مقدار 2 GiB متوقف می‌شود. یک نمونه 2 GB تحت قانون 2.3 همچنان اجازه می‌دهد 1.25 GiB استفاده شود. برنامه شما به آنچه باقی می‌ماند دسترسی خواهد داشت.

به‌جای اعتماد به جدول، اعداد واقعی را از سرور خود بخوانید:

grep -E '^(size|c_max) ' /proc/spl/kstat/zfs/arcstats
arc_summary | head -n 20

ستون سوم نشان‌دهنده بایت‌ها است. c_max سقف فعلی اعمال‌شده است و size مقداری است که ARC در حال حاضر در خود نگه داشته است.

ARC حافظه را پس می‌دهد. هسته فشار حافظه را اعلام می‌کند و ARC کوچک می‌شود. مشکل در زمان‌بندی است، زیرا کوچک‌شدن با آن فشار تحریک می‌شود؛ بنابراین فرآیندی که ناگهان چندین صد MiB درخواست می‌کند، ممکن است پیش از آنکه ARC حافظه را آزاد کند، با OOM (مخفف out of memory) killer مواجه شود. در یک سرور 2 GB که دیتابیس و وب‌سرور روی آن اجرا می‌شود، این اتفاق نادر نیست. دفترچه راهنمای OpenZFS در مورد تغییرات دستی نیز همین نکته را می‌گوید: کاهش محدودیت «باعث کوچک‌شدن ARC نمی‌شود مگر اینکه فشار حافظه برای تحریک آن وجود داشته باشد».

نحوه محدود کردن ARC در یک VPS کوچک

ابتدا بار کاری حافظه را تعیین کنید. مجموع نیاز دیتابیس و اپلیکیشن را محاسبه کنید، مقداری حاشیه برای سیستم‌عامل در نظر بگیرید و باقی‌مانده را به ARC اختصاص دهید. در یک نمونه 4 GB که Postgres و یک اپلیکیشن وب را اجرا می‌کند، اختصاص 512 MiB تا 1 GiB به ARC نقطه شروع معقولی است.

آن را به صورت زنده و بر حسب بایت تنظیم کنید. این مقدار 1 GiB است.

echo 1073741824 | sudo tee /sys/module/zfs/parameters/zfs_arc_max

آن را برای پس از reboot ماندگار کنید.

echo 'options zfs zfs_arc_max=1073741824' | sudo tee /etc/modprobe.d/zfs.conf
sudo update-initramfs -u

مرحله initramfs اهمیت دارد، زیرا ماژول می‌تواند پیش از mount شدن فایل‌سیستم ریشه از initramfs بارگذاری شود؛ این یعنی فایل تنظیماتی که نوشته‌اید خوانده نخواهد شد. پس از reboot، با استفاده از خط c_max از arcstats آن را تأیید کنید.

دو نکته مهم در خود راهنما ذکر شده است. شما نمی‌توانید مقدار را در حین اجرای سیستم به 0 برگردانید، بنابراین برای لغو این تنظیم باید فایل را ویرایش کرده و سیستم را reboot کنید. همچنین کاهش عدد، ARC بزرگ را بلافاصله کوچک نمی‌کند.

در FreeBSD همین محدودیت یک sysctl تحت vfs.zfs.arc است. دستور sysctl vfs.zfs.arc را اجرا کنید تا مقادیر فعلی و نام دقیق مورد استفاده در نسخه خود را ببینید، سپس مقدار حداکثر را در /boot/loader.conf بنویسید.

دو قانون حافظه دیگر برای سرور کوچک: deduplication را غیرفعال نگه دارید، زیرا جدول dedup در حافظه قرار می‌گیرد و قاعده کلی منتشر شده، اختصاص 1 تا 3 GB رم به ازای هر TB داده منحصربه‌فرد است. همچنین swap را روی zvol (یک بلاک دیوایس که از pool جدا شده) قرار ندهید، زیرا swap کردن از طریق فایل‌سیستمی که در حال تلاش برای آزاد کردن حافظه است، می‌تواند باعث deadlock شدن ماشین شود. swap را روی یک پارتیشن ساده یا یک فایل swap خارج از pool نگه دارید.

چه زمانی ext4 یا XFS به همراه restic گزینه بهتری است

ZFS در سروری که حافظه رم مازاد و یک درایو دوم دارد، ارزش خود را نشان می‌دهد. در غیر این صورت، استفاده از یک فایل‌سیستم ساده به همراه یک ابزار پشتیبان‌گیری واقعی، انتخاب بهتری است. در شرایط زیر ext4 یا XFS را انتخاب کنید:

• نمونه (instance) شما دارای 2 GB یا 4 GB رم است و بار کاری (workload) به تمام آن نیاز دارد.
• تنها یک دیسک مجازی دارید و نسخه دومی وجود ندارد؛ بنابراین ZFS فقط خرابی را تشخیص می‌دهد اما نمی‌تواند آن را تعمیر کند.
• مقصد پشتیبان‌گیری شما object storage یا یک میزبان لینوکسی ساده است و هیچ‌کدام نمی‌توانند جریان zfs send را دریافت کنند.
• از Debian با DKMS استفاده می‌کنید و نمی‌توانید ریسک ارتقای هسته‌ای را بپذیرید که در آن ماژول ZFS ساخته نمی‌شود.
• به ZFS روی فایل‌سیستم روت نیاز دارید اما ایمیج‌های ارائه‌دهنده سرویس فقط ext4 را پشتیبانی می‌کنند.

زمانی ZFS را حفظ کنید که یک درایو داده مجزا، رم کافی (8 GB و بالاتر وضعیت مطلوبی است) و برنامه‌ای برای استفاده از snapshotها و zfs send داشته باشید، نه اینکه صرفاً آن‌ها را فعال کنید. برای سایر موارد، استفاده از ext4 به همراه restic برای نوشتن پشتیبان‌های رمزنگاری‌شده و deduplicate‌شده در فضایی که سرور کنترلی روی آن ندارد، اکثر نیازها را بدون اشغال حافظه رم پوشش می‌دهد.

حالت‌های شکست و پیام‌های مربوطه

استخر (pool) پس از reboot ناپدید می‌شود. دستور zpool status خروجی no pools available را نمایش می‌دهد. سرویس import فایل /etc/zfs/zpool.cache را می‌خواند، بنابراین اگر استخری در این فایل نباشد، در زمان بوت import نمی‌شود. دستور sudo zpool import موارد قابل import را لیست می‌کند، sudo zpool import tank آن را بازمی‌گرداند و sudo zpool set cachefile=/etc/zfs/zpool.cache tank وضعیت را دائمی می‌کند. استخری که به‌درستی از سیستم دیگری export نشده باشد، خطای cannot import 'tank': pool may be in use from other system را گزارش می‌دهد و اگر مطمئن هستید هیچ میزبان دیگری از آن استفاده نمی‌کند، sudo zpool import -f tank این وضعیت را نادیده می‌گیرد.

خطای modprobe: FATAL: Module zfs not found in directory /lib/modules/6.12.0-... در Debian پس از ارتقای هسته (kernel). ماژول DKMS برای هسته جدید ساخته نشده است، معمولاً به این دلیل که headerهای منطبق نصب نیستند. دستور dkms status نشان می‌دهد چه چیزی برای کدام هسته ساخته شده است. سپس sudo apt install -y linux-headers-$(uname -r) و به دنبال آن sudo dkms autoinstall آن را بازسازی می‌کنند و sudo zpool import tank استخر را بازمی‌گرداند.

استخر پر است اما فایل‌ها را حذف کرده‌اید. داده‌های حذف‌شده تا زمانی که یک snapshot به آن‌ها ارجاع می‌دهد روی دیسک باقی می‌مانند، بنابراین خروجی du و df با هم همخوانی ندارند. دستور zfs list -o space -r tank میزان مصرف را به USEDDS و USEDSNAP تقسیم می‌کند و مقدار زیاد USEDSNAP پاسخ شماست. snapshotهای قدیمی را با sudo zfs destroy tank/data@2026-06-01 حذف کنید تا فضا آزاد شود.

افزایش شمارنده CKSUM در zpool status. لایه‌ای پایین‌تر از ZFS داده‌های نادرستی برگردانده است. در یک mirror، این شمارنده صرفاً یک هشدار است و بلوک مربوطه ترمیم شده است. در یک استخر تک‌دیسکی، فایل از دست رفته است، zpool status -v نام آن را مشخص می‌کند و شما باید آن فایل خاص را از نسخه‌ پشتیبانی که در این استخر نیست، بازیابی کنید.

سرور کند است و از swap استفاده می‌کند. محدودیت ARC را طبق روش بالا اعمال کنید، سپس arc_summary را اجرا کرده و نسبت hit ratio را بررسی کنید. اگر ARC برای نگهداری working set بسیار کوچک باشد، هر خواندن به دیسک ارجاع داده می‌شود؛ در این نقطه، یک فایل‌سیستم معمولی که از page cache استفاده می‌کند، عملکرد بهتری برای شما خواهد داشت.

FAQ

ZFS روی یک VPS به چه مقدار RAM نیاز دارد؟

ZFS روی یک نمونه با 2 گیگابایت RAM اجرا می‌شود. پرسش اصلی این است که چه مقدار برای برنامهٔ شما باقی می‌ماند. بدون تنظیمات دستی، OpenZFS 2.3 اجازه می‌دهد ARC تا سقف بزرگ‌تر از مقدار (RAM منهای 1 گیگابایت) و (5/8 کل RAM) رشد کند؛ بنابراین یک سرور 4 گیگابایتی می‌تواند 3 گیگابایت را به کش اختصاص دهد. مقدار zfs_arc_max را روی عددی تنظیم کنید که بار کاری شما توانایی صرف‌نظر از آن را داشته باشد، سپس با خواندن خط c_max از /proc/spl/kstat/zfs/arcstats آن را تأیید کنید.

آیا اسنپ‌شات ZFS یک نسخهٔ پشتیبان (Backup) محسوب می‌شود؟

خیر. اسنپ‌شات در همان pool داده‌ها زندگی می‌کند. اسنپ‌شات در برابر یک rm بد و ارتقای ناموفق سالم می‌ماند، اما با از بین رفتن pool یا سرور، آن هم از بین می‌رود. برای تبدیل آن به نسخهٔ پشتیبان، آن را با استفاده از zfs send به ماشین دیگری بفرستید، یا از ابزار پشتیبان‌گیری استفاده کنید که داده‌ها را روی فضایی ذخیره می‌کند که این سرور کنترلی روی آن ندارد.

آیا عملکرد ZFS در FreeBSD و Linux یکسان است؟

از زمان OpenZFS 2.0 در دسامبر 2020، کدبیس (codebase) یکسان است، دستورات مشابه هستند، فرمت روی دیسک یکسان است و poolها بین این دو سیستم‌عامل قابل جابه‌جایی هستند. تفاوت در بسته‌بندی (packaging) است. FreeBSD سیستم ZFS را در سیستم پایه (base system) ارائه می‌دهد. در لینوکس، هر توزیع تصمیم‌گیرنده است: اوبونتو ماژول را درون بسته‌های هسته (kernel) خود می‌سازد، در حالی که دبیان آن را با استفاده از DKMS روی ماشین شما کامپایل می‌کند؛ بنابراین ممکن است پس از ارتقای هسته، تا زمانی که بازسازی (rebuild) با موفقیت انجام نشود، ماژول در دسترس نباشد.

آیا ZFS می‌تواند خرابی داده‌ها را در یک VPS با یک دیسک تعمیر کند؟

ZFS خرابی را تشخیص می‌دهد و نام فایل را اعلام می‌کند، اما نمی‌تواند آن را تعمیر کند، زیرا تعمیر نیازمند یک کپی دوم از آن بلاک است. تنظیم zfs set copies=2 روی یک dataset، آن کپی دوم را با دو برابر کردن فضای مصرفی در اختیار شما قرار می‌دهد که خرابی یک بلاک را پوشش می‌دهد، اما در برابر از دست رفتن کل volume کاری انجام نمی‌دهد. راهکار واقعی برای ترمیم داده‌ها، ایجاد یک mirror بین دو volume است.

آیا فشرده‌سازی باعث کندی سرور می‌شود؟

lz4 معمولاً باعث افزایش سرعت می‌شود. بلاک‌های فشرده به معنای نوشتن و خواندن بایت‌های کمتر است و هزینهٔ پردازشی برای هر بلاک در مقایسه با فضای دیسکی که ذخیره می‌شود، ناچیز است. مقدار compression=lz4 را در ریشهٔ pool تنظیم کنید تا همهٔ datasetها آن را به ارث ببرند، سپس پس از نوشتن داده‌های واقعی، zfs get compressratio tank را بررسی کنید.