آموزش Restic؛ راهنمای ساده بکاپ‌گیری و بازیابی اطلاعات

اگر روی کامپیوتر یا سرور خود فایل‌های مهمی دارید، داشتن یک نسخه پشتیبان یکی از ضروری‌ترین کارهایی است که باید انجام دهید. خرابی هارد، حذف اشتباهی فایل‌ها، حمله باج‌افزاری یا حتی یک خطای ساده می‌تواند باعث از بین رفتن اطلاعات شود.

یکی از ابزارهای قدرتمند برای این کار Restic است.

Restic یک ابزار متن‌باز برای بکاپ‌گیری و بازیابی اطلاعات است که به‌صورت خط فرمان کار می‌کند و می‌تواند بکاپ‌ها را روی حافظه محلی، سرورهای دیگر، SFTP، سرویس‌های S3 و بسیاری از سرویس‌های ذخیره‌سازی دیگر نگهداری کند.

نکته مهم این است که برای استفاده از Restic لازم نیست متخصص سیستم‌های پشتیبان‌گیری باشید. اگر با چند دستور ساده خط فرمان آشنا باشید، می‌توانید یک سیستم بکاپ قابل اعتماد برای کامپیوتر شخصی یا سرور خود راه‌اندازی کنید.

در این آموزش از ابتدا توضیح می‌دهیم Restic چیست، چگونه نصب می‌شود، Repository و Snapshot چه هستند، چطور بکاپ بگیریم، چگونه فایل‌ها را برگردانیم و چطور سلامت بکاپ‌ها را بررسی کنیم.


Restic چیست؟

Restic یک نرم‌افزار متن‌باز و خط فرمانی برای تهیه نسخه پشتیبان از فایل‌ها و دایرکتوری‌ها است.

برخلاف روش‌های ساده‌ای مثل کپی کردن یک پوشه به هارد دیگر، Restic اطلاعات را در ساختاری به نام Repository ذخیره می‌کند و از قابلیت‌هایی مانند رمزنگاری، حذف داده‌های تکراری و نگهداری چندین Snapshot استفاده می‌کند.

به زبان ساده، می‌توان Restic را این‌طور تصور کرد:

فایل‌های شما
     │
     ▼
   Restic
     │
     ├── رمزنگاری
     ├── حذف داده‌های تکراری
     └── ایجاد Snapshot
             │
             ▼
        Repository
             │
       ┌─────┼─────┐
       ▼     ▼     ▼
      Disk  SFTP   S3

Repository می‌تواند روی همان کامپیوتر، یک سرور دیگر یا یک فضای ذخیره‌سازی ابری قرار داشته باشد.

مستندات رسمی Restic نیز Repository را محل ذخیره فایل‌های بکاپ، اطلاعات مربوط به آن‌ها و کلیدهای رمزنگاری معرفی می‌کند.


چرا از Restic استفاده کنیم؟

Restic چند ویژگی مهم دارد که آن را برای بکاپ کامپیوتر و سرور مناسب می‌کند.

۱. رمزنگاری بکاپ‌ها

اطلاعات موجود در Repository به‌صورت رمزنگاری‌شده ذخیره می‌شوند.

Restic برای رمزنگاری داده‌ها از AES-256 استفاده می‌کند و داده‌ها نیز احراز اصالت می‌شوند تا تغییرات ناخواسته یا خراب شدن اطلاعات قابل تشخیص باشد.

این موضوع مخصوصاً زمانی اهمیت دارد که بکاپ را روی یک فضای ابری یا سروری ذخیره می‌کنید که کنترل کامل آن را در اختیار ندارید.


۲. جلوگیری از ذخیره چندباره اطلاعات

فرض کنید یک پوشه ۱۰۰ گیگابایتی دارید و هر روز از آن بکاپ می‌گیرید.

اگر فقط یک فایل کوچک ۲۰ مگابایتی تغییر کند، منطقی نیست که هر روز دوباره ۱۰۰ گیگابایت اطلاعات ذخیره شود.

Restic می‌تواند داده‌های تکراری را شناسایی کند و فقط داده‌های جدید را به Repository اضافه کند.

در نتیجه، چندین Snapshot می‌توانند داشته باشید بدون اینکه هر Snapshot الزاماً یک کپی کامل و مستقل از تمام اطلاعات باشد. مستندات رسمی Restic نیز به قابلیت deduplication و ذخیره تنها داده‌های جدید اشاره می‌کند.


Snapshot در Restic چیست؟

یکی از مهم‌ترین مفاهیمی که هنگام کار با Restic باید بدانید Snapshot است.

Snapshot را می‌توان یک تصویر از وضعیت فایل‌های شما در یک زمان مشخص در نظر گرفت.

مثلاً:

شنبه  → Snapshot 1
یکشنبه → Snapshot 2
دوشنبه → Snapshot 3
سه‌شنبه → Snapshot 4

فرض کنید روز شنبه فایل زیر را دارید:

/home/alireza/report.txt

روز یکشنبه آن را تغییر می‌دهید و دوباره بکاپ می‌گیرید.

Restic Snapshot جدیدی ایجاد می‌کند، اما لازم نیست تمام اطلاعات قبلی را دوباره ذخیره کند.

به همین دلیل Snapshotهای Restic با مفهوم «یک فایل فشرده کامل برای هر روز» متفاوت هستند.


Repository چیست؟

Repository محلی است که Restic بکاپ‌ها را در آن نگهداری می‌کند.

برای مثال می‌توانیم Repository را در این مسیر ایجاد کنیم:

/backup/restic

در این حالت:

/backup/restic

Repository ما خواهد بود.

اما Repository الزاماً روی هارد داخلی کامپیوتر قرار ندارد.

Restic از Backendهای مختلفی پشتیبانی می‌کند، از جمله:

  • Local Storage
  • SFTP
  • REST Server
  • Amazon S3
  • S3-compatible Storage
  • Backblaze B2
  • Google Cloud Storage
  • Microsoft Azure Blob Storage
  • Wasabi
  • MinIO
  • برخی سرویس‌ها از طریق rclone

فهرست رسمی مستندات Restic نیز این Backendها را به‌عنوان روش‌های مختلف ساخت Repository معرفی می‌کند.


نصب Restic

روش نصب Restic به سیستم‌عامل شما بستگی دارد.

در بسیاری از توزیع‌های لینوکس می‌توانید آن را از Package Manager نصب کنید.

برای مثال در Debian و Ubuntu:

sudo apt update
sudo apt install restic

بعد از نصب، نسخه Restic را بررسی کنید:

restic version

اگر نصب درست انجام شده باشد، نسخه برنامه نمایش داده می‌شود.

برای سیستم‌عامل‌های دیگر نیز Restic فایل‌های اجرایی و روش‌های نصب مختلفی ارائه می‌کند. مستندات رسمی بخش جداگانه‌ای برای Packages، Binaryهای رسمی، Docker و نصب از Source دارد.


ساخت اولین Repository

حالا فرض کنیم می‌خواهیم بکاپ‌ها را در این مسیر ذخیره کنیم:

/backup/restic

ابتدا دایرکتوری را ایجاد می‌کنیم:

sudo mkdir -p /backup/restic

سپس Repository را ایجاد می‌کنیم:

restic -r /backup/restic init

Restic از شما یک Password می‌خواهد.

این Password بسیار مهم است.

نکته مهم درباره رمز عبور Restic

رمز Repository را فراموش نکنید.

اگر Password مربوط به Repository را از دست بدهید، دسترسی به داده‌های رمزنگاری‌شده Repository را نیز از دست خواهید داد.

بنابراین Password را در یک Password Manager معتبر نگهداری کنید.

Restic امکان داشتن چند Key برای یک Repository را نیز فراهم می‌کند؛ بنابراین در سناریوهای مدیریتی می‌توان چند رمز دسترسی متفاوت برای یک Repository داشت.


اولین بکاپ با Restic

فرض کنیم اطلاعات مهم ما در این مسیر قرار دارد:

/home/alireza/Documents

برای تهیه بکاپ:

restic -r /backup/restic backup /home/alireza/Documents

Restic Password مربوط به Repository را از شما می‌پرسد.

پس از پایان عملیات، Restic یک Snapshot ایجاد می‌کند.

برای مشاهده Snapshotها می‌توانیم از دستور زیر استفاده کنیم:

restic -r /backup/restic snapshots

خروجی چیزی شبیه این خواهد بود:

ID        Time                 Host        Tags
--------------------------------------------------------
a1b2c3d4  2026-09-13 15:20:00  my-pc

شناسه‌ای که در ستون ID مشاهده می‌کنید، شناسه Snapshot است.

مستندات رسمی نیز Snapshot را وضعیت فایل‌ها و دایرکتوری‌ها در یک نقطه مشخص از زمان تعریف می‌کند.


بکاپ گرفتن دوباره چه اتفاقی می‌افتد؟

حالا فرض کنیم چند فایل تغییر کرده‌اند.

دوباره همان دستور را اجرا می‌کنیم:

restic -r /backup/restic backup /home/alireza/Documents

Restic فایل‌ها را بررسی می‌کند و اطلاعات جدید را به Repository اضافه می‌کند.

در حالت عادی، داده‌هایی که قبلاً در Repository وجود دارند دوباره ذخیره نمی‌شوند.

به همین دلیل Restic برای بکاپ‌های روزانه یا حتی چند بار در روز بسیار مناسب است.


مشاهده فایل‌های موجود در بکاپ

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

restic -r /backup/restic ls latest

در اینجا:

latest

یعنی آخرین Snapshot.

اگر بخواهید Snapshot مشخصی را مشاهده کنید:

restic -r /backup/restic ls a1b2c3d4

پیدا کردن یک فایل در بکاپ‌ها

گاهی می‌دانیم فایلی را قبلاً بکاپ گرفته‌ایم، اما نمی‌دانیم در کدام Snapshot قرار دارد.

Restic برای پیدا کردن فایل‌ها نیز ابزارهایی دارد.

برای مثال:

restic -r /backup/restic find report.pdf

این دستور می‌تواند محل فایل را در Repository پیدا کند.


بازیابی فایل‌ها با Restic

یکی از مهم‌ترین قسمت‌های هر سیستم بکاپ، Restore است.

بکاپی که امکان بازیابی نداشته باشد، عملاً ارزش زیادی ندارد.

فرض کنیم می‌خواهیم آخرین Snapshot را در این مسیر بازیابی کنیم:

/tmp/restore

دستور:

restic -r /backup/restic restore latest --target /tmp/restore

Restic اطلاعات Snapshot را در مسیر مشخص‌شده بازیابی می‌کند.


بازیابی یک فایل خاص

لازم نیست همیشه کل بکاپ را Restore کنید.

مثلاً اگر فقط فایل زیر را می‌خواهید:

/home/alireza/Documents/report.pdf

می‌توانید از --include استفاده کنید:

restic -r /backup/restic restore latest \
  --target /tmp/restore \
  --include /home/alireza/Documents/report.pdf

در این حالت فقط فایل موردنظر بازیابی می‌شود.

Restic همچنین امکان استفاده از --exclude و انتخاب مسیرهای خاص داخل Snapshot را فراهم می‌کند.


چرا نباید فقط به Backup موفق اعتماد کنیم؟

یکی از اشتباهات رایج این است که:

«دستور Backup بدون خطا اجرا شد، پس همه چیز درست است.»

این فرض همیشه کافی نیست.

Restic دستوری به نام check دارد که برای بررسی سلامت Repository استفاده می‌شود.

مثلاً:

restic -r /backup/restic check

این دستور ساختار Repository و داده‌های موجود را بررسی می‌کند.

خود مستندات Restic نیز توصیه می‌کند restic check به‌صورت منظم اجرا شود تا مشکلات احتمالی Repository زودتر شناسایی شوند.

برای بررسی دقیق‌تر داده‌ها می‌توانید از:

restic -r /backup/restic check --read-data

استفاده کنید.

این بررسی می‌تواند زمان و منابع بیشتری مصرف کند، بنابراین بهتر است متناسب با حجم Repository و سیاست بکاپ شما برنامه‌ریزی شود.


حذف بکاپ‌های قدیمی

اگر هر روز Backup بگیرید، تعداد Snapshotها به‌مرور زیاد می‌شود.

مثلاً:

هر ساعت → 24 Snapshot در روز
هر روز  → 7 Snapshot در هفته
هر هفته → 4 Snapshot در ماه

اگر همه Snapshotها را برای همیشه نگه دارید، Repository می‌تواند به‌مرور بزرگ شود.

Restic برای مدیریت این وضعیت دستور forget دارد.

مثلاً می‌توانید سیاستی تعیین کنید که تعداد مشخصی Snapshot روزانه، هفتگی، ماهانه و سالانه نگهداری شود.

یک نمونه:

restic -r /backup/restic forget \
  --keep-daily 7 \
  --keep-weekly 4 \
  --keep-monthly 12

اما یک نکته مهم وجود دارد.

forget و prune دقیقاً یک کار انجام نمی‌دهند.


تفاوت forget و prune

به زبان ساده:

forget

مشخص می‌کند کدام Snapshotها دیگر نباید نگهداری شوند.

prune

داده‌هایی را که دیگر توسط Snapshotهای باقی‌مانده استفاده نمی‌شوند از Repository حذف می‌کند تا فضای ذخیره‌سازی آزاد شود.

بنابراین در بسیاری از سناریوها ابتدا Snapshotهای قدیمی را با forget مشخص می‌کنیم و سپس با prune داده‌های بلااستفاده را پاک می‌کنیم.

مثلاً:

restic -r /backup/restic forget \
  --keep-daily 7 \
  --keep-weekly 4 \
  --keep-monthly 12 \
  --prune

قبل از اجرای سیاست‌های حذف روی یک Repository مهم، بهتر است ابتدا دقیقاً بررسی کنید چه Snapshotهایی قرار است حذف شوند.


استفاده از Restic برای بکاپ سرور

Restic فقط برای کامپیوتر شخصی نیست.

یکی از کاربردهای بسیار مناسب آن، تهیه Backup از سرورهای لینوکسی است.

فرض کنید روی یک سرور این اطلاعات را داریم:

/etc
/home
/var/www

می‌توانیم یک Repository جداگانه برای بکاپ ایجاد کنیم و سپس:

restic -r /backup/restic backup \
  /etc \
  /home \
  /var/www

البته در سرور واقعی بهتر است قبل از Backup مشخص کنیم دقیقاً چه اطلاعاتی باید ذخیره شوند.

برای مثال معمولاً لازم نیست فایل‌های موقتی یا Cacheها را بکاپ بگیریم.

می‌توانیم با --exclude برخی مسیرها را حذف کنیم:

restic -r /backup/restic backup \
  /var/www \
  --exclude /var/www/example/cache

بکاپ روی سرور دیگر با SFTP

یکی از مزیت‌های Restic این است که Repository می‌تواند روی سیستم دیگری قرار داشته باشد.

برای مثال اگر سرور مقصد این مشخصات را داشته باشد:

backup.example.com

می‌توان Repository را از طریق SFTP استفاده کرد.

ساختار کلی Repository به شکل زیر خواهد بود:

sftp:user@backup.example.com:/backup/restic

این روش برای کسانی مناسب است که یک سرور جداگانه برای نگهداری Backup دارند.

مستندات رسمی Restic پشتیبانی از SFTP را به‌عنوان یکی از روش‌های ایجاد Repository معرفی می‌کند.


استفاده از فضای ابری و S3

Restic می‌تواند Repository را روی Storageهای مبتنی بر S3 نیز نگهداری کند.

این قابلیت باعث می‌شود بتوانید Backup را خارج از سرور اصلی خود نگهداری کنید.

این موضوع از نظر امنیتی اهمیت زیادی دارد.

فرض کنید سرور اصلی شما خراب شود.

اگر Repository نیز روی همان سرور باشد:

Server
 ├── Website
 ├── Database
 └── Backup

خرابی سرور می‌تواند هم اطلاعات اصلی و هم Backup را از بین ببرد.

اما اگر Backup روی یک Storage جداگانه باشد:

Server ──────────────► Backup Storage

ریسک بسیار کمتر می‌شود.

Restic از Amazon S3 و سرویس‌های S3-compatible مختلف پشتیبانی می‌کند.


استفاده از rclone با Restic

اگر سرویس ذخیره‌سازی موردنظر شما به‌صورت مستقیم توسط Restic پشتیبانی نشود، یکی از گزینه‌های مفید استفاده از rclone است.

مستندات Restic نیز استفاده از سرویس‌های دیگر از طریق rclone را در فهرست Backendهای خود قرار داده است.

این قابلیت تعداد زیادی از سرویس‌های ذخیره‌سازی را در دسترس Restic قرار می‌دهد.


آیا Restic فایل‌ها را فشرده می‌کند؟

Restic می‌تواند داده‌های Backup را فشرده کند.

در نسخه‌های جدید Repository Format 2 از Compression پشتیبانی می‌کند. مستندات رسمی فعلی Restic نیز Compression را در بخش قابلیت‌های Repository و تنظیمات معرفی کرده است.

البته میزان کاهش حجم به نوع اطلاعات شما بستگی دارد.

مثلاً فایل‌های متنی معمولاً قابلیت فشرده‌سازی خوبی دارند، اما فایل‌هایی مانند:

.jpg
.mp4
.zip
.rar

معمولاً از قبل فشرده شده‌اند و فشرده‌سازی مجدد آن‌ها ممکن است تأثیر زیادی نداشته باشد.


رمزنگاری Restic چگونه کار می‌کند؟

یکی از نقاط قوت Restic، رمزنگاری داخلی آن است.

اطلاعات Repository به‌صورت رمزنگاری‌شده ذخیره می‌شوند و Restic از کلیدهای رمزنگاری برای محافظت از داده‌ها استفاده می‌کند. مستندات فنی Restic جزئیات استفاده از AES-256 و Poly1305-AES را توضیح می‌دهد.

به همین دلیل اگر Repository را روی یک فضای ذخیره‌سازی شخص ثالث قرار دهید، ارائه‌دهنده Storage به‌سادگی نمی‌تواند محتوای فایل‌های Backup را به شکل اصلی مشاهده کند.

البته این موضوع یک شرط مهم دارد:

Password Repository را باید به‌خوبی محافظت کنید.


آیا Restic برای بکاپ‌گیری خودکار مناسب است؟

بله.

Restic خودش یک Scheduler داخلی دائمی نیست؛ یعنی معمولاً برنامه را اجرا می‌کنید و عملیات Backup انجام می‌شود.

برای اجرای خودکار می‌توانید از ابزارهای سیستم‌عامل استفاده کنید.

در Linux گزینه‌های رایج عبارت‌اند از:

  • Cron
  • systemd timer

در Windows نیز می‌توان از:

  • Task Scheduler

استفاده کرد.

مستندات Restic نیز صراحتاً اشاره می‌کند که خود Restic زمان‌بندی داخلی برای اجرای دوره‌ای Backup ندارد و استفاده از ابزارهایی مانند systemd و cron یا Task Scheduler را پیشنهاد می‌کند.


یک سناریوی ساده برای بکاپ روزانه

فرض کنید می‌خواهیم هر روز از این مسیر بکاپ بگیریم:

/home/alireza/Documents

و Repository در این مسیر قرار دارد:

/backup/restic

دستور اصلی:

restic -r /backup/restic backup /home/alireza/Documents

بعد از آن می‌توانیم به‌صورت دوره‌ای:

restic -r /backup/restic check

را اجرا کنیم.

و برای مدیریت Snapshotهای قدیمی:

restic -r /backup/restic forget \
  --keep-daily 7 \
  --keep-weekly 4 \
  --keep-monthly 12 \
  --prune

این یعنی مثلاً:

  • ۷ Snapshot روزانه
  • ۴ Snapshot هفتگی
  • ۱۲ Snapshot ماهانه

نگهداری شود.

مقادیر دقیق باید بر اساس اهمیت اطلاعات، فضای ذخیره‌سازی و نیاز به نگهداری نسخه‌های قدیمی انتخاب شوند.


یک نکته مهم درباره Password در Backup خودکار

وقتی Restic را به‌صورت دستی اجرا می‌کنیم، می‌توانیم Password را وارد کنیم.

اما برای Backup خودکار چنین کاری ممکن نیست.

Restic روش‌هایی مانند:

RESTIC_PASSWORD_FILE

و:

RESTIC_PASSWORD_COMMAND

را برای تأمین خودکار Password ارائه می‌کند.

برای مثال می‌توان Password را در یک فایل با Permission محدود نگهداری کرد:

chmod 600 /root/.restic-password

و سپس:

export RESTIC_PASSWORD_FILE=/root/.restic-password

نکته امنیتی مهم این است که Password را به‌صورت مستقیم داخل Command Line قرار ندهید؛ چون در برخی شرایط ممکن است در Process List قابل مشاهده باشد. مستندات رسمی Restic نیز درباره این موضوع هشدار داده است.


آیا می‌توان از چند کامپیوتر در یک Repository بکاپ گرفت؟

بله.

یکی از قابلیت‌های مفید Restic این است که چند سیستم می‌توانند از یک Repository استفاده کنند.

مثلاً:

Laptop ──────┐
             │
Desktop ─────┼──► Restic Repository
             │
Server ──────┘

Restic برای Snapshotها اطلاعاتی مانند Host و Path را نگهداری می‌کند و امکان گروه‌بندی و فیلتر کردن Snapshotها وجود دارد.

این قابلیت برای داشتن یک Storage مرکزی Backup بسیار کاربردی است.


اگر Backup وسط کار قطع شود چه اتفاقی می‌افتد؟

قطع شدن اتصال اینترنت یا خاموش شدن سیستم هنگام Backup لزوماً به معنی خراب شدن کل Repository نیست.

ساختار Repository Restic به‌گونه‌ای طراحی شده که عملیات‌هایی مانند backup و prune بتوانند در صورت قطع شدن متوقف شوند بدون اینکه لزوماً کل Repository خراب شود؛ البته ممکن است در برخی شرایط نیاز به بررسی یا unlock وجود داشته باشد.

بعد از مشکلات غیرعادی، بررسی Repository با:

restic -r /backup/restic check

کار مناسبی است.


چند دستور مهم Restic

اگر تازه با Restic شروع کرده‌اید، این دستورات را بهتر است به خاطر بسپارید:

دستور کاربرد
init ساخت Repository جدید
backup تهیه Backup
snapshots نمایش Snapshotها
ls نمایش فایل‌های یک Snapshot
find پیدا کردن فایل در Backup
restore بازیابی اطلاعات
check بررسی سلامت Repository
forget حذف/فراموش کردن Snapshotهای قدیمی
prune حذف داده‌های بلااستفاده
mount مشاهده Backup به شکل یک فایل‌سیستم

مثلاً یک گردش کار ساده می‌تواند این باشد:

init
  ↓
backup
  ↓
snapshots
  ↓
check
  ↓
forget
  ↓
prune

و در صورت نیاز:

restore

اشتباهات رایج هنگام استفاده از Restic

۱. نگهداری Backup روی همان هارد

اگر اطلاعات و Backup هر دو روی یک هارد باشند، خرابی هارد می‌تواند هر دو را از بین ببرد.

Backup بهتر است روی یک Storage جداگانه نگهداری شود.


۲. فراموش کردن Password

Repository رمزنگاری شده است و Password بخش مهمی از دسترسی به اطلاعات آن است.

Password را در یک Password Manager مطمئن نگهداری کنید.


۳. هیچ‌وقت Restore را آزمایش نکردن

ممکن است Backup ظاهراً موفق باشد اما شما هرگز بازیابی آن را امتحان نکرده باشید.

هر چند وقت یک‌بار یک فایل یا مجموعه‌ای از فایل‌ها را در یک دایرکتوری موقت Restore کنید و مطمئن شوید Backup واقعاً قابل استفاده است.


۴. اجرا نکردن check

صرفاً گرفتن Backup کافی نیست.

بررسی سلامت Repository نیز باید بخشی از برنامه Backup شما باشد. مستندات Restic اجرای منظم check را برای اطمینان از سلامت ساختار Repository توصیه می‌کند.


۵. نگهداری بی‌نهایت Snapshot

اگر هیچ سیاستی برای حذف Snapshotهای قدیمی نداشته باشید، حجم Repository به‌مرور افزایش پیدا می‌کند.

استفاده درست از forget و prune می‌تواند این مشکل را مدیریت کند.


آیا Restic برای شما مناسب است؟

Restic گزینه بسیار خوبی است اگر:

  • با Linux یا Command Line مشکلی ندارید.
  • می‌خواهید Backup رمزنگاری‌شده داشته باشید.
  • می‌خواهید Backup روی سرور یا فضای ابری نگهداری شود.
  • به Deduplication نیاز دارید.
  • می‌خواهید چندین نسخه از فایل‌ها را نگهداری کنید.
  • می‌خواهید یک سیستم Backup سبک و قابل اسکریپت‌نویسی داشته باشید.
  • می‌خواهید Backup را بدون وابستگی به یک نرم‌افزار گرافیکی مدیریت کنید.

اما اگر با Command Line کاملاً راحت نیستید و یک نرم‌افزار کاملاً گرافیکی می‌خواهید، شاید ابزارهای دیگری برای شما مناسب‌تر باشند.


جمع‌بندی

Restic یک ابزار ساده اما قدرتمند برای Backup و Restore است.

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

Repository
Snapshot
Backup
Restore
Check
Forget
Prune

با همین چند مفهوم می‌توانید یک سیستم Backup نسبتاً حرفه‌ای ایجاد کنید.

یک سناریوی ساده می‌تواند این باشد:

                ┌──────────────┐
                │  Computer    │
                │              │
                │ /home/user   │
                └──────┬───────┘
                       │
                    restic
                       │
                       ▼
                ┌──────────────┐
                │  Repository  │
                │              │
                │ Encrypted    │
                │ Deduplicated │
                └──────┬───────┘
                       │
              ┌────────┼────────┐
              ▼        ▼        ▼
             Disk     SFTP      S3

نکته اصلی این است که Backup فقط به معنی «کپی کردن فایل‌ها» نیست. یک سیستم Backup خوب باید بتواند اطلاعات را در چند نقطه زمانی نگهداری کند، از آن‌ها در برابر دسترسی غیرمجاز محافظت کند، سلامت داده‌ها را بررسی کند و مهم‌تر از همه، در زمان نیاز امکان Restore واقعی آن‌ها را فراهم کند.

Restic این امکانات را در قالب یک ابزار خط فرمان نسبتاً ساده در اختیار شما قرار می‌دهد.

برای مطالعه جزئیات فنی و همه قابلیت‌های Restic، می‌توانید به مستندات رسمی Restic مراجعه کنید.