ಎರಡು ಸರ್ವರ್ಗಳು, ಒಂದು VPN, ಎರಡೂ ಕಡೆ ಇರಲೇಬೇಕಾದ ಒಂದು ಡೈರೆಕ್ಟರಿ, ಮತ್ತು ಚಲಾಯಿಸಲು ಸುಲಭ ಆದರೆ ಹಿಂತಿರುಗಿಸಲು ಕಷ್ಟವಾದ ಒಂದು ಆಜ್ಞೆ. ಅದನ್ನು ಬರೆಯುವ ಮೊದಲು ಯಾವ ಪ್ರತಿ ಅಧಿಕೃತ ಎಂದು ನಿರ್ಧರಿಸಿ, ಏಕೆಂದರೆ rsync ಬಗ್ಗೆ ಪ್ರತಿ ಮುಂದಿನ ಪ್ರಶ್ನೆ ಆ ಉತ್ತರವನ್ನು ಅವಲಂಬಿಸಿದೆ. ಏಕಮುಖ ಪ್ರತಿ, ಹಂಚಿದ ಕೆಲಸದ ಫೋಲ್ಡರ್ ಮತ್ತು ಆವೃತ್ತಿಗಳಿರುವ ಆರ್ಕೈವ್ ಸಂಪಾದನೆ ಮತ್ತು ಅಳಿಸುವಿಕೆಗೆ ಬೇರೆ ಬೇರೆ ನಿಯಮಗಳನ್ನು ಕೇಳುತ್ತವೆ. ಸುರಂಗ ಮಾರ್ಗವನ್ನು ಒದಗಿಸುತ್ತದೆ, ಅವುಗಳಲ್ಲಿ ಯಾವುದರ ಬಗ್ಗೆಯೂ ಅದಕ್ಕೆ ಅಭಿಪ್ರಾಯವಿಲ್ಲ.

ಆಜ್ಞೆ ಬರೆಯುವ ಮೊದಲು ಯಾವ ಪ್ರತಿ ಗೆಲ್ಲುತ್ತದೆ ಎಂದು ನಿರ್ಧರಿಸಿ

ದಿಕ್ಕನ್ನು ಒಂದು ವಾಕ್ಯದಲ್ಲಿ ಬರೆಯಿರಿ, ಪ್ರತಿ ಬದಿಯ ಹೋಸ್ಟ್ ಹೆಸರು ಮತ್ತು ಮಾರ್ಗ ಸೇರಿಸಿ, ಮತ್ತು ಡೇಟಾದ ಮಾಲೀಕರಿಂದ ಒಪ್ಪಿಗೆ ಪಡೆಯಿರಿ. ಈ ವಿವರಣೆಯಲ್ಲಿ ಮೂಲ /srv/publish/, ಗಮ್ಯ fileserver.example ನಲ್ಲಿರುವ ಒಂದು ಖಾತೆ, ಅದು /srv/mirror/ ನಲ್ಲಿ ಮಾತ್ರ ಬರೆಯಲು ಅನುಮತಿ ಪಡೆದಿದೆ.

ಪ್ರತಿ ಮಾಡುವ ಮೊದಲು ಸಾಗಣೆ ಸತ್ಯಗಳನ್ನು ದೃಢೀಕರಿಸಿ: SSH ಹೋಸ್ಟ್ ಕೀ ಪರಿಶೀಲಿಸಲಾಗಿದೆ, ಗಮ್ಯ ಖಾತೆ ಪ್ರತಿ ಪ್ರದೇಶದಲ್ಲಿ ಬರೆಯಬಹುದು ಬೇರೆಲ್ಲೂ ಇಲ್ಲ, ಮತ್ತು ಎರಡೂ ಹೋಸ್ಟ್ಗಳಿಗೆ ಹೊಂದುವ rsync ಆವೃತ್ತಿಗಳಿವೆ. ಈ ಪೂರ್ವಷರತ್ತುಗಳು ಸಣ್ಣ ಯೋಜನಾ ತಪ್ಪು ಅನುಮತಿ ಘಟನೆಯಾಗುವುದನ್ನು ತಡೆಯುತ್ತವೆ. ಏನಾದರೂ ತಪ್ಪಾದರೆ ಗಮ್ಯದ ಲಾಗ್ಗಳಲ್ಲಿ ಯಾವ ಖಾತೆ ಕಾಣುತ್ತದೆ ಎಂಬುದನ್ನೂ ಅವು ಹೇಳುತ್ತವೆ.

ಪ್ರತಿಯ ಮುನ್ನೋಟ ನೋಡಿ ವಿವರವಾದ ಪಟ್ಟಿ ಓದಿ

ಪ್ರತಿಯನ್ನು ಮೊದಲು ಮುನ್ನೋಟ ಧ್ವಜದೊಂದಿಗೆ ಚಲಾಯಿಸಿ ಮತ್ತು ಔಟ್ಪುಟ್ ಉಳಿಸಿ. ವಿವರವಾದ ಬದಲಾವಣೆಗಳು ಪ್ರತಿ ಮಾರ್ಗಕ್ಕೆ ಏನಾಗುತ್ತದೆ ಎಂದು ಹೇಳುತ್ತವೆ, ಇದು ನಂತರ ಬರುವ ಸಾರಾಂಶಕ್ಕಿಂತ ಹೆಚ್ಚು ಉಪಯುಕ್ತ. ಮುಂದಿನ ಸಲ ಚಲಾಯಿಸುವಾಗ ಹೋಲಿಸಲು ಏನಾದರೂ ಇರಲಿ ಎಂದು ಔಟ್ಪುಟ್ ಅನ್ನು ಬದಲಾವಣೆ ದಾಖಲೆಯಲ್ಲಿ ಇರಿಸಿ.

rsync -rt --dry-run --itemize-changes -e ssh -- /srv/publish/ [email protected]:/srv/mirror/

ಕೊನೆಯ ಓರೆ ಗೆರೆ ಮುಖ್ಯ. ಮೂಲದ ಬದಿಯಲ್ಲಿ ಅದು ಆ ಡೈರೆಕ್ಟರಿಯ ವಿಷಯವನ್ನು ಸೂಚಿಸುತ್ತದೆ, ಅದನ್ನು ಬಿಟ್ಟರೆ ಮೂಲದ ಹೆಸರಿನ ಹೆಚ್ಚುವರಿ ಡೈರೆಕ್ಟರಿ ಹಂತ ಸೇರುತ್ತದೆ. rsync ಕೈಪಿಡಿ ಎರಡೂ ರೂಪಗಳನ್ನು ಮೆಟಾಡೇಟಾ ಉಳಿಸುವ ಧ್ವಜಗಳೊಂದಿಗೆ ದಾಖಲಿಸುತ್ತದೆ, ಮತ್ತು ನಿಮಗೆ ಬೇಕಾದ ಆಯ್ಕೆಗಳ ಗುಂಪು ಅಭ್ಯಾಸವನ್ನಲ್ಲ, ಡೇಟಾವನ್ನು ಅವಲಂಬಿಸಿದೆ.

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

ನಂತರ ಅಳಿಸುವಿಕೆಗಳು ಪ್ರಯಾಣಿಸುತ್ತವೆಯೇ ಎಂದು ನಿರ್ಧರಿಸಿ

ಗಮ್ಯವನ್ನು ಕನ್ನಡಿಯಾಗಿಸುವುದು ಎರಡನೇ ನಿರ್ಣಯ, ಮೊದಲನೆಯ ಸುಧಾರಣೆಯಲ್ಲ. ಅದನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಮುನ್ನೋಟ ನೋಡಿ, ಅಳಿಸುವ ಧ್ವಜ ಸೇರಿಸಿ ಬೇರೆ ಏನನ್ನೂ ಬದಲಿಸದೆ, ಪಟ್ಟಿಯಲ್ಲಿನ ವ್ಯತ್ಯಾಸ ಸಂಪೂರ್ಣವಾಗಿ ಆ ನಿರ್ಣಯಕ್ಕೇ ಸೇರುವಂತೆ.

rsync -rt --delete --dry-run --itemize-changes -e ssh -- /srv/publish/ [email protected]:/srv/mirror/

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

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

ಎರಡು ಏಕಮುಖ ಕೆಲಸಗಳು ದ್ವಿಮುಖ ಸಿಂಕ್ ಆಗುವುದಿಲ್ಲ

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

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

ನೀತಿ ಬರೆದ ನಂತರವೇ ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸಿ

ನಿಗದಿತ ಕೆಲಸವು ದಿಕ್ಕು, ಮಾರ್ಗಗಳು, ಮೆಟಾಡೇಟಾ ನೀತಿ ಮತ್ತು ಅನುಮೋದಿತ ಅಳಿಸುವ ನಿರ್ಣಯವನ್ನು ಹೊತ್ತಿರಬೇಕು. ಈ ಐದು ಸತ್ಯಗಳನ್ನು ಕೆಲಸದ ಫೈಲ್ನಲ್ಲೇ ಇರಿಸಿ, ಮುಂದಿನ ನಿರ್ವಾಹಕರು ಎಂದಿಗೂ ಓದದಿರಬಹುದಾದ ವಿಕಿ ಪುಟದಲ್ಲಿ ಅಲ್ಲ. ಒಂದರ ಮೇಲೊಂದು ಬೀಳುವ ಚಲಾವಣೆಗಳನ್ನು ತಡೆಯಿರಿ, ಏಕೆಂದರೆ ಒಂದೇ ಮರಕ್ಕೆ ಒಂದೇ ಸಮಯದಲ್ಲಿ ಬರೆಯುವ ಎರಡು ಪ್ರತಿಗಳು ಯಾರೂ ಬಯಸದ ಸ್ಥಿತಿಯನ್ನು ಸೃಷ್ಟಿಸುತ್ತವೆ.

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

ಪೂರ್ಣಗೊಳಿಸುವಿಕೆ ಮತ್ತು ವೈಫಲ್ಯಗಳನ್ನು ದಾಖಲಿಸಿ, ಮತ್ತು ನಿರ್ಗಮನ ಕೋಡ್ ಮಾತ್ರವಲ್ಲ ಗಮ್ಯದಲ್ಲಿನ ಡೇಟಾಸೆಟ್ ಪರಿಶೀಲಿಸಿ. ಅಡಚಣೆಯ ನಂತರ VPN ಮರುಸ್ಥಾಪಿಸುವುದು ಸಂಪರ್ಕವನ್ನು ಮರಳಿಸುತ್ತದೆ; ಕೊನೆಯ ಪ್ರತಿ ಮುಗಿಯಿತೇ ಅಥವಾ ವಿರೋಧಾಭಾಸದ ಸಂಪಾದನೆಗಳು ಎಂದಾದರೂ ಪರಿಹಾರವಾದವೇ ಎಂದು ಅದು ಹೇಳುವುದಿಲ್ಲ.

ಸಂಬಂಧಿತ ಲೇಖನಗಳು