Restic மூலம் VPS தரவுகளை பாதுகாப்பாக பேக்கப் எடுப்பது

ஒரே server-ல் எடுக்கப்படும் backup ஏன் உண்மையான backup அல்ல

Restic என்பது ஒரு இலவச, open source backup கருவியாகும். இது உங்கள் கோப்புகளின் encrypted மற்றும் deduplicated snapshots-களை வேறொரு இடத்திற்கு, அதாவது மற்றொரு VPS, வீட்டில் உள்ள ஒரு கணினி அல்லது S3-compatible object storage-க்கு அனுப்புகிறது. இந்த வழிகாட்டி Ubuntu 24.04-ல் இதை எவ்வாறு அமைப்பது என்பதை விளக்குகிறது: நிறுவுதல், SFTP வழியாக repository-ஐ உருவாக்குதல், முதல் backup, nightly systemd timer, retention policy மற்றும் முழு அமைப்பும் சரியாக வேலை செய்கிறதா என்பதை உறுதிப்படுத்தும் restore பயிற்சி ஆகியவற்றை இது உள்ளடக்கியுள்ளது. backup சேமிக்கப்படும் இடம் வேறொரு கணினியாக இருக்க வேண்டும்; ஏனெனில் ஒரே server-ல் இருக்கும் நகல், அந்த server செயலிழக்கும்போது அழிந்துவிடும்.

நீங்கள் backup எடுக்கும் அதே server-ல் உள்ள ஒரு backup/ directory, கோப்புகளைத் தவறுதலாக அழிப்பதிலிருந்து மட்டுமே உங்களைப் பாதுகாக்கும். வட்டு (disk) பழுதடைந்தால், அந்த வட்டில் உள்ள backup-ம் அழிந்துவிடும் என்பதால் அது உதவாது. root access கொண்ட ஒரு தாக்குதல் நடத்துபவர், முதலில் அந்த backup நகல்களை அழித்துவிடுவார் என்பதால் அதிலிருந்தும் பாதுகாப்பு கிடைக்காது. VPS-ஐயே நீக்கிவிடும் ஒரு கணக்குத் தவறு நடந்தாலும் இந்த backup உதவாது. உலகின் மிகத் திறமையற்ற தரவு மையம் (The world's least efficient datacenter) என்ற கட்டுரை, தரவுகள் இருக்கும் அதே array-ல் backup_final_v2_REAL என்ற பெயரில் ஒரு tarball-ஐ வைத்திருப்பதை நகைச்சுவையாகக் குறிப்பிடுகிறது. நம்மில் பலர் இப்படிச் செய்திருப்பதால் தான் அந்த நகைச்சுவை உண்மையாகிறது. தரவுகளை server-க்கு வெளியே வைப்பதே சரியான முறை; அதைச் செய்வதற்கு restic மிக எளிதான வழியாகும்.

Restic நான்கு முக்கிய கருத்துகளில்

Repository. Restic தரவுகளை எழுதும் இடம். இது restic-ன் சொந்த வடிவமைப்பில் உள்ள ஒரு directory ஆகும். இதில் குறியாக்கம் செய்யப்பட்ட (encrypted) blobs மட்டுமே இருக்கும்; restic-ஆல் மட்டுமே இதை வாசிக்க முடியும். இதை நீங்கள் கைமுறையாக மாற்றக்கூடாது; restic கட்டளைகள் மற்றும் -r முகவரி மூலமாகவே இதனுடன் தொடர்பு கொள்ள வேண்டும்.

Snapshot. நீங்கள் backup செய்த கோப்புகளின் ஒரு குறிப்பிட்ட காலக்கட்டத்தின் பிரதி. ஒவ்வொரு backup செயல்பாடும் ஒரு snapshot-ஐ உருவாக்குகிறது. ஒவ்வொரு snapshot-ஐயும் தனித்தனியாக மீட்டெடுக்க முடியும். அந்தந்த நேரத்தில் உங்கள் தரவுகளின் முழுமையான நகலாக இது செயல்படும்.

Deduplication. Restic கோப்புகளை உள்ளடக்கத்தின் அடிப்படையில் சிறு பகுதிகளாகப் (chunks) பிரிக்கிறது. repository-ல் ஏற்கனவே இல்லாத பகுதிகளை மட்டுமே இது பதிவேற்றுகிறது. முதல் backup-ல் அனைத்தும் பதிவேற்றப்படும்; அதன் பிறகு நடக்கும் ஒவ்வொரு backup-லும் மாற்றமடைந்த பகுதிகள் மட்டுமே பதிவேற்றப்படும். 20 GB தரவில் 50 MB மட்டுமே மாறியிருந்தால், அந்த nightly snapshot-க்கு 50 MB மட்டுமே செலவாகும். இதனால்தான் பல snapshot-களைச் சேமிப்பது எளிதானது.

Encryption by default. Restic repository எப்போதும் குறியாக்கம் (AES-256) செய்யப்பட்டிருக்கும். ஒவ்வொரு கட்டளைக்கும் repository கடவுச்சொல் தேவை. backup செய்யும் host அல்லது storage provider-க்கு குறியாக்கம் செய்யப்பட்ட blobs மட்டுமே தெரியும். இதன் கடுமையான விளைவு: கடவுச்சொல்லைத் தொலைத்துவிட்டால், தரவுகள் நிரந்தரமாக இழக்கப்படும். இது வடிவமைப்பிலேயே சேர்க்கப்பட்டுள்ளது. கடவுச்சொல்லின் நகலை இந்த server அல்லாத வேறொரு இடத்தில் பாதுகாப்பாக வைக்கவும். இது மிக முக்கியமானது என்பதால் கீழே மேலும் இரண்டு முறை குறிப்பிடப்பட்டுள்ளது.

Ubuntu 24.04-ல் restic-ஐ நிறுவுதல்

sudo apt update && sudo apt install -y restic
restic version

Ubuntu 24.04-ல் இது restic 0.16.4 பதிப்பை நிறுவுகிறது, ஆனால் தற்போதைய upstream release 0.19.1 ஆகும். ஒரு LTS (long term support) release அதன் package பதிப்புகளை மாற்றாமல் வைத்திருப்பதால் இந்த இடைவெளி ஏற்படுகிறது, ஆனால் இது இங்கே ஒரு சிக்கல் அல்ல: இந்த வழிகாட்டியில் உள்ள அனைத்து செயல்பாடுகளையும் 0.16.4 பதிப்பிலேயே செய்ய முடியும். வேக மேம்பாடுகளுக்காக உங்களுக்கு புதிய release தேவைப்பட்டால், restic திட்டத்தின் GitHub releases பக்கத்திலிருந்து அதிகாரப்பூர்வ single-binary build-ஐ தரவிறக்கம் செய்து, அதை bunzip2 மூலம் பிரித்தெடுத்து, /usr/local/bin/restic-க்கு நகர்த்தவும்; restic நிறுவுதலுக்கு இதைத் தவிர வேறு எதுவும் தேவையில்லை.

மற்றொரு server-ல் SFTP வழியாக repository-ஐ உருவாக்குதல்

உங்களுக்கு ஒரு destination machine தேவை: பொதுவாக ஒரு சிறிய இரண்டாவது VPS இதற்குப் போதுமானது, SSH server மற்றும் போதிய disk இடம் உள்ள எந்தவொரு கணினியும் இதற்குச் சரியாக இருக்கும். Restic, SFTP (SSH வழியாக கோப்பு பரிமாற்றம்) மூலம் செயல்படுவதால், backup host-ல் எந்த மென்பொருளையும் நிறுவ வேண்டிய அவசியமில்லை. இந்த வழிகாட்டியில், backup host என்பது 10.0.0.12 மற்றும் அதில் உள்ள பயனர் restic ஆவார். அந்த பயனருக்கு backup என்று பெயரிட வேண்டாம்: Ubuntu மற்றும் Debian-ன் ஒவ்வொரு நிறுவலிலும் backup (uid 34, login shell கிடையாது) என்ற ஒதுக்கப்பட்ட system account உள்ளது, எனவே adduser backup தோல்வியடையும் மற்றும் ssh backup@... என்பது nologin-ல் முடிவடையும்.

தினசரி இரவு நடக்கும் backup பணி, backup செய்யப்படும் server-ல் root பயனராக இயங்கும், எனவே root பயனருக்கு backup host-ல் key login தேவை. Passphrase இல்லாத ஒரு பிரத்யேக key-ஐ உருவாக்கவும், ஏனெனில் அதிகாலை 3 மணிக்கு அதை உள்ளிட மனிதர்கள் யாரும் இருக்க மாட்டார்கள், மேலும் அதை நகலெடுக்கவும்:

sudo ssh-keygen -t ed25519 -f /root/.ssh/id_ed25519 -N "" -C "web1-restic"
sudo ssh-copy-id -i /root/.ssh/id_ed25519.pub restic@10.0.0.12
sudo ssh restic@10.0.0.12 true && echo key login works

Key-கள் உங்களுக்குப் புதியவை என்றால், SSH key மேலாண்மை அடிப்படைகள் அதன் மாதிரி, அனுமதிகள் மற்றும் ஒரு key-ஐ எவ்வாறு பின்னர் நீக்குவது என்பதை விளக்குகிறது.

அடுத்து, repository கடவுச்சொல். Root பயனருக்கு மட்டும் அணுகக்கூடிய கோப்பில் வலுவான கடவுச்சொல்லை உருவாக்கவும்:

openssl rand -base64 32 | sudo tee /root/.restic-password
sudo chmod 600 /root/.restic-password

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

Repository-ஐ initialize செய்யவும்:

sudo restic -r sftp:restic@10.0.0.12:/srv/restic/web1 --password-file /root/.restic-password init

created restic repository 9f3c2a1b0d at sftp:restic@10.0.0.12:/srv/restic/web1

இதற்கு மாற்றாக S3-compatible object storage-ஐப் பயன்படுத்தலாம், இரண்டாவது machine-ஐ இயக்க விரும்பாதபோது இதுவே சரியான தேர்வாகும். எந்தவொரு S3-compatible bucket-ம் ஒரே மாதிரியாகவே செயல்படும்; முகவரி மற்றும் இரண்டு credential மாறிகள் மட்டுமே மாறும்:

export AWS_ACCESS_KEY_ID=your-key-id
export AWS_SECRET_ACCESS_KEY=your-secret-key
sudo -E restic -r s3:https://s3.example.com/web1-backups --password-file /root/.restic-password init

init-க்கு பிறகு உள்ள அனைத்தும் இரண்டு destination-களுக்கும் ஒரே மாதிரியானவை. இந்த வழிகாட்டியின் மீதமுள்ள பகுதி SFTP முகவரியைக் காட்டுகிறது; அதற்குப் பதிலாக உங்களுடையதை மாற்றிக்கொள்ளவும்.

முதல் backup, தவிர்க்க வேண்டியவற்றுடன்

மீண்டும் நிறுவ முடியாத தரவுகளை மட்டும் backup செய்யுங்கள், முழு filesystem-ஐயும் அல்ல. Operating system-ஐ மீண்டும் நிறுவிக்கொள்ள முடியும்; ஆனால் உங்கள் configuration மற்றும் தரவுகளை அவ்வாறு செய்ய முடியாது. ஒரு பொதுவான VPS-க்கு, /etc, /home மற்றும் உங்கள் applications தரவுகளைச் சேமிக்கும் இடங்களான /srv அல்லது /var/www ஆகியவற்றை backup செய்வது அவசியம். Caches-ஐத் தவிர்க்கவும், ஏனெனில் அவை அளவில் பெரியவை, தினமும் மாறக்கூடியவை மற்றும் அவை தானாகவே மீண்டும் உருவாகக்கூடியவை:

sudo restic -r sftp:restic@10.0.0.12:/srv/restic/web1 --password-file /root/.restic-password backup /etc /home /srv --exclude '/home/*/.cache'

Files:        4181 new,     0 changed,     0 unmodified
Added to the repository: 731.204 MiB (312.418 MiB stored)
snapshot 5b8a3f2c saved

முதல்முறை இயக்கும்போது அனைத்து தரவுகளும் upload செய்யப்படுவதால், இதற்கு சிறிது நேரம் எடுக்கும். அதே கட்டளையை மீண்டும் இயக்கினால், சில நொடிகளில் முடிந்துவிடும். சில கோப்புகள் மாறியுள்ளன மற்றும் சில MiB தரவு சேர்க்கப்பட்டுள்ளது என்ற தகவலை அது காட்டும், ஏனெனில் deduplication மூலம் புதிய chunks மட்டுமே upload செய்யப்படுகின்றன. உங்களிடம் உள்ளவற்றை பட்டியலிட:

sudo restic -r sftp:restic@10.0.0.12:/srv/restic/web1 --password-file /root/.restic-password snapshots

ஒவ்வொரு snapshot-ம் ஒரு ID, நேரம் மற்றும் அதில் உள்ள பாதைகளைக் காட்டும். அந்த ID-களைக் கொண்டே நீங்கள் தரவுகளை restore செய்ய முடியும்.

systemd timer மூலம் இரவு நேர செயல்பாடுகள்

ஒவ்வொரு கட்டளையிலும் repository முகவரியை உள்ளிடுவது சலிப்பைத் தரும், மேலும் கைமுறையாகச் செய்யும் backup ஒரு மாதத்திற்குள் நின்றுவிடும். இந்த இரண்டு சிக்கல்களுக்கும் ஒரு script மற்றும் ஒரு timer தீர்வாகும். இந்த script, restic வாசிக்கும் இரண்டு environment variables-ஐயும் RESTIC_REPOSITORY மற்றும் RESTIC_PASSWORD_FILE மூலம் அமைக்கிறது, எனவே அதற்குள் உள்ள ஒவ்வொரு கட்டளையும் சுருக்கமாக இருக்கும்:

sudo nano /usr/local/bin/restic-backup.sh

#!/usr/bin/env bash
set -euo pipefail
export RESTIC_REPOSITORY='sftp:restic@10.0.0.12:/srv/restic/web1'
export RESTIC_PASSWORD_FILE=/root/.restic-password

restic backup /etc /home /srv --exclude '/home/*/.cache'
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
restic check

sudo chmod 700 /usr/local/bin/restic-backup.sh

forget மற்றும் check வரிகள் அடுத்த இரண்டு பிரிவுகளில் விளக்கப்பட்டுள்ளன. இப்போது கால அட்டவணை: script-ஐ இயக்கும் ஒரு oneshot service மற்றும் அதை ஒவ்வொரு நாள் இரவு 03:00 மணிக்கு இயக்கும் ஒரு timer. இங்கே cron வரியை விட timer சிறந்தது, ஏனெனில் இது logs-ஐ journal-க்கு அனுப்புகிறது, மேலும் server downtime-க்கு பிறகு மீண்டும் இயங்கும்போது Persistent=true விடுபட்ட backup-ஐ உடனடியாகச் செய்யும்.

# /etc/systemd/system/restic-backup.service
[Unit]
Description=Nightly restic backup
Wants=network-online.target
After=network-online.target

[Service]
Type=oneshot
ExecStart=/usr/local/bin/restic-backup.sh

# /etc/systemd/system/restic-backup.timer
[Unit]
Description=Run the nightly restic backup

[Timer]
OnCalendar=*-*-* 03:00:00
RandomizedDelaySec=15m
Persistent=true

[Install]
WantedBy=timers.target

Timer-ஐ enable செய்யவும், பின்னர் service-ஐ ஒருமுறை கைமுறையாக இயக்கி அது செயல்படுவதைக் கவனிக்கவும்:

sudo systemctl daemon-reload
sudo systemctl enable --now restic-backup.timer
sudo systemctl start restic-backup.service
sudo journalctl -u restic-backup.service -f

systemctl list-timers அடுத்த இயக்கம் எப்போது நடக்கும் என்பதைக் காட்டும். இந்த இரண்டு unit files-ஐயும் தட்டச்சு செய்வதற்குப் பதிலாக நீங்களே உருவாக்கலாம்:

இந்த இரண்டு கோப்புகளுக்குப் பின்னால் உள்ள முழுமையான அமைப்பு, calendar syntax மற்றும் ஒரு service-ல் பயன்படுத்தக்கூடிய hardening directives பற்றிய விவரங்கள் VPS-ல் systemd service ஆக ஒரு நிரலை இயக்குதல் பகுதியில் உள்ளன.

தரவு மீட்பு (restore) செய்யப்படும் வரை backup என்பது வெறும் வதந்தியே

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

முதலில், restic check, இதை script ஒவ்வொரு இரவும் இயக்குகிறது. இது repository அமைப்பு மற்றும் index-ஐச் சரிபார்க்கிறது. இதனால், backup host-ல் ஏற்படும் மறைமுகமான தரவுச் சிதைவு (silent corruption), மீட்பு நாளில் தெரியாமல், அடுத்த இரவே கண்டறியப்படும். மாதத்திற்கு ஒருமுறை, ஆழமான சோதனையை இயக்கவும். இது உண்மையான தரவுகளில் பத்தில் ஒரு பகுதியைத் தற்செயலாகத் தேர்ந்தெடுத்து, பதிவிறக்கம் செய்து, cryptographic முறையில் சரிபார்க்கும்:

sudo -i
export RESTIC_REPOSITORY='sftp:restic@10.0.0.12:/srv/restic/web1'
export RESTIC_PASSWORD_FILE=/root/.restic-password
restic check --read-data-subset=10%

ஒவ்வொரு முறையும் வெவ்வேறு தரவுத் தொகுதிகள் தேர்ந்தெடுக்கப்படுவதால், முழுமையாகப் பதிவிறக்கம் செய்யாமலேயே, மாதந்தோறும் repository முழுவதையும் படிப்படியாகச் சரிபார்க்க முடியும்.

இரண்டாவதாக, மீட்புப் பயிற்சி (restore drill). மேலே உள்ள root shell-லிலேயே இருந்து, சமீபத்திய snapshot-லிருந்து ஒரு கோப்பகத்தை (directory) ஒரு தற்காலிக இடத்திற்கு மீட்டு, அதை நேரடி கோப்புகளுடன் ஒப்பிட்டுப் பார்க்கவும்:

restic restore latest --target /srv/restore-drill --include /etc/ssh
diff -r /etc/ssh /srv/restore-drill/etc/ssh

diff எதையும் அச்சிடவில்லை என்றால், ஒவ்வொரு byte-ம் சரியாக மீட்கப்பட்டுள்ளது என்று அர்த்தம். இது மட்டுமே உண்மையான ஆதாரமாகும். அதன் பிறகு /srv/restore-drill-ஐ நீக்கிவிடவும். இந்தப் பயிற்சியை மாதந்தோறும் செய்யவும். ஆண்டுக்கு ஒன்று அல்லது இரண்டு முறை முழுமையான சோதனையைச் செய்யவும்: சமீபத்திய snapshot முழுவதையும் ஒரு தற்காலிக VPS-ல் மீட்டு, உங்கள் application அதிலிருந்து சரியாகத் தொடங்குகிறதா என்று சரிபார்க்கவும். நெருக்கடியான சூழலில் இது உங்களுக்குத் தேவைப்படும்போது, நீங்கள் ஏற்கனவே பழகிய ஒரு வழக்கமான செயலாக இது இருக்க வேண்டும்.

Retention: forget மற்றும் prune

ஒரு கொள்கை (policy) இல்லையென்றால், snapshots நிரந்தரமாகச் சேர்ந்து கொண்டே இருக்கும், repository-ன் அளவும் வளர்ந்து கொண்டே இருக்கும். ஸ்கிரிப்ட்டின் forget வரி ஒவ்வொரு இரவும் ஒரு கொள்கையைச் செயல்படுத்துகிறது: --keep-daily 7 கடந்த ஏழு நாட்களுக்கு, ஒரு நாளைக்கு ஒரு snapshot வீதம் வைத்திருக்கும்; --keep-weekly 4 நான்கு வாரங்களுக்கு, வாரத்திற்கு ஒரு snapshot வீதம் வைத்திருக்கும்; --keep-monthly 6 ஆறு மாதங்களுக்கு, மாதத்திற்கு ஒரு snapshot வீதம் வைத்திருக்கும். எந்த விதியாலும் பாதுகாக்கப்படாத அனைத்தும் forget செய்யப்படும்.

forget கட்டளை மட்டும் snapshot பதிவுகளை நீக்கும்; தரவுத் துண்டுகள் (data chunks) ஏதேனும் ஒன்று அவற்றை நீக்கும் வரை repository-லேயே இருக்கும். அதைத்தான் --prune செய்கிறது: எந்த snapshot-உம் குறிக்காத தரவுத் துண்டுகளை இது கண்டறிந்து நீக்கும், அப்போதுதான் வட்டு இடம் (disk space) உண்மையில் விடுவிக்கப்படும். Prune என்பது repository-ல் உண்மையான வேலையைச் செய்வதால், பெரிய repository-களில் சிலர் forget-ஐ இரவுதோறும், --prune-ஐ வாரந்தோறும் இயக்குவார்கள்; வழக்கமான VPS அளவுகளில், இரவுதோறும் இயக்குவது போதுமானது.

தரவுத்தளங்கள்: முதலில் dump செய்யவும், பின் காப்புப்பிரதி எடுக்கவும்

Restic கோப்புகளை வாசிக்கும்போதே நகலெடுக்கிறது, ஆனால் தரவுத்தளம் தொடர்ந்து தனது கோப்புகளில் எழுதிக்கொண்டே இருக்கும். எழுதும் செயல்பாட்டின் நடுவில் எடுக்கப்படும் நேரடித் தரவுத்தளக் கோப்பு சிதைந்த நிலையில் மீட்கப்படும், ஏனெனில் அந்த நகல் எழுதும் செயல்பாட்டிற்கு முன்னும் பின்னும் உள்ள பக்கங்களைக் கலந்துவிடும். இதற்குத் தீர்வு இதுதான்: தரவுத்தள இயந்திரத்தைக் கொண்டு கோப்பாக ஒரு சீரான ஏற்றுமதியை (export) உருவாக்க வேண்டும், பின்னர் அந்த கோப்பை restic மூலம் காப்புப்பிரதி எடுக்க வேண்டும்.

PostgreSQL-க்கு, restic-backup.sh-ன் தொடக்கத்தில், restic backup கட்டளைக்கு முன்னால் ஒரு dump வரியைச் சேர்க்கவும், மேலும் அந்த dump கோப்பகத்தை காப்புப்பிரதி பாதைகளில் சேர்க்கவும்:

mkdir -p /var/backups/db
sudo -u postgres pg_dump myapp | gzip > /var/backups/db/myapp.sql.gz

MariaDB மற்றும் MySQL-க்கு mysqldump அதே பணியைச் செய்கிறது. முழுமையான செயல்பாட்டிற்கான உதாரணத்திற்கு, Nextcloud காப்புப்பிரதி பகுதி maintenance mode-ஐ இயக்கி, Postgres-ஐ dump செய்து, கோப்புகளை ஒரு சீரான தொகுப்பாக நகலெடுக்கிறது; இதுவே ஒவ்வொரு இரவும் restic சர்வரிலிருந்து வெளியே எடுத்துச் செல்ல வேண்டிய சரியான தொகுப்பாகும். SQLite-க்கும் இதே தர்க்கம்தான், ஆனால் சிறிய மாற்றத்துடன்: Vaultwarden வழிகாட்டி db.sqlite3-ன் cold copy-ஐ எடுக்க சில நொடிகள் container-ஐ நிறுத்துகிறது, அந்த ஆவணமே restic மூலம் சர்வரிலிருந்து அனுப்பப்படுகிறது.

FAQ

restic backups குறியாக்கம் (encrypted) செய்யப்படுமா?

ஆம், எப்போதும். ஒவ்வொரு restic repository-யும் AES-256 மூலம் குறியாக்கம் செய்யப்படுகிறது. இதில் குறியாக்கம் செய்யப்படாத முறை (unencrypted mode) கிடையாது. ஒவ்வொரு கட்டளைக்கும் (command) repository கடவுச்சொல் தேவை. repository-ஐச் சேமிக்கும் இயந்திரம் அல்லது சேவை வழங்குநர் குறியாக்கம் செய்யப்பட்ட தரவுகளை மட்டுமே வைத்திருப்பார்கள். எனவே, backup host பாதிக்கப்பட்டாலும் உங்கள் கோப்புகள் வெளிப்படாது. இதற்கு ஈடாக, கடவுச்சொல் இல்லாமல் யாராலும் தரவை மீட்க முடியாது. எனவே, கடவுச்சொல்லின் நகலை server-க்கு வெளியே பாதுகாப்பாக வைக்கவும்.

restic incremental backups செய்கிறதா?

ஒவ்வொரு restic snapshot-உம் முழுமையான backup போலச் செயல்படும், ஆனால் சேமிப்பகத் தேவை (storage cost) குறைவாகவே இருக்கும். Restic கோப்புகளைச் சிறு துண்டுகளாகப் பிரித்து, repository-ல் ஏற்கனவே இல்லாத துண்டுகளை மட்டுமே பதிவேற்றும். எனவே, தினசரி இயங்கும் backup, அந்த நாளில் மாறிய தரவுகளை மட்டுமே மாற்றும். பாரம்பரிய incremental முறைகளைப் போலன்றி, இதில் தரவுகளை மீண்டும் உருவாக்கச் சங்கிலித் தொடர் (chain) தேவையில்லை. எந்தவொரு snapshot-ஐயும் நேரடியாக மீட்கலாம்; பழைய snapshot-ஐ நீக்குவது புதிய snapshot-ஐப் பாதிக்காது.

restic backup-லிருந்து கோப்புகளை எப்படி மீட்பது?

snapshot ID-ஐக் கண்டறிய restic snapshots கட்டளையை இயக்கவும். பின் அதை மீட்க restic restore <id> --target /some/empty/dir கட்டளையைப் பயன்படுத்தவும். குறிப்பிட்ட பகுதியை மட்டும் மீட்க --include /path-ஐச் சேர்க்கவும். ID-க்கு பதிலாக latest-ஐயும் பயன்படுத்தலாம். Restic அசல் கோப்பு முறைமையை (directory structure) இலக்கு கோப்புறையில் உருவாக்கும். உதாரணமாக, /etc/ssh-ஐ மீட்டெடுத்தால் அது /some/empty/dir/etc/ssh-ல் அமையும். தேவைப்படும் முன் இதைப் பயிற்சி செய்யவும், ஏனெனில் சோதிக்கப்படாத backup என்பது வெறும் உறுதிமொழி மட்டுமே.

restic backup-ஐ எவ்வளவு அடிக்கடி இயக்க வேண்டும்?

ஒரு server-க்கு தினசரி (nightly) இயக்குவது சரியான குறைந்தபட்ச அளவாகும். deduplication வசதி இருப்பதால் இது செலவு குறைந்தது; கடைசி backup-க்குப் பிறகு மாறிய துண்டுகளை மட்டுமே ஒவ்வொரு முறையும் பதிவேற்றும். வேகமாக மாறும் தரவுகள் அல்லது ஒரு நாள் இழப்பு கூட பாதிப்பை ஏற்படுத்தும் தரவுகளுக்கு, சில மணிநேரங்களுக்கு ஒருமுறை இதே timer முறையில் backup எடுக்கலாம். அடிக்கடி இயக்குவது எளிதான பகுதி; அதனுடன் restic check கட்டளையைத் தவறாமல் இயக்கவும், மாதத்திற்கு ஒருமுறை restore செய்து சோதிக்கவும். ஏனெனில், சரிபார்ப்பு இல்லாத கால அட்டவணை ஒரு போலியான பாதுகாப்பையே தரும்.

restic repository கடவுச்சொல்லை மறந்துவிட்டால் என்ன ஆகும்?

backup-களை மீட்க முடியாது. Restic-ன் குறியாக்கத்தில் பின்வாசல் (back door) அல்லது கடவுச்சொல் மாற்றும் வசதி கிடையாது. எனவே, backup-களைப் போலவே கடவுச்சொல்லும் மிக முக்கியமானது. உங்கள் password manager-ல் ஒரு நகலைச் சேமிக்கவும், backup எடுக்கப்படும் server-ஐத் தவிர வேறு பாதுகாப்பான இடத்திலும் வைக்கவும். உங்களுக்கு இன்னும் அணுகல் இருக்கும்போதே, restic key add கட்டளையைப் பயன்படுத்தி அதே repository-க்கு இரண்டாவது கடவுச்சொல்லைச் சேர்த்துக்கொள்ளலாம். இது உங்களுக்கு ஒரு மாற்று வழியைத் தரும்.