VPN ಮೂಲಕ rsync: ಮುರಿದ ವರ್ಗಾವಣೆಯನ್ನು ಮರುಬಳಕೆ ಮಾಡುವ ಮರುಪ್ರಯತ್ನ

ಹನ್ನೆರಡು ಗಿಗಾಬೈಟ್ ಗಾತ್ರದ ಆರ್ಕೈವ್ ನ ನಾಲ್ಕು ಗಿಗಾಬೈಟ್ ಹಂತದಲ್ಲಿ ನಿಮ್ಮ ಅಪ್ಲೋಡ್ ನಿಲ್ಲುತ್ತದೆ, ಮತ್ತು ಡೌನ್ಲೋಡ್ ನಿರ್ವಾಹಕರಿಂದ ಕಲಿತ ಅಭ್ಯಾಸ ಮುಂದುವರಿಸು ಒತ್ತು ಎನ್ನುತ್ತದೆ. rsync TCP ಹರಿವನ್ನು ಮುಂದುವರಿಸುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ಆ ಹರಿವು ಸುರಂಗದ ಕೊನೆಯ ಮರುಪ್ರಸಾರದೊಂದಿಗೆ ಹೋಯಿತು. ಅದು ಮಾಡಬಲ್ಲದ್ದು ಈಗಾಗಲೇ ಸ್ವೀಕರಿಸಿದ ಬೈಟ್ ಗಳನ್ನು ಇಟ್ಟುಕೊಂಡು ಮುಂದಿನ ಪ್ರಯತ್ನಕ್ಕೆ ಆಧಾರವಾಗಿ ಬಳಸುವುದು, ಇದು ಬೇರೆ ನಿಯಮಗಳ ಗುಂಪಿನ ಬೇರೆ ಕಾರ್ಯವಿಧಾನ. ನೀವು ಆಯ್ಕೆ ಮಾಡುವ ಫ್ಲ್ಯಾಗ್ ಗಳು ಈ ಮರುಬಳಕೆ ನಡೆಯುತ್ತದೆಯೇ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತವೆ.

ಮರುಪ್ರಯತ್ನ ಸ್ಥಿತಿಯನ್ನು ಮರುನಿರ್ಮಿಸುತ್ತದೆ, ಹರಿವನ್ನು ಮುಂದುವರಿಸುವುದಿಲ್ಲ

SSH ಅಧಿವೇಶನ ಕುಸಿದಾಗ, ದೂರದ ತುದಿಯಲ್ಲಿ ಡಿಸ್ಕ್ ಗೆ ಬರೆದದ್ದು ಮಾತ್ರ ಉಳಿಯುತ್ತದೆ, ಬೇರೇನೂ ಇಲ್ಲ. ಮತ್ತೆ ಸೇರಲು ಅಧಿವೇಶನ ಟೋಕನ್ ಇಲ್ಲ ಮತ್ತು ಮರುಪ್ಲೇ ಮಾಡಲು ಕ್ರಮ ಸಂಖ್ಯೆ ಇಲ್ಲ. ಮುಂದಿನ ಸಲ ಸ್ವಚ್ಛ ಸಂಪರ್ಕ ತೆರೆಯುತ್ತದೆ, ಮೂಲವನ್ನು ಮತ್ತೆ ಓದುತ್ತದೆ ಮತ್ತು ಸ್ವೀಕರಿಸುವವರಿಗೆ ಈಗಾಗಲೇ ಏನಿದೆ ಎಂದು ಕೇಳುತ್ತದೆ.

ಆ ಕೊನೆಯ ಪ್ರಶ್ನೆಯೇ ಭಾಗಶಃ ಫೈಲ್ ಇಟ್ಟುಕೊಳ್ಳುವುದು ಏಕೆ ಯೋಗ್ಯ ಎಂಬುದನ್ನು ವಿವರಿಸುತ್ತದೆ. ಸ್ವೀಕರಿಸುವವರ ಪ್ರತಿ rsync ಗೆ ಹೋಲಿಸಲು ಏನನ್ನೋ ಕೊಡುತ್ತದೆ, ಮತ್ತು ಅಲ್ಗಾರಿದಮ್ ಗುರುತಿಸಬಲ್ಲ ವ್ಯತ್ಯಾಸಗಳನ್ನು ಮಾತ್ರ ಕಳುಹಿಸುತ್ತದೆ. ಇದು ಇನ್ನೂ ಮೆಟಾಡೇಟಾದ ಹೊಸ ವರ್ಗಾವಣೆ ಮತ್ತು ಮೂಲದ ಮೇಲೆ ಹೊಸ ಸುತ್ತು, ಆದ್ದರಿಂದ ಉಳಿತಾಯವಾದ ಸಮಯ ಫೈಲ್ ಎಷ್ಟು ಹೊಂದಿಕೆಯಾಗುತ್ತದೆ ಎಂಬುದಕ್ಕೆ ಅನುಪಾತದಲ್ಲಿದೆ, ಹಿಂದಿನ ಸಂಪರ್ಕ ಎಷ್ಟು ಮುಂದೆ ಸಾಗಿತ್ತು ಎಂಬುದಕ್ಕಲ್ಲ. ಸ್ವೀಕರಿಸುವವರು ಏನನ್ನೂ ಇಟ್ಟುಕೊಳ್ಳದಿದ್ದರೆ, ಮುಂದಿನ ಪ್ರಯತ್ನ ಪೂರ್ಣ ಪ್ರತಿ, ಮೊದಲನೆಯದು ಎಷ್ಟು ಗಿಗಾಬೈಟ್ ಸರಿಸಿದರೂ.

ಮರುಬಳಕೆ ಮಾಡಬಹುದಾದ ತುಣುಕು ಎಲ್ಲಿ ಇರುತ್ತದೆ ಎಂದು ನಿರ್ಧರಿಸಿ

ಪೂರ್ವನಿಯೋಜಿತ ವರ್ತನೆ ಭಾಗಶಃ ಫೈಲ್ ಅನ್ನು ಗಮ್ಯ ಮಾರ್ಗದಲ್ಲಿ ಬರೆಯುತ್ತದೆ, ಇದು ಅರ್ಧ ಬರೆದ ಆರ್ಕೈವ್ ಅನ್ನು ಅಂತಿಮ ಹೆಸರಿನ ಅಡಿಯಲ್ಲಿ ಕಾಣುವಂತೆ ಮಾಡುತ್ತದೆ. --partial-dir ಅದನ್ನು ನೀವು ಆರಿಸಿದ ಡೈರೆಕ್ಟರಿಗೆ ಸರಿಸುತ್ತದೆ, ಮತ್ತು ಕೈಪಿಡಿ ಆ ಡೈರೆಕ್ಟರಿಯನ್ನು ಮುಂದಿನ ವರ್ಗಾವಣೆ ಡೇಟಾ ಆಗಿ ಬಳಸಲು ಇಟ್ಟುಕೊಳ್ಳಲಾಗಿದೆ ಎಂದು ವಿವರಿಸುತ್ತದೆ. ಸಾಪೇಕ್ಷ ಹೆಸರು ಗಮ್ಯ ಡೈರೆಕ್ಟರಿ ಅಡಿಯಲ್ಲಿ ಪರಿಹರಿಸಲ್ಪಡುತ್ತದೆ, ಎರಡು ತುದಿಗಳ ವಿನ್ಯಾಸ ಬೇರೆಯಾಗಿರಬಹುದಾದಾಗ ನಿಮಗೆ ಬೇಕಾದದ್ದು ಅದೇ.

rsync -e ssh --partial-dir=.rsync-partial --info=progress2 -- \
  large-archive.bin [email protected]:/srv/incoming/

ಗಮ್ಯದಲ್ಲೂ ಕ್ರಮ ಮುಖ್ಯ: ಭಾಗಶಃ ಡೈರೆಕ್ಟರಿಗೆ ತುಣುಕಿಗೆ ಸಾಕಷ್ಟು ಜಾಗ ಬೇಕು, ಮತ್ತು ಸಂಪುಟಕ್ಕೆ ಪೂರ್ಣ ಫೈಲ್ ಗೂ ಸಾಕಷ್ಟು ಜಾಗ ಬೇಕು. ವರ್ಗಾವಣೆಯ ಮಧ್ಯದಲ್ಲಿ ಗುರಿ ಸಂಪುಟ ತುಂಬಿದರೆ ಜಾಲ ಸಮಸ್ಯೆಯಂತೆ ಕಾಣುವ ಆದರೆ ಅಲ್ಲದ ವೈಫಲ್ಯ ಉಂಟಾಗುತ್ತದೆ, ಮತ್ತು ಇಟ್ಟುಕೊಂಡ ತುಣುಕು ಕತ್ತರಿಸಲ್ಪಟ್ಟು ಉಳಿಯಬಹುದು. ಓಟ ಪ್ರಾರಂಭವಾಗುವ ಮೊದಲು ಸ್ವೀಕರಿಸುವ ಹೋಸ್ಟ್ ನಲ್ಲಿ ಮುಕ್ತ ಜಾಗ ಪರಿಶೀಲಿಸಿ, ವಿಫಲವಾದ ಮೇಲಲ್ಲ. ಅದೇ SSH ಮಾರ್ಗದಲ್ಲಿ df -h ಜೊತೆ ಕೆಲವು ಸೆಕೆಂಡುಗಳು ಯೋಜನೆಯ ಅಗ್ಗದ ಸಾಧ್ಯ ಪರೀಕ್ಷೆ.

ಅನುಮತಿಗಳು ಚಿಕ್ಕದಾದರೂ ನಿಜವಾದ ಚಿಂತೆ. ಸಂಬಂಧವಿಲ್ಲದ ಖಾತೆಗಳು ಬರೆಯಬಹುದಾದ ಭಾಗಶಃ ಡೈರೆಕ್ಟರಿ, ನಿಮ್ಮ ಮುಂದಿನ ಓಟ ಈಗಾಗಲೇ ಸ್ವೀಕರಿಸಿದ್ದೆಂದು ಪರಿಗಣಿಸುವ ವಿಷಯವನ್ನು ಬೇರೆಯವರು ಬದಲಿಸಲು ಅವಕಾಶ ನೀಡುತ್ತದೆ. ಅದನ್ನು ವರ್ಗಾವಣೆ ಖಾತೆಯ ಮಾಲೀಕತ್ವದಲ್ಲಿ ಇರಿಸಿ, ಮತ್ತು ಬೇರೆ ಸೇವೆಗಳು ಪ್ರಕಟಿಸುವ ಸ್ಥಳದಲ್ಲಿ ಇಡಬೇಡಿ.

ಅದೇ ಪ್ರತಿಯನ್ನು ಓಡಿಸಿ, ಬುದ್ಧಿವಂತ ಪ್ರತಿಯನ್ನಲ್ಲ

ಮರುಬಳಕೆ ಮೂಲ ಮತ್ತು ಗಮ್ಯ ಇನ್ನೂ ಒಂದೇ ವಸ್ತುವನ್ನು ವಿವರಿಸುವಾಗ ಮಾತ್ರ ಅನ್ವಯಿಸುತ್ತದೆ. ಅದೇ ಮಾರ್ಗ, ಅದೇ ಹೆಸರು, ಅದೇ ಫೈಲ್. ಮೂಲದ ಹೆಸರು ಬದಲಿಸುವುದು ಅಥವಾ ಬೇರೆ ಗಮ್ಯ ಡೈರೆಕ್ಟರಿ ತೋರಿಸುವುದು ಉಪಯುಕ್ತವಲ್ಲದ್ದರ ವಿರುದ್ಧ ಹೊಸ ಹೋಲಿಕೆ ಪ್ರಾರಂಭಿಸುತ್ತದೆ.

ಡೆಲ್ಟಾ ವರ್ತನೆಯನ್ನು ನಿರೀಕ್ಷಿಸುತ್ತಾ --whole-file ಸೇರಿಸಬೇಡಿ. ಆ ಆಯ್ಕೆ rsync ಗೆ ರೋಲಿಂಗ್ ಚೆಕ್ಸಮ್ ಹೋಲಿಕೆ ಇಲ್ಲದೆ ಇಡೀ ಫೈಲ್ ಪ್ರತಿ ಮಾಡಲು ಹೇಳುತ್ತದೆ, ಇದು ವೇಗದ ಸ್ಥಳೀಯ ಕೊಂಡಿಯಲ್ಲಿ ಸೂಕ್ತ ಮತ್ತು ವಿಫಲ ದೂರದ ಅಪ್ಲೋಡ್ ನಂತರ ಸಂಪೂರ್ಣ ತಪ್ಪು. --inplace ಕೂಡ ಕಥೆ ಬದಲಿಸುತ್ತದೆ: ಅದು ನೇರವಾಗಿ ಗಮ್ಯ ಫೈಲ್ ಗೆ ಬರೆಯುತ್ತದೆ, ಆದ್ದರಿಂದ ಅಡಚಣೆ ಹಳೆಯ ಮತ್ತು ಹೊಸ ವಿಷಯ ಬೆರೆಸುವ ಫೈಲ್ ಬಿಡುತ್ತದೆ, ಹಿಂದೆ ಸರಿಯಲು ಪ್ರತ್ಯೇಕ ತುಣುಕು ಇರುತ್ತದಿಲ್ಲ.

ಪ್ರಗತಿ ಸಾಲು ವರ್ಗಾವಣೆಯ ಒಟ್ಟು ಪ್ರಗತಿ ತಿಳಿಸುತ್ತದೆ. ಅದು ಪೂರ್ಣಗೊಳಿಸುವ ಸಂಕೇತವಲ್ಲ. ಸಂಪರ್ಕ ಇನ್ನೂ ತೆರೆದಿರುವಾಗ ನೂರು ಪ್ರತಿಶತ ತಲುಪಿದ ಸಂಖ್ಯೆ ಎಂದರೆ ಡೇಟಾ ತಳ್ಳಲಾಗಿದೆ, ಸ್ವೀಕರಿಸುವವರು ಏನನ್ನೋ ಮರುನಾಮಕರಣ ಮಾಡಿದ್ದಾರೆ, ಸಿಂಕ್ ಮಾಡಿದ್ದಾರೆ ಅಥವಾ ಸ್ವೀಕರಿಸಿದ್ದಾರೆ ಎಂದಲ್ಲ.

ವಸ್ತು ಹೊಂದಿಕೆಯಾದ ಮೇಲೆಯೇ ಸ್ವೀಕರಿಸಿ

ಮೊದಲು ನಿರ್ಗಮನ ಸ್ಥಿತಿ ದೃಢೀಕರಿಸಿ, ನಂತರ ದೋಷಗಳ ಅನುಪಸ್ಥಿತಿಯನ್ನು ನಂಬುವ ಬದಲು ಫಲಿತಾಂಶವನ್ನು ಹೋಲಿಸಿ. ಗಾತ್ರ ಪರಿಶೀಲನೆ ಹೆಚ್ಚಿನ ಕತ್ತರಿಸಿದ ವರ್ಗಾವಣೆಗಳನ್ನು ಹಿಡಿಯುತ್ತದೆ; ಚೆಕ್ಸಮ್ ಹೋಲಿಕೆ ಉಳಿದದ್ದನ್ನು ಹಿಡಿಯುತ್ತದೆ, ಮತ್ತು ಅಪ್ಲೋಡ್ ಮತ್ತೆ ಓಡಿಸುವುದಕ್ಕೆ ಹೋಲಿಸಿದರೆ ಎರಡೂ ಅಗ್ಗ.

ಆರ್ಕೈವ್ ಅನ್ನು ಕೆಳ ಹರಿವಿನ ಪ್ರಕ್ರಿಯೆ ಪ್ರಕಟಿಸಿದರೆ, ಆ ಪ್ರಕ್ರಿಯೆ ಸ್ವೀಕೃತ ಫೈಲ್ ಗಾಗಿ ಕಾಯುವಂತೆ ಮಾಡಿ. ಅಂತಿಮ ಹೆಸರಿನ ಅಡಿಯಲ್ಲಿ ಕಣ್ಗಾವಲು ಡೈರೆಕ್ಟರಿಗೆ ಬೀಳುವ ಇಟ್ಟುಕೊಂಡ ತುಣುಕನ್ನು ಮುಂದಿನ ಸ್ಕ್ಯಾನ್ ಎತ್ತಿಕೊಳ್ಳುತ್ತದೆ, ಮತ್ತು ಗ್ರಾಹಕನ ದೋಷ ಖರಾಬಾದ ಇನ್ಪುಟ್ ಬಗ್ಗೆ ಇರುತ್ತದೆ, ಎಂದಿಗೂ ಮುಗಿಯದ ವರ್ಗಾವಣೆ ಬಗ್ಗೆ ಅಲ್ಲ.

ಸ್ವೀಕರಿಸುವವರು ದೃಢೀಕರಿಸುವವರೆಗೆ ಮೂಲವನ್ನು ಮುಟ್ಟಬೇಡಿ. ಪ್ರಯತ್ನಗಳ ನಡುವೆ ಆರ್ಕೈವ್ ಮರುಉತ್ಪಾದಿಸುವುದು ಹೋಲಿಕೆಯ ಆಧಾರ ಬದಲಿಸುತ್ತದೆ, ಮತ್ತು ಮುಂದಿನ ಓಟ ಬಹುತೇಕ ಎಲ್ಲವನ್ನೂ ವರ್ಗಾಯಿಸುತ್ತದೆ ಅಥವಾ ಹಳೆಯದಕ್ಕೂ ಹೊಸದಕ್ಕೂ ಹೊಂದಿಕೆಯಾಗದ ಫೈಲ್ ಉತ್ಪಾದಿಸುತ್ತದೆ.

ಮಿತಿ ಫ್ಲ್ಯಾಗ್ ಅಲ್ಲ, ಕೊಂಡಿ ಆಗಿರುವಾಗ

ಶೀರ್ಷಿಕೆ ಮತ್ತು ಪ್ರೋಟೋಕಾಲ್ ಹೆಚ್ಚುವರಿ ವೆಚ್ಚ ವರ್ಗಾವಣೆಯ ಒಂದು ವೆಚ್ಚ, ಮತ್ತು ದೊಡ್ಡ ಫೈಲ್ ಎಷ್ಟು ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ ಎಂಬುದನ್ನು ಅದೇ ಅಪರೂಪವಾಗಿ ನಿರ್ಧರಿಸುತ್ತದೆ. ಮರುಪ್ರಾರಂಭದ ವರ್ತನೆ ಹೆಚ್ಚು ಮುಖ್ಯ: ಕೈ ಹೆಜ್ಜೆಗಳಿಲ್ಲದೆ ಅಡಚಣೆಯನ್ನು ದಾಟುವ ವಿಧಾನ ವೇಗದ ವಿಧಾನಕ್ಕಿಂತ ಬೇಗ ಬಳಸಬಹುದಾದ ಫೈಲ್ ನೀಡುತ್ತದೆ, ಮತ್ತೆ ಪ್ರಾರಂಭಿಸಬೇಕಾದ ವಿಧಾನಕ್ಕೆ ಹೋಲಿಸಿದರೆ. ಎರಡೂ ತುದಿಗಳ ಸಂಗ್ರಹಣೆ ಮತ್ತು ದೃಢೀಕರಣ ಮಾರ್ಗ ಅದೇ ಹೋಲಿಕೆಯಲ್ಲಿ ಸೇರುತ್ತವೆ.

ಅನುಮತಿಸಿದ ಪರ್ಯಾಯ ಮಾರ್ಗಗಳನ್ನು ಅದೇ ಫೈಲ್ ಮತ್ತು ಅದೇ ಗಮ್ಯದೊಂದಿಗೆ ಹೋಲಿಸಿ, ಮತ್ತು ಅಡಚಣೆಯ ನಂತರ ಪ್ರತಿಯೊಂದೂ ಎಲ್ಲಿಂದ ಮತ್ತೆ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ ಎಂದು ಬರೆಯಿರಿ. ಆ ಒಂದೇ ಕಾಲಮ್ VPN ಮೂಲಕ ಹನ್ನೆರಡು ಗಿಗಾಬೈಟ್ ಅಪ್ಲೋಡ್ ಬಗ್ಗೆ ಸಣ್ಣ ಪರೀಕ್ಷೆಯಲ್ಲಿ ಅಳೆದ ಯಾವುದೇ ಗರಿಷ್ಠ ವೇಗಕ್ಕಿಂತ ಹೆಚ್ಚು ಹೇಳುತ್ತದೆ.