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ಒಂದು ಅಪ್ಲೋಡ್ ಎಲ್ಲಾ ಇತರ ಹರಿವುಗಳನ್ನು ಹಸಿವಿನಿಂದ ಬಳಲಿಸಬಹುದು
ಅಪ್ಲಿಂಕ್ ತುಂಬಿಸುವ ಅಪ್ಲೋಡ್ ಕರೆಗಳು ಮತ್ತು ಬ್ರೌಸಿಂಗ್ ಅನ್ನು ಪ್ರತಿಕ್ರಿಯೆ ಇಲ್ಲದಂತೆ ಮಾಡುತ್ತದೆ, ಮತ್ತು ಬ್ಯಾಕಪ್ ಅದಕ್ಕಾಗಿ ಸ್ಪರ್ಧಿಸುವ ಏಕೈಕ ವಸ್ತುವಾಗಿರುವುದು ಅಪರೂಪ. ಎರಡನೇ ಸಿಂಕ್ ಕ್ಲೈಂಟ್ ತನ್ನಷ್ಟಕ್ಕೇ ಅದೇ ಲಕ್ಷಣವನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ. ಟನೆಲ್ ಅನ್ನು ದೂಷಿಸುವ ಮೊದಲು ಬೇರೆ ಏನು ಅಪ್ಲೋಡ್ ಆಗುತ್ತಿದೆ ಎಂದು ನೋಡಿ.
ಗರಿಷ್ಠ ಥ್ರೂಪುಟ್ಗಾಗಿ ಹೋರಾಡುವ ಬದಲು ಪರಿಕರ ದಾಖಲಿಸುವ ವೇಳಾಪಟ್ಟಿ ಅಥವಾ ಬ್ಯಾಂಡ್ವಿಡ್ತ್ ಮಿತಿಯನ್ನು ಬಳಸಿ; ಸಂವಾದಾತ್ಮಕ ಕೆಲಸಕ್ಕೆ ಜಾಗ ಬಿಡುವುದು ಸಾಮಾನ್ಯವಾಗಿ ಕೊನೆಯ ಕೆಲವು ಶೇಕಡಾಕ್ಕಿಂತ ಹೆಚ್ಚು ಮೌಲ್ಯದ್ದು. ನಂತರ ಮಿತಿ ನಿಜವಾಗಿ ಯಾವುದಕ್ಕೆ ಅನ್ವಯವಾಗುತ್ತದೆ ಎಂದು ಪರಿಶೀಲಿಸಿ, ಏಕೆಂದರೆ ಕೆಲವು ಪರಿಕರಗಳು ಪ್ರತಿ ಫೈಲ್ಗೆ, ಕೆಲವು ಇಡೀ ರನ್ಗೆ ಮಿತಿ ಹಾಕುತ್ತವೆ, ಮತ್ತು ಕೆಲವು ಸಣ್ಣ ಫೈಲ್ಗಳ ಹೆಚ್ಚುವರಿ ವೆಚ್ಚವನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ನಿರ್ಲಕ್ಷಿಸುತ್ತವೆ. ಕೆಲಸದ ಹೊರೆಗೆ ಹೊಂದದ ಮಿತಿ ಏನನ್ನೂ ಬದಲಿಸುವುದಿಲ್ಲ. ಸ್ಪ್ಲಿಟ್ ಟನೆಲಿಂಗ್ ಕೂಡ ಇಲ್ಲಿ ಸಂದೇಹಾರ್ಹ, ಏಕೆಂದರೆ ಲಾಂಚರ್ ಅನ್ನು ಟನೆಲ್ನಿಂದ ಹೊರಗಿಡುವುದು ಅಪ್ಲೋಡ್ ಮಾಡುವ ಸಹಾಯಕ ಸೇವೆಯನ್ನು ಹೊರಗಿಡುವುದಿಲ್ಲ. ಉದಾಹರಣೆಗೆ Rclone ವರ್ಗಾವಣೆ ಮಿತಿಗಳನ್ನು ಮತ್ತು ಮರುಪ್ರಯತ್ನದ ವರ್ತನೆಯನ್ನು ತನ್ನ ದಾಖಲೆಗಳಲ್ಲಿ ಪ್ರಕಟಿಸುತ್ತದೆ, ಇದು ಮಿತಿ ಏನನ್ನು ನಿಯಂತ್ರಿಸಬೇಕು ಎಂಬುದಕ್ಕೆ ಉಪಯುಕ್ತ ಉಲ್ಲೇಖವಾಗುತ್ತದೆ.
ವೇಗ ಪರೀಕ್ಷೆಯಲ್ಲ, ಮರುಸ್ಥಾಪನೆಯೊಂದಿಗೆ ಮುಗಿಸಿ
ಪೂರ್ಣಗೊಂಡ ಅಪ್ಲೋಡ್ ಅದರಿಂದ ಏನಾದರೂ ಮರುಸ್ಥಾಪನೆಯಾಗುವವರೆಗೆ ಬ್ಯಾಕಪ್ ಅಲ್ಲ. ನಿರೀಕ್ಷಿತ ಆವೃತ್ತಿ ಇದೆ ಎಂದು ಖಚಿತಪಡಿಸಿ, ನಂತರ ಪರಿಕರ ದಾಖಲಿಸುವ ವಿಧಾನದಿಂದ ಪ್ರತಿನಿಧಿ ಫೈಲ್ ಮರುಸ್ಥಾಪಿಸಿ. ಮರುಪ್ರಾಪ್ತಿ ಮಾಹಿತಿಯನ್ನು ನೀವು ಕಳೆದುಕೊಳ್ಳಬಹುದಾದ ಯಂತ್ರ ಅಥವಾ ಪ್ರೊಫೈಲ್ನಿಂದ ಬೇರೆಡೆ ಇರಿಸಿ, ಮತ್ತು ಪ್ರಯೋಗ ಅಚ್ಚುಕಟ್ಟಾಗಿರಲಿ ಎಂದು ಕೆಲಸ ಮಾಡುವ ಬ್ಯಾಕಪ್ ಅನ್ನು ಎಂದಿಗೂ ಬಿಸಾಡಬೇಡಿ.
restic snapshots --latest 3
restic restore latest --target /tmp/restore-check --include /etc/hostsನೆಟ್ವರ್ಕ್ ಬದಲಾವಣೆಯ ನಂತರ ವರ್ಗಾವಣೆ ಮತ್ತು ಮರುಸ್ಥಾಪನೆ ಎರಡನ್ನೂ ಪುನರಾವರ್ತಿಸಿ, ಸುಧಾರಣೆ ಕೇವಲ ಡೇಟಾವನ್ನು ವೇಗವಾಗಿ ಸರಿಸುವುದಲ್ಲ, ಬ್ಯಾಕಪ್ಗೆ ಸೇವೆ ಸಲ್ಲಿಸುತ್ತದೆ ಎಂದು ತೋರಿಸಲು. ಆ ಎರಡನೇ ಸುತ್ತೇ ಟಿಕೆಟ್ ಮುಚ್ಚುತ್ತದೆ. ಪರೀಕ್ಷಿಸದ ಮರುಸ್ಥಾಪನೆಯೊಂದಿಗೆ ವೇಗವಾದ ವರ್ಗಾವಣೆ ರಕ್ಷಣೆಯಿಲ್ಲದೆ ಇರುವ ನಿಧಾನ ಮಾರ್ಗ.