VPS-ஐ off-site backup target-ஆக பயன்படுத்துவது எப்படி?

Off-site backup target என்பது உண்மையில் என்ன

Off-site backup target என்பது உங்கள் தரவுகளின் நகலை வைத்திருக்கும் இரண்டாவது இயந்திரம் ஆகும். இது முதன்மை சர்வரிலிருந்து தனித்து இயங்கக்கூடியது. பெரும்பாலான பயனர்களுக்கு, மற்றொரு provider-ல் உள்ள ஒரு VPS-ஐப் பயன்படுத்துவதே மலிவான வழியாகும். இதில் மூன்று நடைமுறை வழிகள் உள்ளன: VPS-ல் இயங்கும் Proxmox Backup Server, SSH அல்லது S3 வழியாக அணுகப்படும் restic repository, அல்லது backup host-ஆல் இழுக்கப்படும் (pull) rsync mirror. நீங்கள் எதை மீட்டெடுக்க வேண்டும் மற்றும் எவ்வளவு விரைவாகத் தேவை என்பதைப் பொறுத்தே இதில் எது சிறந்தது என்பது அமையும். நகலை யார் நீக்கலாம் என்ற அதிகாரம் மீதமுள்ள முடிவுகளைத் தீர்மானிக்கிறது.

Off-site என்பது ஒரு மாறுபட்ட failure domain-ஐக் குறிக்கிறது. அதாவது, இது ஒரு மாறுபட்ட provider-ஆக இருக்க வேண்டும். மேலும், உங்கள் சர்வரை இயக்கும் கணக்கிலிருந்து முற்றிலும் மாறுபட்ட, பகிரப்படாத login விவரங்களைக் கொண்ட கணக்காக இருக்க வேண்டும். ஒரே provider-ன் மற்றொரு region-ல் உள்ள இரண்டாவது சர்வர், ஒரு கட்டிடத்தில் ஏற்படும் தீ விபத்தைத் தாங்கும். ஆனால், அது compromised control panel login-ஐத் தாங்காது; ஏனெனில் ஒரே கணக்கு இரண்டு நகல்களையும் கட்டுப்படுத்துகிறது.

உங்கள் provider வழங்கும் snapshot என்பது அந்த இரண்டாவது நகல் அல்ல. அது அதே panel password-க்கு பின்னால் இருப்பதால், அந்த password-ஐப் பெறுபவர் சர்வரையும் அதன் snapshot-களையும் ஒரே அமர்வில் நீக்கிவிட முடியும். மேலும், snapshot சேவைகள் சாதாரண disk-ஐ விட அதிக விலையில், gigabyte-க்கு மாதந்தோறும் கட்டணம் வசூலிக்கின்றன. இதனால் 90 நாட்களுக்கான snapshot-களை வைத்திருப்பது செலவு மிக்கது. VPS snapshots மற்றும் backups-க்கு இடையிலான வேறுபாடு என்பதை நீங்கள் எதை நம்புவதற்கு முன்பும் வாசிப்பது அவசியம்.

உங்களுக்கு எந்த வடிவம் பொருத்தமானது

• Proxmox Backup Server (PBS): இதன் மூலம் Proxmox VE (virtual environment) இலிருந்து முழு virtual machine-ஐயும் restore செய்ய முடியும். இது disk-image மட்டத்தில் backup செய்கிறது, மேலும் இதன் verify பணிகள் target-ல் உள்ள தரவுகளை மீண்டும் வாசித்து சரிபார்க்கும்.
• A restic repository: ஒன்று அல்லது அதற்கு மேற்பட்ட Linux hosts-லிருந்து directory அல்லது database dump-ஐ restore செய்ய இது உதவும். இது client பக்கத்திலேயே தரவுகளை encrypt செய்கிறது; இது SSH, S3 மற்றும் தனது சொந்த REST protocol-ஐ ஆதரிக்கிறது.
• rsync over SSH, pulled by the backup host: target-ல் உள்ள கோப்புகள் சாதாரண கோப்புகளாகவே இருக்க வேண்டும் எனில் இதைப் பயன்படுத்தலாம். இவற்றை ls மற்றும் cat மூலம் வாசிக்க முடியும், இவற்றைத் திரும்பப் பெற எந்த client மென்பொருளும் தேவையில்லை.

உங்களால் முடிவு செய்ய முடியவில்லை எனில், restic-ஐப் பயன்படுத்தவும். இது தரவுகள் இயந்திரத்தை விட்டு வெளியேறும் முன்பே encrypt செய்துவிடும்; target-ல் ஒரு SSH account மற்றும் disk தவிர வேறு எதுவும் தேவையில்லை. VPS-ல் restic backups அமைத்தல் பகுதி client பக்கத்தை விரிவாக விளக்குகிறது, மேலும் நீங்கள் ஏற்கனவே Borg பயன்படுத்துகிறீர்கள் எனில் restic மற்றும் BorgBackup ஒப்பீடு பகுதி உங்களுக்கு உதவும்.

இலக்கின் அளவை நிர்ணயித்தல்: ஒரு மாத சேமிப்பிற்கான செலவு

Deduplication தொழில்நுட்பமே மக்கள் எதிர்பார்ப்பதை விட எண்கள் குறைவாக இருப்பதற்குக் காரணம். restic மற்றும் PBS ஆகிய இரண்டுமே கோப்புகளை மாறுபட்ட அளவுள்ள துண்டுகளாகப் (chunks) பிரித்து, ஒவ்வொரு துண்டையும் hash செய்கின்றன. தனித்துவமான ஒவ்வொரு துண்டும் ஒருமுறை மட்டுமே சேமிக்கப்படும். 500 GB தரவுத்தொகுப்பின் இரண்டாவது backup, கூடுதலாக 500 GB-ஐச் சேர்ப்பதில்லை. அது மாறிய துண்டுகளை மட்டுமே சேர்க்கிறது.

எனவே, repository-ன் அளவு snapshots-ன் எண்ணிக்கையை அல்ல, மாறாக உங்கள் பழமையான snapshot-ன் வயதையே அடிப்படையாகக் கொண்டது. 500 GB தரவு மற்றும் தினமும் 5 GB புதிய தனித்துவமான தரவு இருப்பதாகக் கொள்வோம். அப்போது repository-ல் 500 GB அடிப்படைத் தரவும், கொள்கைப்படி (policy) சேமிக்கப்படும் பழமையான snapshot வரையிலான ஒவ்வொரு நாளுக்கும் சுமார் 5 GB தரவும் இருக்கும்.

[
  {
    "label": "7 daily",
    "repo_size_gb": 535,
    "usd_at_10_per_tb": 5.35
  },
  {
    "label": "7 daily, 4 weekly",
    "repo_size_gb": 640,
    "usd_at_10_per_tb": 6.4
  },
  {
    "label": "7 daily, 4 weekly, 6 monthly",
    "repo_size_gb": "1,400",
    "usd_at_10_per_tb": 14.0
  },
  {
    "label": "7 daily, 4 weekly, 12 monthly",
    "repo_size_gb": "2,325",
    "usd_at_10_per_tb": 23.25
  }
]

டாலர் நெடுவரிசை அந்த repository-ன் விலையை ஒரு TB-க்கு மாதம் 10 US டாலர்கள் என மதிப்பிடுகிறது. இது கணக்கீட்டிற்கான ஒரு உதாரணம் மட்டுமே, எந்தவொரு சேவை வழங்குநரின் விலையும் அல்ல. எனவே, நீங்கள் பரிசீலிக்கும் திட்டத்தின் உண்மையான TB-க்கான விலையை இதில் பிரதியிடவும். ஒரு வார கால dailies சுமார் 535 GB-ஐக் கொண்டிருக்கும். ஒரு முழு ஆண்டு வரலாறு 2,325 GB-ஐக் கொண்டிருக்கும், இது வாராந்திரத் திட்டத்திற்கு $5.35 செலவாகும் நிலையில், மாதத்திற்கு $23.25 செலவாகும். வரலாறு மலிவானது. நீங்கள் அடிப்படை நகலுக்கே (base copy) பணம் செலுத்துகிறீர்கள்.

ஏற்கனவே compressed அல்லது encrypted செய்யப்பட்ட தரவுகளுக்கு deduplication எந்தப் பலனையும் தராது. ஒரு gzipped database dump ஒவ்வொரு முறையும் முழுமையாக மாறுவதால், ஒவ்வொரு dump-ம் புதிய துண்டுகளாகச் சேமிக்கப்பட்டு, repository ஒவ்வொரு இரவும் ஒரு முழு dump அளவுக்கு வளரும். dump-ஐ compress செய்யாமல் எழுதவும், backup கருவியையே அதைச் செய்ய அனுமதிக்கவும். ஏனெனில் restic 0.14 பதிப்பிலிருந்து compressed repositories-ஐ ஆதரிக்கிறது மற்றும் 0.19 பதிப்பில் fastest மற்றும் better zstd முறைகள் சேர்க்கப்பட்டுள்ளன. இதே காரணத்தால் புகைப்படம் மற்றும் வீடியோ கோப்புகள் சரியாக dedupe செய்யப்படுவதில்லை, எனவே அவற்றின் அளவை மேற்கூறிய வரிசைகளைக் கொண்டு கணக்கிடாமல், அவற்றின் உண்மையான வளர்ச்சி விகிதத்தைக் கொண்டு கணக்கிடவும்.

இங்கே நீங்கள் CPU-வை விட idle disk-ஐ வாங்குகிறீர்கள், இதுவே a storage VPS beats a regular VPS என்பதற்கான சரியான சூழலாகும்.

அலைக்கற்றை (bandwidth) மற்றும் மீட்பு நேரம் (restore time) ஏன் திட்டத்தைத் தீர்மானிக்கின்றன

வட்டு (disk) என்பது மலிவான பகுதி. முதல்முறை பதிவேற்றம் (upload) மற்றும் தேவைப்படும்போது தரவை மீட்டெடுத்தல் (restore) ஆகியவையே அதிக செலவு பிடிக்கும் பகுதிகள். 500 GB என்பது 4 டிரில்லியன் பிட்கள் ஆகும். எனவே, முழுமையான தரவை மீட்டெடுக்க எவ்வளவு நேரம் ஆகும் என்பதைக் கணக்கிட, தரவு பரிமாற்ற வேகத்தால் (link speed) இதைப் பிரிக்க வேண்டும்.

[
  {
    "label": "40 Mbit/s home upload",
    "elapsed_h": 27.8
  },
  {
    "label": "100 Mbit/s",
    "elapsed_h": 11.1
  },
  {
    "label": "500 Mbit/s",
    "elapsed_h": 2.2
  },
  {
    "label": "1 Gbit/s VPS port",
    "elapsed_h": 1.1
  }
]

இவை எந்தவிதமான புரோட்டோகால் மேல்நிலைச் செலவும் (protocol overhead) இல்லாத, மிகச் சிறந்த சூழலில் கிடைக்கும் வேகங்கள் ஆகும். 100 Mbit/s வேகத்தில், தரவைத் தொடுவதற்கு முன்பே முழுமையான மீட்டெடுப்பிற்கு 11.1 மணிநேரம் தேவைப்படும். வீட்டிலிருந்து 40 Mbit/s பதிவேற்ற வேகத்தில் இது 27.8 மணிநேரம் எடுக்கும். 1 Gbit/s போர்ட்டில் அதே மீட்டெடுப்பிற்கு 1.1 மணிநேரம் ஆகும். பல சிறிய கோப்புகள் இருக்கும்போது, கணக்கீட்டை விட வேகம் குறைவாக இருக்கும். ஏனெனில், சில நூறு கிலோபைட்டுகளுக்கும் குறைவான கோப்புகளைக் கையாளும்போது, ஒவ்வொரு கோப்பிற்கும் ஏற்படும் கூடுதல் சுமை (per-file overhead) அதிகமாக இருக்கும்.

இதிலிருந்து இரண்டு விஷயங்கள் தெளிவாகின்றன. உங்கள் மீட்பு கால இலக்கு (RTO) - அதாவது நீங்கள் தாங்கக்கூடிய செயலிழப்பு நேரம் - நான்கு மணிநேரம் என்றால், 100 Mbit/s இணைப்பில் 500 GB தரவை மீட்டெடுக்கும்போது அந்த இலக்கை நீங்கள் ஏற்கனவே கடந்துவிட்டீர்கள் என்று அர்த்தம்; இதில் மலிவான வட்டு எந்த உதவியும் செய்யாது. மேலும், பெரும்பாலான VPS திட்டங்கள் வெளிச்செல்லும் தரவுப் பரிமாற்றத்தை (outbound transfer) அளவிடுகின்றன. எனவே, ஒருமுறை முழுமையாக மீட்டெடுக்கும்போது, அந்த பேக்கப் ஹோஸ்டின் மாதாந்திர ஒதுக்கீட்டில் 0.5 TB செலவாகிவிடும். தரவு தேவைப்படுவதற்கு முன்பே, அந்த ஒதுக்கீட்டைச் சரிபார்க்கவும்; அதைத் தாண்டும்போது அந்த நிறுவனம் என்ன நடவடிக்கை எடுக்கும் என்பதையும் உறுதிப்படுத்திக் கொள்ளவும்.

முதல் பேக்கப் என்பது முழு தரவுத்தொகுப்பையும் உள்ளடக்கியது, இதுவே நீங்கள் செய்யும் மிக மெதுவான செயல்பாடாக இருக்கும். இதை வெள்ளிக்கிழமை தொடங்கவும். மூல இணைப்பின் (source's uplink) வேகத்தை முழுமையாக ஆக்கிரமிக்காதவாறு, அதன் வேகத்தைக் கட்டுப்படுத்தவும்: restic-க்கு --limit-upload (KiB/s-ல்) மற்றும் rsync-க்கு --bwlimit ஆகிய கட்டளைகளைப் பயன்படுத்தவும்.

வடிவம் 1: Proxmox Backup Server-ஐ ஒரு தொலைதூர datastore-ஆகப் பயன்படுத்துதல்

மூலமானது Proxmox VE ஆகவும், மீட்டெடுக்கும் அலகு ஒரு virtual machine ஆகவும் இருக்கும்போது PBS பொருத்தமானது. ஒரு VPS-ல் Proxmox ISO-வை boot செய்ய முடியாது என்பதால், Debian-ன் மேல் PBS-ஐ நிறுவவும். ஆகஸ்ட் 2026 நிலவரப்படி, Debian 13 (trixie)-ஐ அடிப்படையாகக் கொண்ட 4.2 பதிப்பு தற்போதைய பதிப்பாகும்.

wget https://enterprise.proxmox.com/debian/proxmox-archive-keyring-trixie.gpg \
  -O /usr/share/keyrings/proxmox-archive-keyring.gpg
sha256sum /usr/share/keyrings/proxmox-archive-keyring.gpg

அந்த checksum-ஐ Proxmox package repositories page-ல் வெளியிடப்பட்டுள்ள மதிப்புடன் ஒப்பிடவும். நீங்கள் சரிபார்த்த key எவ்வளவு நம்பகமானதோ, அவ்வளவுதான் apt repository-யும் நம்பகமானது. பிறகு /etc/apt/sources.list.d/proxmox.sources-ஐ உள்ளிடவும்:

Types: deb
URIs: http://download.proxmox.com/debian/pbs
Suites: trixie
Components: pbs-no-subscription
Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg

sudo apt update && sudo apt install -y proxmox-backup-server
sudo proxmox-backup-manager datastore create offsite /mnt/datastore/offsite

Datastore-க்கு எனத் தனி filesystem அல்லது தனி volume-ஐ ஒதுக்கவும். Datastore முழுமையாக நிரம்பினால் backups நின்றுவிடும்; root filesystem-ஐப் பகிரும் datastore நிரம்பினால், அது முழு server-யையும் செயலிழக்கச் செய்யும்.

அடுத்து, மூலமானது (source) பயன்படுத்தும் account-ஐ உருவாக்கி, அதற்கு password-க்கு பதிலாக ஒரு token-ஐ வழங்கவும்.

sudo proxmox-backup-manager user create backup@pbs
sudo proxmox-backup-manager user generate-token backup@pbs pve1
sudo proxmox-backup-manager acl update /datastore/offsite DatastoreBackup \
  --auth-id 'backup@pbs!pve1'

Token secret ஒருமுறை மட்டுமே திரையில் தோன்றும், அதை மீண்டும் பார்க்க முடியாது, எனவே அது தோன்றும்போது சேமித்துக்கொள்ளவும். Token-ஐப் போலவே அதன் role-ம் முக்கியமானது. DatastoreBackup தனது சொந்த backups-ஐ உருவாக்கவும் மீட்டெடுக்கவும் முடியும், மேலும் இது Datastore.Prune உரிமையைக் கொண்டிருக்கவில்லை, எனவே அந்த token-ஆல் தான் எழுதிய snapshot-ஐ நீக்க முடியாது.

PBS-ல் retention இரண்டு பகுதிகளைக் கொண்டது, இரண்டாவது பகுதியைத்தான் பலரும் கவனிக்கத் தவறுவார்கள். Prune என்பது snapshot-களை நீக்கும். Garbage collection என்பது எஞ்சியிருக்கும் எந்த snapshot-ஆலும் குறிக்கப்படாத chunks-ஐ நீக்கும். Prune செய்த பிறகு அல்ல, garbage collection செய்த பிறகுதான் காலி இடம் (free space) கிடைக்கும்.

proxmox-backup-client prune host/web1 \
  --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --dry-run
sudo proxmox-backup-manager garbage-collection start offsite
sudo proxmox-backup-manager verify offsite

நீக்கப்பட வேண்டிய snapshot-களின் பட்டியல் சரியாகத் தெரிந்தால், --dry-run-ஐ இயக்கவும். Garbage collection இரண்டு நிலைகளில் இயங்குகிறது: முதலில், இன்னும் பயன்பாட்டில் உள்ள ஒவ்வொரு chunk-ன் access time-ஐயும் புதுப்பிக்கும், பிறகு அந்த run தொடங்குவதற்கு 24 மணிநேரம் 5 நிமிடங்களுக்கு முந்தைய access time கொண்ட chunks-ஐ நீக்கும். Backup நடந்து கொண்டிருக்கும்போது, அந்த chunk நீக்கப்படாமல் இருக்கவே இந்த grace period வழங்கப்படுகிறது. Datastore-ல் தினமும் prune-ஐயும், வாரந்தோறும் garbage collection-ஐயும் திட்டமிடவும். மேலும், ஒரு verify job-ஐச் சேர்க்கவும், இதன் மூலம் target தனது சொந்த chunks-ஐ மீண்டும் படித்து, மீட்டெடுக்கும் முன்பே disk-ல் ஏதேனும் சிதைவு (corruption) உள்ளதா என்பதைத் தெரிவிக்கும்.

மூலமானது ஒரு PBS instance-ஆகவே இருந்தால், off-site box-ஆனது push செய்வதற்குப் பதிலாகத் தரவுகளைத் தானாகவே இழுக்க (pull) முடியும்.

sudo proxmox-backup-manager remote create home1 \
  --host pbs.home.example --userid sync@pam --password 'SECRET' \
  --fingerprint '64:d3:ff:3a:50:38:53:5a:9b:f7:50:ab:fe'
sudo proxmox-backup-manager sync-job create home1-offsite \
  --remote home1 --remote-store main --store offsite --schedule 'Wed 02:30'

அந்த sync job-ஐ VPS-ல், இயல்பான pull திசையில் இயக்கவும். VPS ஆனது home datastore-க்குள் சென்று தரவுகளை எடுக்கும், அதாவது home box-ல் off-site நகலை அணுகக்கூடிய எந்தச் சான்றுகளும் (credential) இருக்காது.

வடிவம் 2: SSH அல்லது S3 வழியாக restic repository

Debian மற்றும் Ubuntu ஆகிய இரண்டுமே restic-ஐ package செய்கின்றன, ஆனால் அவை upstream-ஐ விடப் பின்தங்கியே உள்ளன. ஆகஸ்ட் 2026 நிலவரப்படி, 0.19.1 பதிப்பு தற்போதைய பதிப்பாகும். source host-ல் அதிகாரப்பூர்வ binary-ஐ நிறுவவும்.

curl -LO https://github.com/restic/restic/releases/download/v0.19.1/restic_0.19.1_linux_amd64.bz2
bunzip2 restic_0.19.1_linux_amd64.bz2
sudo install -m 755 restic_0.19.1_linux_amd64 /usr/local/bin/restic
restic version

restic version பதிப்பையும் அது உருவாக்கப்பட்ட Go compiler-ஐயும் அச்சிடும். பிற்கால மேம்படுத்தல்களுக்கு sudo restic self-update-ஐப் பயன்படுத்தவும்; இது அதிகாரப்பூர்வ binary-களில் மட்டுமே செயல்படும், apt மூலம் நிறுவப்பட்ட நகல்களில் செயல்படாது.

Backup VPS-ல், வேறு எதற்கும் உரிமையற்ற ஒரு கணக்கை உருவாக்கி, source host-ன் public key-ஐ /home/resticsrv/.ssh/authorized_keys-க்குள் நகலெடுக்கவும்.

sudo adduser --disabled-password --gecos '' resticsrv
sudo install -d -m 700 -o resticsrv -g resticsrv /srv/restic

SFTP வழியாக source-லிருந்து repository-ஐ initialize செய்யவும்.

sudo sh -c 'umask 077; head -c 32 /dev/urandom | base64 > /root/.restic-password'
export RESTIC_REPOSITORY='sftp:resticsrv@backup.example.net:/srv/restic/web1'
export RESTIC_PASSWORD_FILE=/root/.restic-password
restic init
restic backup /etc /srv /var/backups --exclude-caches

அந்த password-ஐ இந்த server அல்லது backup target அல்லாத வேறொரு இடத்தில் சேமிக்கவும். அதைத் தொலைத்துவிட்டால், repository-ஐ வாசிக்க முடியாது; மீட்பதற்கான வழியும் இல்லை. இதுவே client-side encryption-ன் நிபந்தனை.

Retention என்பது ஒரே கட்டளை, அதன் இரண்டாம் பகுதிதான் disk-ஐ விடுவிக்கும் பணியைச் செய்கிறது.

restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
restic check --read-data-subset=10%

forget snapshots-ஐ நீக்கும். prune அந்த snapshots-ஆல் மட்டுமே குறிக்கப்பட்ட pack files-ஐ நீக்கும், மேலும் ஏதேனும் நீக்கப்பட்டால் --prune அதைத் தானாகவே இயக்கும். இது இல்லையெனில் repository-ன் அளவு குறையாது. restic check repository கட்டமைப்பைச் சரிபார்க்கும், மேலும் --read-data-subset=10% pack files-ல் பத்தில் ஒரு பங்கை மீண்டும் வாசித்து hash செய்யும்; இது அனைத்தையும் வாசிக்கும் செலவின்றி target-ல் உள்ள சிதைவுகளைக் கண்டறியும். மற்றொரு வடிவமான --read-data-subset=1/10, நிலையான பத்தில் ஒரு பங்கைச் சரிபார்க்கும், எனவே ஒவ்வொரு வாரமும் அந்த முதல் எண்ணை அதிகரிப்பதன் மூலம் பத்து வாரங்களில் முழு repository-யும் சரிபார்க்கப்படும்.

ஒரு run பாதியில் நிறுத்தப்பட்டால், அடுத்தது repository is already locked exclusively by PID பிழையுடன் நிற்கும். எந்த backup-ம் இயங்கவில்லை என்பதை உறுதிசெய்துவிட்டு, restic unlock மூலம் அதை நீக்கவும்.

Object storage-க்கு repository string s3:https://s3.example.net/web1 என மாறும், அதற்கான credentials AWS_ACCESS_KEY_ID மற்றும் AWS_SECRET_ACCESS_KEY-ல் இருக்கும். மற்ற அனைத்தும் ஒரே மாதிரியானவை, இதைப் பயன்படுத்திதான் restic அதே VPS-ல் இயங்கும் self-hosted MinIO object store-உடன் தொடர்பு கொள்கிறது.

வடிவம் 3: SSH வழியாக rsync மற்றும் pull-only key

இந்த அமைப்பின் பாதுகாப்பு அம்சம் அதன் திசையமைப்பில் உள்ளது. Backup VPS, source-ஐத் தொடர்புகொண்டு தரவுகளைப் படிக்கிறது. Source-ல் எந்தவொரு key-யும் இல்லை, backup host-க்குச் செல்லும் வழித்தடமும் இல்லை. எனவே, source சமரசம் (compromise) செய்யப்பட்டாலும், அது backup-ஐ அணுக முடியாது.

Backup VPS-ல் ஒரு key pair-ஐ உருவாக்கி, அதன் public பகுதியை source-ல் ஒரு forced command உடன் நிறுவவும்.

command="rrsync -ro /srv",restrict ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAA offsite-pull

rrsync, Debian 13 மற்றும் Ubuntu 24.04-ல் /usr/bin/rrsync என்ற பாதையில் rsync தொகுப்புடன் வருகிறது. -ro வாசிப்பு அனுமதியை மட்டுமே வழங்குகிறது மற்றும் -no-del-ஐ உள்ளடக்கியது. எனவே, இந்த key-யால் source-ல் எதையும் எழுதவோ அல்லது நீக்கவோ முடியாது. restrict, இங்கே தேவையில்லாத SSH அம்சங்களான port forwarding மற்றும் pty ஆகியவற்றை முடக்குகிறது. இதனால், இந்த key-யைப் பயன்படுத்தி interactive login செய்ய முடியாது. பாதைகள் நீங்கள் குறிப்பிட்ட directory-க்கு உட்பட்டவை; எனவே remote path / என்பது source-ல் /srv-ஐக் குறிக்கும்.

இந்த pull முறை hardlinks மூலம் வரலாற்றைப் பராமரிக்கிறது. புதிய tree-ல் மாறாத கோப்புகள் முந்தைய tree-ன் hardlinks-ஆக இருக்கும். இதனால், கோப்பின் நகலுக்குப் பதிலாக ஒரு directory entry மட்டுமே செலவாகும்.

DEST=/srv/mirror/web1
TODAY=$(date +%F)
LAST=$(ls -1d "$DEST"/2* 2>/dev/null | tail -1)
LINK=""
if [ -n "$LAST" ]; then LINK="--link-dest=$LAST"; fi
rsync -aH --numeric-ids $LINK -e 'ssh -i /root/.ssh/pull_ed25519' \
  pull@web1.example.net:/ "$DEST/.$TODAY.partial/"
mv "$DEST/.$TODAY.partial" "$DEST/$TODAY"

இறுதியில் செய்யப்படும் பெயர் மாற்றம் (rename), காலவரிசைப்படுத்தப்பட்ட directory-ஐ நம்பகமானதாக மாற்றுகிறது. rsync வெற்றிகரமாக (exit 0) முடிந்த பிறகுதான் பெயர் மாற்றப்படும். எனவே, பாதியில் நின்ற பரிமாற்றம் ஒரு முழுமையான snapshot போலத் தெரியாது. பழைய tree-களை ஒரே வரியில் நீக்கி, முப்பது நாட்களுக்கான தரவுகளை மட்டும் வைத்திருக்கலாம்.

ls -1d /srv/mirror/web1/2* | sort | head -n -30 | xargs -r rm -rf

இந்த வடிவத்தின் குறைபாடுகளைப் புரிந்துகொள்வது அவசியம். Hardlinks முழுமையான கோப்புகளை மட்டுமே deduplicate செய்யும். 4 GB disk image-ல் ஒரு byte மாறினாலும், முழு 4 GB-யும் நகலெடுக்கப்படும். ஆனால் restic மற்றும் PBS போன்ற கருவிகள் மாற்றப்பட்ட பகுதிகளை (chunks) மட்டுமே சேமிக்கும். மேலும், target-ல் உங்கள் கோப்புகள் plaintext வடிவில் இருக்கும். எனவே, backup VPS-ல் root அணுகல் உள்ள எவராலும் அவற்றைப் படிக்க முடியும்.

Client-side encryption, இதனால் target-க்கு plaintext தெரியாது

Backup VPS-ஐ நீங்கள் முழுமையாகக் கட்டுப்படுத்தாத ஒரு machine-ஆகக் கருதவும். அதற்கு ஒரு provider உண்டு; அந்த provider-க்கு ஊழியர்கள் உள்ளனர், மேலும் பழுதடைந்த disks அந்த இடத்தை விட்டு வெளியேறக்கூடும்.

restic தரவுகளை அனுப்பும் முன்பே source-ல் உள்ள ஒவ்வொரு chunk-ஐயும் encrypt செய்கிறது; எனவே repository என்பது ciphertext மற்றும் அதன் அளவு, நேரம் குறித்த metadata மட்டுமே. PBS-ல் encryption என்பது விருப்பத்தேர்வு: ஒரு key-ஐ உருவாக்கி, ஒவ்வொரு backup-ன் போதும் அதை வழங்க வேண்டும்.

proxmox-backup-client key create /root/pbs-encryption.key
proxmox-backup-client backup root.pxar:/ --keyfile /root/pbs-encryption.key
proxmox-backup-client key paperkey --output-format text > qrkey.txt

Paper key-ஐ print செய்து, பாதுகாப்பான இடத்தில் வைக்கவும். Proxmox ஆவணங்கள் இதன் தீவிரத்தை நேரடியாகக் கூறுகின்றன: key இல்லையென்றால், backup செய்யப்பட்ட கோப்புகளை அணுக முடியாது. Key-ஐ backup target-ல் வைக்க வேண்டாம்; ஏனெனில் ciphertext-க்கு அருகிலேயே key-ஐ வைத்திருப்பது எந்தப் பாதுகாப்பையும் தராது.

rsync mirrors-க்கு இதற்கு இணையான வசதி இல்லை. கோப்புகள் அப்படியே கோப்புகளாகவே சேமிக்கப்படும். தரவுகள் முக்கியமானவை என்றால், target-ஆல் அவற்றைப் படிக்க முடியும் என்பதை ஏற்றுக்கொள்ளுங்கள், அல்லது மற்ற இரண்டு முறைகளில் ஒன்றைப் பயன்படுத்தவும்.

பாதிக்கப்பட்ட source-லிருந்து அதன் சொந்த backups-ஐ அழிப்பதைத் தடுத்தல்

ஒரு attacker source-ஐக் கைப்பற்றிய பிறகு, அடுத்ததாக backups-ஐத் தேடுவார். அவற்றை upload செய்யும் credential அந்த machine-லேயே இருக்கும். அந்த credential-க்கு அழிக்கும் அதிகாரம் இருந்தால், அதை அவர்கள் பயன்படுத்துவார்கள்.

PBS இதற்கு roles மூலம் பதிலளிக்கிறது. DatastoreBackup மட்டுமே கொண்ட ஒரு token புதிய snapshots-ஐ எழுதவும், தனது சொந்த snapshots-ஐ restore செய்யவும் முடியும். ஆனால், ஒரு snapshot-ஐ நீக்குவதற்குத் தனிப்பட்ட Datastore.Prune அதிகாரம் தேவை என்பதால், அந்த token-ஆல் நீக்க முடியாது. Retention-ஐ PBS பக்கத்திலிருந்து இயக்கினால், எதையும் நீக்கும் அதிகாரம் கொண்ட credential source-ல் இருக்காது.

SFTP வழியாக இயங்கும் restic-ல் இத்தகைய பிரிவினை இல்லை. ஏனெனில், repository-க்கு எழுதும் SSH key-ஆல் அதிலிருந்து நீக்கவும் முடியும். இதற்கு REST backend-ஐப் பயன்படுத்துவதே தீர்வு. Backup VPS-ல் --append-only உடன் rest-server-ஐ இயக்கவும். இது புதிய backups-ஐ உருவாக்க அனுமதிக்கும், ஆனால் ஏற்கனவே உள்ளவற்றை நீக்கவோ மாற்றவோ அனுமதிக்காது. client-ஐ rest:https://backup.example.net:8000/web1-க்குச் சுட்டிக்காட்டி, RESTIC_REST_USERNAME மற்றும் RESTIC_REST_PASSWORD-ஐப் பயன்படுத்தவும். அப்போது source-லிருந்து வரும் restic forget --prune தோல்வியடையும்; இதுவே எதிர்பார்க்கப்படும் முடிவு. எனவே, retention-ஐ மற்றொரு machine-லிருந்து அதன் சொந்த credential மூலம் இயக்க வேண்டும். Append-only repositories-ல் எண்ணிக்கையை அடிப்படையாகக் கொண்ட கொள்கைகளுக்குப் பதிலாக --keep-within-ஐப் பயன்படுத்த restic கையேடு பரிந்துரைக்கிறது. இல்லையெனில், ஒரு attacker குப்பை snapshots-ஐக் கொண்டு repository-ஐ நிரப்பி, உங்கள் உண்மையான snapshots-ஐ --keep-last காலக்கெடுவிலிருந்து வெளியேற்றிவிடுவார்.

rsync இந்தச் சிக்கலை அமைப்புரீதியாகத் தீர்க்கிறது. இது தரவை இழுப்பதன் (pulling) மூலம் செயல்படுவதால், target-க்கான எந்த credential-ம் source-ல் இருப்பதில்லை.

இந்த மூன்று முறைகளுக்கும் ஒரு பொதுவான விதி உள்ளது: backups-ஐ நீக்கும் அதிகாரம் கொண்ட credential, backup செய்யப்படும் machine-ல் இருக்கக்கூடாது.

மீட்புப் பயிற்சியை காலண்டரில் குறித்துக்கொள்ளுங்கள்

நீங்கள் ஒருபோதும் மீட்டெடுக்காத ஒரு காப்புப்பிரதி (backup) என்பது வெறும் அனுமானம் மட்டுமே. ஒவ்வொரு காலாண்டிலும் ஒரு மணிநேரத்தை ஒதுக்கி அதைச் சோதித்துப் பாருங்கள்.

restic snapshots
restic restore latest --target /var/tmp/restore-test --include /etc/nginx
diff -r /etc/nginx /var/tmp/restore-test/etc/nginx

diff -r எதையும் அச்சிடவில்லை என்றால், மீட்டெடுக்கப்பட்ட கோப்பு முறைமை (tree) நேரலையில் உள்ளவற்றுடன் ஒத்துப்போகிறது என்று அர்த்தம். PBS-ல் இதே பயிற்சி proxmox-backup-client restore host/web1/2026-08-13T02:30:00Z root.pxar /var/tmp/restore-test/ ஆகும், அதனுடன் இலக்கு சேமிப்பகத்தில் உள்ள பகுதிகளை மீண்டும் வாசித்து, checksum தோல்விகளைப் புகாரளிக்கும் ஒரு திட்டமிடப்பட்ட சரிபார்ப்புப் பணியும் (verify job) உள்ளது.

இந்த மீட்புப் பயிற்சி, தரவுகள் (bytes) சிதையாமல் இருப்பதை மட்டும் நிரூபித்தால் போதாது.

• மூலத்திலிருந்து (source) மீட்டெடுக்காமல், மூன்றாவது கணினியிலிருந்து மீட்டெடுங்கள். ஏனெனில், மூலமானது அழிந்துவிட்டதாகவே நீங்கள் கருதுகிறீர்கள். அதாவது, repository password அல்லது PBS key ஆகியவை மூலக் கணினி இல்லாமலேயே அணுகக்கூடியதாக இருக்க வேண்டும்.
• மீட்புப் பணிக்கு ஆகும் நேரத்தைக் குறித்து வைத்துக்கொண்டு, நீங்கள் நிர்ணயித்த RTO-வுடன் ஒப்பிட்டுப் பாருங்கள். மேலே உள்ள வரைபடம் பரிமாற்றத்திற்கான குறைந்தபட்ச நேரத்தைக் காட்டுகிறது. உண்மையான நேரத்தில், தரவுகளை decrypt செய்தல், வட்டில் எழுதுதல் மற்றும் தேவையான snapshot-ஐத் தேர்ந்தெடுக்கும் நேரம் ஆகியவையும் அடங்கும்.
• ஒரு database dump போன்ற, நிலைத்தன்மை (state) கொண்ட தரவை மீட்டெடுத்து, அதை ஒரு தற்காலிக instance-ல் ஏற்றிச் சோதிக்கவும். ஒரு tar கோப்பு பிரித்தெடுக்கப்படுவது மட்டுமே, அந்த application இயங்கும் என்பதற்குச் சான்றாகாது.

நீங்கள் ஒருமுறை கூட மீட்டெடுக்காத வரை, உலகின் மலிவான வட்டு கூட எந்தப் பயனும் அற்றது.

FAQ

எனது VPS வழங்குநரிடம் உள்ள snapshot ஒரு off-site backup-ஆ?

இல்லை. ஒரு வழங்குநரின் snapshot அதே கணக்கிலும், அதே panel login-இலும், அதே invoice-இலும் தான் இருக்கும். அந்த login-ஐப் பெறுபவர், server-ஐயும் அதன் அனைத்து snapshot-களையும் ஒரே நேரத்தில் நீக்கிவிட முடியும். ஆபத்தான upgrade-க்கு முன் விரைவாக rollback செய்ய snapshot உதவும், ஆனால் அது ஒரு மாற்று இடம் (second location) அல்ல. ஒரு off-site நகல் என்பது வேறொரு கணக்கிலும், முடிந்தால் வேறொரு வழங்குநரிடமும் இருக்க வேண்டும். அந்த நகலை அணுகும் credentials, மூல இயந்திரத்திடம் (source machine) இருக்கக்கூடாது.

ஒரு மாத கால backup-களைச் சேமிக்க எவ்வளவு disk இடம் தேவை?

snapshot-களின் எண்ணிக்கையை விட, நீங்கள் சேமிக்கும் பழமையான snapshot-ன் வயதைக் கொண்டு அளவிடவும். deduplicating கருவி ஒவ்வொரு தனித்துவமான chunk-ஐயும் ஒருமுறை மட்டுமே சேமிக்கும். எனவே, repository-ன் அளவு என்பது மூலத் தரவின் அளவுடன், தினசரி மாறும் புதிய தரவை நீங்கள் சேமிக்கும் நாட்களால் பெருக்கினால் கிடைக்கும் அளவாகும். 500 GB தரவில் தினமும் 5 GB மாறினால், ஒரு வார கால தினசரி backup-களுக்கு சுமார் 535 GB தேவைப்படும், ஒரு வருட வரலாற்றிற்கு 2,325 GB தேவைப்படும். கூடுதலாகக் கூடுதல் இடம் ஒதுக்குங்கள், ஏனெனில் disk நிறைந்தால் அடுத்த backup தோல்வியடையும். மேலும், restic-ன் prune செயல்பாட்டிற்கு, பழைய தரவை நீக்கி இடத்தை மீட்டெடுக்கக் கூடுதல் disk இடம் தேவைப்படும்.

பாதிக்கப்பட்ட (compromised) ஒரு server, தனது off-site backup-களை நீக்க முடியுமா?

ஆம், நீங்கள் அதற்கேற்ப வடிவமைக்கவில்லை என்றால் முடியும். சாதாரண SSH அல்லது SFTP repository-ல், எழுதும் அனுமதி (write access) கொண்ட key-யால் தரவை நீக்கவும் முடியும். தரவை நீக்க முடியாதவாறு மூல இயந்திரத்திற்கு அனுமதி வழங்கவும்: DatastoreBackup role மட்டும் கொண்ட PBS API token-ஐப் பயன்படுத்தவும், அதில் Datastore.Prune privilege இருக்கக்கூடாது. அல்லது --append-only flag-உடன் இயங்கும் rest-server-க்கு எதிராக restic-ஐப் பயன்படுத்தவும், இது ஏற்கனவே உள்ள backup-களை நீக்கவோ மாற்றவோ அனுமதிக்காது. ஒரு pull design இன்னும் பாதுகாப்பானது, ஏனெனில் இதில் மூல இயந்திரத்திடம் backup host-க்கான எந்த credential-உம் இருக்காது. retention செயல்பாட்டை மூல இயந்திரம் அல்லாத பக்கத்திலிருந்து இயக்கவும்.

backup VPS-ல் Proxmox Backup Server-ஐ இயக்க வேண்டுமா அல்லது restic-ஐயா?

நீங்கள் எதை restore செய்ய விரும்புகிறீர்களோ, அதற்கு ஏற்ற கருவியைத் தேர்ந்தெடுக்கவும். மூலமானது Proxmox VE ஆக இருந்து, நீங்கள் முழு virtual machine-ஐயும் திரும்பப் பெற விரும்பினால், PBS-ஐப் பயன்படுத்தவும். ஏனெனில் இது disk-image அளவில் backup எடுத்து, ஒரே கட்டத்தில் VM-ஐ restore செய்யும். மூலமானது Linux host ஆக இருந்து, நீங்கள் கோப்புகள் மற்றும் database dumps-ஐ மட்டும் திரும்பப் பெற விரும்பினால், restic-ஐப் பயன்படுத்தவும். இதற்கு இலக்கு இயந்திரத்தில் (target) ஒரு SSH கணக்கு மட்டுமே தேவை, மேலும் தரவு அனுப்பப்படும் முன்பே encrypt செய்யப்படும். இரண்டையும் பயன்படுத்துவது வழக்கமானது: hypervisor-க்கு PBS, அதில் இல்லாத server-களுக்கு restic.

ஒரு VPS backup-லிருந்து restore செய்ய எவ்வளவு காலம் ஆகும்?

தரவின் அளவை network வேகத்தால் வகுத்தால் கிடைக்கும் நேரமே குறைந்தபட்ச காலம். அதனுடன் decryption மற்றும் எழுதும் நேரத்தைச் சேர்க்கவும். 100 Mbit/s இணைப்பில் 500 GB தரவை restore செய்ய 11.1 மணிநேரம் ஆகும், அதே restore 1 Gbit/s port-ல் நடந்தால் 1.1 மணிநேரம் ஆகும். பல சிறிய கோப்புகள் இருந்தால், கோப்பு வாரியான overhead காரணமாக வேகம் குறையும். ஒருமுறை உண்மையான restore செய்து அந்த நேரத்தைக் குறித்துக்கொள்ளுங்கள், ஏனெனில் உங்கள் recovery திட்டத்திற்கு அந்த அளவீடு மட்டுமே நம்பகமானது.