VPN ద్వారా క్లౌడ్ బ్యాకప్‌లు నెమ్మదిగా ఉన్నాయి: నిజమైన దశను కనుగొనండి
నెమ్మదిగా బ్యాకప్ బదిలీ చేయకుండా స్కాన్, హాష్ లేదా మళ్లీ ప్రయత్నించవచ్చు. మార్గాలను మార్చే ముందు దశ, గమ్యం రకం మరియు పునరుద్ధరణను పోల్చండి.
VPN ద్వారా జరుపుకుంటూ వెళ్లే బ్యాకప్ టన్నెల్‌ను డిస్‌కనెక్ట్ చేసి మళ్లీ కొలిచే స్పష్టమైన ప్రయోగానికి ఆహ్వానిస్తుంది. ఆ ప్రయోగం తరచుగా మరొక ప్రశ్నకు సమాధానం ఇస్తుంది, ఎందుకంటే పని బైట్‌లను కదిలించడం బదులు ఫైల్‌లను హాష్ చేస్తూ లేదా మళ్లీ ప్రయత్నం కోసం వేచి ఉండవచ్చు. మొదట దశలను వేరు చేయండి, ఫిర్యాదు నిర్దిష్ట ఆశించిన ఫలితంతో కూడిన నిర్దిష్ట పరీక్షగా మారుతుంది. బదిలీ దశ నిజంగా నెమ్మదిగా ఉన్నప్పుడే మార్గం అభ్యర్థి అవుతుంది.
నెమ్మదిగా అనిపించినప్పుడు పని ఏ దశలో ఉంది
బ్యాకప్ సాధనాలు దశల గుండా వెళ్తాయి: ఫైల్‌లను కనుగొనడం, వాటిని చదివి హాష్ చేయడం, కుదించడం, ఎన్‌క్రిప్ట్ చేయడం, అప్‌లోడ్ చేయడం, ఆపై నిర్ధారించడం. ప్రతి దశకు దాని స్వంత అడ్డంకి ఉంటుంది, వాటిలో కొన్ని మాత్రమే నెట్‌వర్క్‌ను తాకుతాయి. ఇంకా ఏ దశను నివేదించని సాధనం స్కాన్ పూర్తి కాలేదని మీకు చెబుతోంది.
మిలియన్ చిన్న ఫైల్‌లను సిద్ధం చేయడానికి ఇరవై నిమిషాలు గడిపే పని టన్నెల్ వేగవంతమైనప్పుడు వేగవంతం కాదు. అప్‌లింక్‌ను నింపే పని వేరే పరిష్కారం ఉన్న సామర్థ్య సమస్య. ఆలస్యం జరుగుతున్నప్పుడు పురోగతి అవుట్‌పుట్ చదవండి, దశను గుర్తించండి మరియు సమయాన్ని రాయండి, ఎందుకంటే ఫిర్యాదు సమయంలోని దశ మాత్రమే ముఖ్యం. చిన్న ఫైల్‌లు ఒక పెద్ద వస్తువు కంటే భిన్నంగా ప్రవర్తిస్తాయి, ఎందుకంటే ప్రతి ఫైల్‌కు రాకపోకలు ఆధిక్యంలో ఉంటాయి మరియు బదిలీ ఎప్పుడూ స్థిరమైన రేటుకు చేరుకోదు. టన్నెల్ గురించి ముగింపులకు రాకముందు సమానమైన వాటిని సమానమైన వాటితో పోల్చండి.
పబ్లిక్ ఎండ్‌పాయింట్ మరియు ప్రైవేట్ NAS వేర్వేరుగా విఫలమవుతాయి
పబ్లిక్ బ్యాకప్ సేవ తన స్వంత ప్రామాణీకృత అప్లికేషన్ కనెక్షన్‌ను కలిగి ఉంటుంది, టన్నెల్ పొడవైన మార్గంలో ఒక దశ మాత్రమే. ప్రైవేట్ NAS సాధారణంగా మీ నెట్‌వర్క్‌కు ప్రాథమిక చేరిక కోసం ఆ టన్నెల్‌పై ఆధారపడి ఉంటుంది. ఆ భేదమే డిస్‌కనెక్ట్ చేయడం చెల్లుబాటు అయ్యే ప్రాతిపదికరేఖా లేక ఏదీ లేని పరీక్షా అని నిర్ణయిస్తుంది.
పబ్లిక్ సందర్భంలో, విధానం అనుమతిస్తే మరో మార్గంలో అదే పని న్యాయమైన పోలిక కావచ్చు. ప్రైవేట్ సందర్భంలో, టన్నెల్‌ను తొలగించడం సర్వర్‌కు ఎలాంటి మార్గాన్ని వదలదు, కాబట్టి ఫలితం మీరు ఉపయోగించే మార్గాన్ని కాక మీరు తొలగించిన మార్గాన్ని వివరిస్తుంది.
| Destination | What the tunnel provides | Valid baseline |
|---|---|---|
| Public backup service | One hop among several | The same job over another route |
| Private NAS | The only path to the server | None that removes the tunnel |
| Self-hosted gateway | Path plus split-DNS policy | Only if the policy is unchanged |
ఆగిపోవడం నెమ్మదిగా బదిలీ నుండి భిన్నమైన వైఫల్యం
ఆ పట్టికలోని మూడవ నిలువు వరుస స్థిరత్వ పరీక్ష అసలు నిర్వహించవచ్చా అని నిర్ణయిస్తుంది, ఎందుకంటే టన్నెల్‌ను తొలగించే ప్రాతిపదికరేఖ మరో మార్గం ఉన్న చోట మాత్రమే అర్థవంతం. ఉపయోగించదగిన ప్రాతిపదికరేఖతో, సగటు రేటు కాక వైఫల్యం ఆకారాన్ని చూడండి. తక్కువ కానీ స్థిరమైన అప్‌లోడ్ సామర్థ్యాన్ని సూచిస్తుంది, అయితే ఆగి మళ్లీ ప్రారంభమయ్యే పని అంతరాయం, ప్రామాణీకరణ లేదా ఒక ఇబ్బందికరమైన ఫైల్‌ను సూచిస్తుంది. ఈ రెండూ దాదాపు ఒకేలాంటి ఫిర్యాదులను మరియు పూర్తిగా భిన్నమైన మరమ్మతులను సృష్టిస్తాయి.
మళ్లీ ప్రయత్నాలు ప్రతి కొలతను వికృతం చేస్తాయి, ఎందుకంటే తీగపై ఉన్న బైట్‌లు నిజంగా మారిన పరిమాణం కంటే ఎక్కువగా ఉండవచ్చు. ఏమి జరుగుతుందో చూడటానికి పనిని మళ్లీ ఆపే ముందు పునఃప్రారంభ ప్రవర్తనను చదవండి, ఎందుకంటే విభజించిన పునఃప్రారంభించగల అప్‌లోడ్‌లు చవకగా కోలుకుంటాయి, మొత్తం ఫైల్ పునఃప్రారంభం కాదు. ప్రతి కొన్ని నిమిషాలకు మళ్లీ కనెక్ట్ అయ్యే టన్నెల్ కూడా నిజంగా స్థిరత్వ సమస్య అయినప్పుడు బ్యాండ్‌విడ్త్ సమస్యలా కనిపిస్తుంది. మార్గం యొక్క MTU దీన్ని మరింత తీవ్రతరం చేస్తుంది, ఎందుకంటే ఉపయోగకరమైన పేలోడ్‌ను తగ్గించే టన్నెల్ పెద్ద విభాగాలను ఆపుతుంది, చిన్నవి దాటిపోతాయి.
journalctl -u wg-quick@wg0 -n 50 --no-pager
ss -tin dst :443
ping -M do -s 1400 -c 3 backup.example.comఒక అప్‌లోడ్ మిగిలిన అన్ని ప్రవాహాలను ఆకలితో చంపగలదు
అప్‌లింక్‌ను నింపే అప్‌లోడ్ కాల్‌లు మరియు బ్రౌజింగ్‌ను ప్రతిస్పందన లేనివిగా చేస్తుంది, మరియు బ్యాకప్ దాని కోసం పోటీ పడే ఏకైక వస్తువు అరుదుగా ఉంటుంది. రెండవ సింక్ క్లయింట్ తనంతట తానే అదే లక్షణాన్ని సృష్టిస్తుంది. టన్నెల్‌ను నిందించే ముందు ఇంకా ఏమి అప్‌లోడ్ అవుతోందో చూడండి.
గరిష్ఠ throughput కోసం పోరాడే బదులు సాధనం డాక్యుమెంట్ చేసే షెడ్యూల్ లేదా బ్యాండ్‌విడ్త్ పరిమితిని ఉపయోగించండి; ఇంటరాక్టివ్ పని కోసం స్థలం వదలడం సాధారణంగా చివరి కొన్ని శాతం కంటే ఎక్కువ విలువైనది. తర్వాత పరిమితి నిజంగా దేనికి వర్తిస్తుందో తనిఖీ చేయండి, ఎందుకంటే కొన్ని సాధనాలు ప్రతి ఫైల్‌కు, కొన్ని మొత్తం రన్‌కు పరిమితి పెడతాయి, మరికొన్ని చిన్న ఫైల్‌ల అదనపు భారాన్ని పూర్తిగా పట్టించుకోవు. పని భారానికి సరిపోని పరిమితి ఏమీ మార్చదు. స్ప్లిట్ టన్నెలింగ్ కూడా ఇక్కడ అనుమానాస్పదం, ఎందుకంటే లాంచర్‌ను టన్నెల్ నుండి మినహాయించడం అప్‌లోడ్ చేసే సహాయక సేవను మినహాయించదు. ఉదాహరణకు Rclone బదిలీ పరిమితులు మరియు మళ్లీ ప్రయత్నం ప్రవర్తన రెండింటినీ తన డాక్యుమెంటేషన్‌లో ప్రచురిస్తుంది, ఇది పరిమితి ఏమి నియంత్రించాలి అనే దానికి ఉపయోగకరమైన సూచనగా మారుతుంది.
వేగ పరీక్షతో కాదు, పునరుద్ధరణతో ముగించండి
పూర్తయిన అప్‌లోడ్ దాని నుండి ఏదైనా పునరుద్ధరించబడే వరకు బ్యాకప్ కాదు. ఆశించిన వెర్షన్ ఉందని నిర్ధారించి, తర్వాత సాధనం డాక్యుమెంట్ చేసే విధానంతో ప్రతినిధి ఫైల్‌ను పునరుద్ధరించండి. పునరుద్ధరణ సమాచారాన్ని మీరు కోల్పోయే మెషీన్ లేదా ప్రొఫైల్ కాకుండా మరెక్కడైనా ఉంచండి, మరియు ప్రయోగాన్ని చక్కగా ఉంచడానికి పనిచేసే బ్యాకప్‌ను ఎప్పుడూ విసిరేయకండి.
restic snapshots --latest 3
restic restore latest --target /tmp/restore-check --include /etc/hostsనెట్‌వర్క్ మార్పు తర్వాత బదిలీ మరియు పునరుద్ధరణ రెండింటినీ పునరావృతం చేయండి, మెరుగుదల డేటాను వేగంగా కదిలించడమే కాక బ్యాకప్‌కు సేవ చేస్తుందని చూపించడానికి. ఆ రెండవ రన్‌యే టికెట్‌ను మూస్తుంది. పరీక్షించని పునరుద్ధరణతో వేగవంతమైన బదిలీ రక్షణ లేకుండా ఉండటానికి నెమ్మదైన మార్గం.