🥇ದೊಡ್ಡ ನೆಕ್ಸ್ಟ್‌ಕ್ಲೌಡ್ ಸ್ಟೋರೇಜ್‌ಗಳ ಬ್ಯಾಕ್‌ಅಪ್ ಮಾಡಲು GitLab ನಿಮಗೆ ಹೇಗೆ ಸಹಾಯ ಮಾಡುತ್ತದೆ

ಹಲೋ, ಹಬ್ರ್!

ನೆಕ್ಸ್ಟ್‌ಕ್ಲೌಡ್ ಸ್ಟೋರೇಜ್‌ಗಳಿಂದ ದೊಡ್ಡ ಡೇಟಾದ ಬ್ಯಾಕಪ್ ಅನ್ನು ವಿವಿಧ ಕಾನ್ಫಿಗರೇಶನ್‌ಗಳಲ್ಲಿ ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸುವಲ್ಲಿ ನಮ್ಮ ಅನುಭವದ ಬಗ್ಗೆ ಇಂದು ನಾನು ಮಾತನಾಡಲು ಬಯಸುತ್ತೇನೆ. ನಾನು ಮೊಲ್ನಿಯಾ ಎಕೆಯಲ್ಲಿ ಸೇವಾ ಕೇಂದ್ರವಾಗಿ ಕೆಲಸ ಮಾಡುತ್ತೇನೆ, ಅಲ್ಲಿ ನಾವು ಐಟಿ ಸಿಸ್ಟಮ್‌ಗಳ ಕಾನ್ಫಿಗರೇಶನ್ ನಿರ್ವಹಣೆಯನ್ನು ಮಾಡುತ್ತೇವೆ; ನೆಕ್ಸ್ಟ್‌ಕ್ಲೌಡ್ ಅನ್ನು ಡೇಟಾ ಸಂಗ್ರಹಣೆಗಾಗಿ ಬಳಸಲಾಗುತ್ತದೆ. ವಿತರಣಾ ರಚನೆಯೊಂದಿಗೆ, ಪುನರಾವರ್ತನೆಯೊಂದಿಗೆ ಸೇರಿದಂತೆ.

ಅನುಸ್ಥಾಪನೆಗಳ ವೈಶಿಷ್ಟ್ಯಗಳಿಂದ ಉಂಟಾಗುವ ಸಮಸ್ಯೆಗಳು ಬಹಳಷ್ಟು ಡೇಟಾ ಇವೆ. Nextcloud, ಪುನರುಕ್ತಿ, ವ್ಯಕ್ತಿನಿಷ್ಠ ಕಾರಣಗಳು ಮತ್ತು ಹೆಚ್ಚಿನವುಗಳಿಂದ ಒದಗಿಸಲಾದ ಆವೃತ್ತಿಯು ಅನೇಕ ನಕಲುಗಳನ್ನು ರಚಿಸುತ್ತದೆ.

ಪೂರ್ವೇತಿಹಾಸದ

ನೆಕ್ಸ್ಟ್‌ಕ್ಲೌಡ್ ಅನ್ನು ನಿರ್ವಹಿಸುವಾಗ, ಪರಿಣಾಮಕಾರಿ ಬ್ಯಾಕ್‌ಅಪ್ ಅನ್ನು ಸಂಘಟಿಸುವ ಸಮಸ್ಯೆ ಉದ್ಭವಿಸುತ್ತದೆ, ಡೇಟಾ ಮೌಲ್ಯಯುತವಾಗಿರುವುದರಿಂದ ಅದನ್ನು ಎನ್‌ಕ್ರಿಪ್ಟ್ ಮಾಡಬೇಕು.

ನಮ್ಮ ಸ್ಥಳದಲ್ಲಿ ಅಥವಾ ಗ್ರಾಹಕರ ಬಳಿ Nextcloud ನಿಂದ ಪ್ರತ್ಯೇಕ ಯಂತ್ರಗಳಲ್ಲಿ ಬ್ಯಾಕ್‌ಅಪ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸಲು ನಾವು ಆಯ್ಕೆಗಳನ್ನು ನೀಡುತ್ತೇವೆ, ಇದಕ್ಕೆ ಆಡಳಿತಕ್ಕೆ ಹೊಂದಿಕೊಳ್ಳುವ ಸ್ವಯಂಚಾಲಿತ ವಿಧಾನದ ಅಗತ್ಯವಿರುತ್ತದೆ.

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

ಮೊದಲಿಗೆ, ಇನ್ಪುಟ್ ಡೇಟಾವನ್ನು ನೋಡೋಣ. ನಮಗೆ ಅವಶ್ಯಕವಿದೆ:

ಒಂದು ನೋಡ್ ಅಥವಾ ಹಲವಾರು ವಿಷಯದಲ್ಲಿ ಸ್ಕೇಲೆಬಿಲಿಟಿ. ದೊಡ್ಡ ಅನುಸ್ಥಾಪನೆಗಳಿಗಾಗಿ ನಾವು minio ಅನ್ನು ಶೇಖರಣೆಯಾಗಿ ಬಳಸುತ್ತೇವೆ.
ಬ್ಯಾಕ್‌ಅಪ್‌ಗಳನ್ನು ನಿರ್ವಹಿಸುವಲ್ಲಿನ ಸಮಸ್ಯೆಗಳ ಬಗ್ಗೆ ತಿಳಿದುಕೊಳ್ಳಿ.
ನಿಮ್ಮ ಕ್ಲೈಂಟ್‌ಗಳೊಂದಿಗೆ ಮತ್ತು/ಅಥವಾ ನಮ್ಮೊಂದಿಗೆ ನೀವು ಬ್ಯಾಕಪ್ ಅನ್ನು ಇರಿಸಿಕೊಳ್ಳಬೇಕು.
ಸಮಸ್ಯೆಗಳನ್ನು ತ್ವರಿತವಾಗಿ ಮತ್ತು ಸುಲಭವಾಗಿ ನಿಭಾಯಿಸಿ.
ಗ್ರಾಹಕರು ಮತ್ತು ಅನುಸ್ಥಾಪನೆಗಳು ಪರಸ್ಪರ ವಿಭಿನ್ನವಾಗಿವೆ - ಏಕರೂಪತೆಯನ್ನು ಸಾಧಿಸಲಾಗುವುದಿಲ್ಲ.
ಎರಡು ಸನ್ನಿವೇಶಗಳಲ್ಲಿ ಚೇತರಿಕೆಯ ವೇಗವು ಕನಿಷ್ಠವಾಗಿರಬೇಕು: ಪೂರ್ಣ ಚೇತರಿಕೆ (ವಿಪತ್ತು), ಒಂದು ಫೋಲ್ಡರ್ ತಪ್ಪಾಗಿ ಅಳಿಸಲಾಗಿದೆ.
ಡೀಪ್ಲಿಕೇಶನ್ ಕಾರ್ಯದ ಅಗತ್ಯವಿದೆ.

ಬ್ಯಾಕ್‌ಅಪ್‌ಗಳನ್ನು ನಿರ್ವಹಿಸುವ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಲು, ನಾವು GitLab ಅನ್ನು ಸ್ಥಾಪಿಸಿದ್ದೇವೆ. ಟ್ಯಾಕ್ಲ್ ಮೂಲಕ ಹೆಚ್ಚಿನ ವಿವರಗಳು.

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

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

ಬ್ಯಾಕಪ್ ಪರಿಕರಗಳು

ಬ್ಯಾಕ್‌ಅಪ್ ರಚನೆಯ ಸಾಧನವನ್ನು ಆಯ್ಕೆ ಮಾಡುವ ಮೂಲಕ ನಾವು ಪರಿಹಾರ ವಿಧಾನಗಳಿಗಾಗಿ ನಮ್ಮ ಹುಡುಕಾಟವನ್ನು ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ.

ನಿಯಮಿತ ಟಾರ್ + ಜಿಜಿಪ್ ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವುದಿಲ್ಲ - ಡೇಟಾವನ್ನು ನಕಲು ಮಾಡಲಾಗಿದೆ. ಒಂದು ಹೆಚ್ಚಳವು ಸಾಮಾನ್ಯವಾಗಿ ಕೆಲವೇ ಕೆಲವು ನೈಜ ಬದಲಾವಣೆಗಳನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ ಮತ್ತು ಒಂದೇ ಫೈಲ್‌ನಲ್ಲಿ ಹೆಚ್ಚಿನ ಡೇಟಾ ಪುನರಾವರ್ತನೆಯಾಗುತ್ತದೆ.
ಮತ್ತೊಂದು ಸಮಸ್ಯೆ ಇದೆ - ವಿತರಿಸಿದ ಡೇಟಾ ಸಂಗ್ರಹಣೆಯ ಪುನರುಕ್ತಿ. ನಾವು ಮಿನಿಯೊವನ್ನು ಬಳಸುತ್ತೇವೆ ಮತ್ತು ಅದರ ಡೇಟಾ ಮೂಲಭೂತವಾಗಿ ಅನಗತ್ಯವಾಗಿರುತ್ತದೆ. ಅಥವಾ ನೀವು ಮಿನಿಯೊ ಮೂಲಕ ಬ್ಯಾಕಪ್ ಮಾಡಬೇಕಾಗಿತ್ತು - ಅದನ್ನು ಲೋಡ್ ಮಾಡಿ ಮತ್ತು ಫೈಲ್ ಸಿಸ್ಟಮ್ ನಡುವೆ ಎಲ್ಲಾ ಸ್ಪೇಸರ್ಗಳನ್ನು ಬಳಸಿ, ಮತ್ತು ಕಡಿಮೆ ಪ್ರಾಮುಖ್ಯತೆ ಇಲ್ಲ, ಕೆಲವು ಬಕೆಟ್ಗಳು ಮತ್ತು ಮೆಟಾ-ಮಾಹಿತಿಗಳ ಬಗ್ಗೆ ಮರೆತುಹೋಗುವ ಅಪಾಯವಿದೆ. ಅಥವಾ ಅಪಕರ್ಷಣೆಯನ್ನು ಬಳಸಿ.

ನಕಲು ಹೊಂದಿರುವ ಬ್ಯಾಕಪ್ ಪರಿಕರಗಳು ತೆರೆದ ಮೂಲದಲ್ಲಿ ಲಭ್ಯವಿವೆ (ಹಬ್ರೆಯಲ್ಲಿ ಇದ್ದವು ಲೇಖನಗಳು ಈ ಥೀಮ್ ಬಗ್ಗೆ) ಮತ್ತು ನಮ್ಮ ಅಂತಿಮ ಸ್ಪರ್ಧಿಗಳು ಬೋರ್ಗ್ и ರೆಸ್ಟಿಕ್. ಎರಡು ಅಪ್ಲಿಕೇಶನ್‌ಗಳ ನಮ್ಮ ಹೋಲಿಕೆ ಕೆಳಗೆ ಇದೆ, ಆದರೆ ಈಗ ನಾವು ಸಂಪೂರ್ಣ ಯೋಜನೆಯನ್ನು ಹೇಗೆ ಆಯೋಜಿಸಿದ್ದೇವೆ ಎಂದು ನಾವು ನಿಮಗೆ ಹೇಳುತ್ತೇವೆ.

ಬ್ಯಾಕ್‌ಅಪ್‌ಗಳನ್ನು ನಿರ್ವಹಿಸುವುದು

ಬೋರ್ಗ್ ಮತ್ತು ರೆಸ್ಟಿಕ್ ಒಳ್ಳೆಯದು, ಆದರೆ ಯಾವುದೇ ಉತ್ಪನ್ನವು ಕೇಂದ್ರೀಕೃತ ನಿಯಂತ್ರಣ ಕಾರ್ಯವಿಧಾನವನ್ನು ಹೊಂದಿಲ್ಲ. ನಿರ್ವಹಣೆ ಮತ್ತು ನಿಯಂತ್ರಣದ ಉದ್ದೇಶಕ್ಕಾಗಿ, ನಾವು ಈಗಾಗಲೇ ಕಾರ್ಯಗತಗೊಳಿಸಿದ ಸಾಧನವನ್ನು ಆಯ್ಕೆ ಮಾಡಿದ್ದೇವೆ, ಅದು ಇಲ್ಲದೆ ಯಾಂತ್ರೀಕೃತಗೊಂಡ ಸೇರಿದಂತೆ ನಮ್ಮ ಕೆಲಸವನ್ನು ನಾವು ಊಹಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ - ಇದು ಪ್ರಸಿದ್ಧ CI/CD - GitLab.

ಕಲ್ಪನೆಯು ಕೆಳಕಂಡಂತಿದೆ: ನೆಕ್ಸ್ಟ್‌ಕ್ಲೌಡ್ ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸುವ ಪ್ರತಿ ನೋಡ್‌ನಲ್ಲಿ ಗಿಟ್ಲ್ಯಾಬ್-ರನ್ನರ್ ಅನ್ನು ಸ್ಥಾಪಿಸಲಾಗಿದೆ. ರನ್ನರ್ ಬ್ಯಾಕಪ್ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುವ ವೇಳಾಪಟ್ಟಿಯಲ್ಲಿ ಸ್ಕ್ರಿಪ್ಟ್ ಅನ್ನು ರನ್ ಮಾಡುತ್ತದೆ ಮತ್ತು ಅದು ಬೋರ್ಗ್ ಅಥವಾ ರೆಸ್ಟಿಕ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸುತ್ತದೆ.

ನಮಗೆ ಏನು ಸಿಕ್ಕಿತು? ಮರಣದಂಡನೆಯಿಂದ ಪ್ರತಿಕ್ರಿಯೆ, ಬದಲಾವಣೆಗಳ ಮೇಲೆ ಅನುಕೂಲಕರ ನಿಯಂತ್ರಣ, ದೋಷದ ಸಂದರ್ಭದಲ್ಲಿ ವಿವರಗಳು.

ಇಲ್ಲಿ ಇಲ್ಲಿ GitHub ನಲ್ಲಿ ನಾವು ವಿವಿಧ ಕಾರ್ಯಗಳಿಗಾಗಿ ಸ್ಕ್ರಿಪ್ಟ್‌ನ ಉದಾಹರಣೆಗಳನ್ನು ಪೋಸ್ಟ್ ಮಾಡಿದ್ದೇವೆ ಮತ್ತು ನಾವು ಅದನ್ನು ನೆಕ್ಸ್ಟ್‌ಕ್ಲೌಡ್‌ನ ಬ್ಯಾಕ್‌ಅಪ್‌ಗೆ ಲಗತ್ತಿಸುವುದನ್ನು ಕೊನೆಗೊಳಿಸಿದ್ದೇವೆ, ಆದರೆ ಅನೇಕ ಇತರ ಸೇವೆಗಳು. ನೀವು ಅದನ್ನು ಹಸ್ತಚಾಲಿತವಾಗಿ ಕಾನ್ಫಿಗರ್ ಮಾಡಲು ಬಯಸದಿದ್ದರೆ (ಮತ್ತು ನಾವು ಬಯಸುವುದಿಲ್ಲ) ಮತ್ತು .gitlab-ci.yml ಅಲ್ಲಿ ಶೆಡ್ಯೂಲರ್ ಕೂಡ ಇದೆ

Gitlab API ನಲ್ಲಿ CI/CD ಸಮಯ ಮೀರುವಿಕೆಯನ್ನು ಬದಲಾಯಿಸಲು ಇನ್ನೂ ಯಾವುದೇ ಮಾರ್ಗವಿಲ್ಲ, ಆದರೆ ಇದು ಚಿಕ್ಕದಾಗಿದೆ. ಇದನ್ನು ಹೆಚ್ಚಿಸಬೇಕು, ಹೇಳಿ 1d.

GitLab, ಅದೃಷ್ಟವಶಾತ್, ಬದ್ಧತೆಯ ಪ್ರಕಾರ ಮಾತ್ರ ಪ್ರಾರಂಭಿಸಬಹುದು, ಆದರೆ ವೇಳಾಪಟ್ಟಿಯ ಪ್ರಕಾರ ಮಾತ್ರ, ಇದು ನಮಗೆ ಬೇಕಾಗಿರುವುದು.

ಈಗ ಹೊದಿಕೆಯ ಸ್ಕ್ರಿಪ್ಟ್ ಬಗ್ಗೆ.

ಈ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಾಗಿ ನಾವು ಈ ಕೆಳಗಿನ ಷರತ್ತುಗಳನ್ನು ಹೊಂದಿಸಿದ್ದೇವೆ:

ಇದನ್ನು ರನ್ನರ್ ಮತ್ತು ಕೈಯಿಂದ ಕನ್ಸೋಲ್‌ನಿಂದ ಒಂದೇ ರೀತಿಯ ಕ್ರಿಯಾತ್ಮಕತೆಯೊಂದಿಗೆ ಪ್ರಾರಂಭಿಸಬೇಕು.
ದೋಷ ನಿರ್ವಾಹಕರು ಇರಬೇಕು:
ರಿಟರ್ನ್ ಕೋಡ್.
ಲಾಗ್‌ನಲ್ಲಿ ಸ್ಟ್ರಿಂಗ್‌ಗಾಗಿ ಹುಡುಕಿ. ಉದಾಹರಣೆಗೆ, ನಮಗೆ ದೋಷವು ಪ್ರೋಗ್ರಾಂ ಮಾರಕವೆಂದು ಪರಿಗಣಿಸದ ಸಂದೇಶವಾಗಿರಬಹುದು.
ಪ್ರಕ್ರಿಯೆಯ ಅವಧಿ ಮೀರಿದೆ. ಪ್ರಮುಖ ಸಮಯವು ಸಮಂಜಸವಾಗಿರಬೇಕು.
ನಮಗೆ ಬಹಳ ವಿವರವಾದ ಲಾಗ್ ಅಗತ್ಯವಿದೆ. ಆದರೆ ದೋಷದ ಸಂದರ್ಭದಲ್ಲಿ ಮಾತ್ರ.
ಪ್ರಾರಂಭಿಸುವ ಮೊದಲು ಹಲವಾರು ಪರೀಕ್ಷೆಗಳನ್ನು ಸಹ ಕೈಗೊಳ್ಳಲಾಗುತ್ತದೆ.
ಬೆಂಬಲ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ನಾವು ಉಪಯುಕ್ತವೆಂದು ಕಂಡುಕೊಂಡ ಅನುಕೂಲಕ್ಕಾಗಿ ಸಣ್ಣ ಬೋನಸ್‌ಗಳು:
ಪ್ರಾರಂಭ ಮತ್ತು ಅಂತ್ಯವನ್ನು ಸ್ಥಳೀಯ ಯಂತ್ರದ ಸಿಸ್ಲಾಗ್‌ನಲ್ಲಿ ದಾಖಲಿಸಲಾಗಿದೆ. ಸಿಸ್ಟಮ್ ದೋಷಗಳು ಮತ್ತು ಬ್ಯಾಕಪ್ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ಸಂಪರ್ಕಿಸಲು ಇದು ಸಹಾಯ ಮಾಡುತ್ತದೆ.
ದೋಷ ಲಾಗ್‌ನ ಭಾಗ, ಯಾವುದಾದರೂ ಇದ್ದರೆ, stdout ಗೆ ಔಟ್‌ಪುಟ್ ಆಗಿದ್ದರೆ, ಸಂಪೂರ್ಣ ಲಾಗ್ ಅನ್ನು ಪ್ರತ್ಯೇಕ ಫೈಲ್‌ಗೆ ಬರೆಯಲಾಗುತ್ತದೆ. ಕ್ಷುಲ್ಲಕವಾಗಿದ್ದರೆ ತಕ್ಷಣವೇ CI ಅನ್ನು ನೋಡಲು ಮತ್ತು ದೋಷವನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡಲು ಅನುಕೂಲಕರವಾಗಿದೆ.
ಡೀಬಗ್ ಮಾಡುವ ವಿಧಾನಗಳು.

ಪೂರ್ಣ ಲಾಗ್ ಅನ್ನು GitLab ನಲ್ಲಿ ಕಲಾಕೃತಿಯಾಗಿ ಉಳಿಸಲಾಗಿದೆ; ಯಾವುದೇ ದೋಷವಿಲ್ಲದಿದ್ದರೆ, ಲಾಗ್ ಅನ್ನು ಅಳಿಸಲಾಗುತ್ತದೆ. ನಾವು ಸ್ಕ್ರಿಪ್ಟ್ ಅನ್ನು ಬ್ಯಾಷ್‌ನಲ್ಲಿ ಬರೆಯುತ್ತೇವೆ.

ಮುಕ್ತ ಮೂಲಕ್ಕೆ ಸಂಬಂಧಿಸಿದಂತೆ ಯಾವುದೇ ಸಲಹೆಗಳು ಮತ್ತು ಕಾಮೆಂಟ್‌ಗಳನ್ನು ಪರಿಗಣಿಸಲು ನಾವು ಸಂತೋಷಪಡುತ್ತೇವೆ - ಸ್ವಾಗತ.

ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ

ಬ್ಯಾಷ್ ಎಕ್ಸಿಕ್ಯೂಟರ್ ಹೊಂದಿರುವ ರನ್ನರ್ ಅನ್ನು ಬ್ಯಾಕಪ್ ನೋಡ್‌ನಲ್ಲಿ ಪ್ರಾರಂಭಿಸಲಾಗಿದೆ. ಶೆಡ್ಯೂಲರ್ ಪ್ರಕಾರ, ಉದ್ಯೋಗ CI/CD ಅನ್ನು ವಿಶೇಷ ಟರ್ನಿಪ್‌ನಲ್ಲಿ ಪ್ರಾರಂಭಿಸಲಾಗಿದೆ. ರನ್ನರ್ ಅಂತಹ ಕಾರ್ಯಗಳಿಗಾಗಿ ಸಾರ್ವತ್ರಿಕ ಹೊದಿಕೆಯ ಸ್ಕ್ರಿಪ್ಟ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸುತ್ತಾನೆ, ಇದು ಬ್ಯಾಕ್ಅಪ್ ರೆಪೊಸಿಟರಿ, ಮೌಂಟ್ ಪಾಯಿಂಟ್ಗಳು ಮತ್ತು ನಮಗೆ ಬೇಕಾದ ಎಲ್ಲವನ್ನೂ ಪರಿಶೀಲಿಸುತ್ತದೆ, ನಂತರ ಬ್ಯಾಕ್ಅಪ್ ಮಾಡಿ ಮತ್ತು ಹಳೆಯದನ್ನು ಸ್ವಚ್ಛಗೊಳಿಸುತ್ತದೆ. ಮುಗಿದ ಬ್ಯಾಕಪ್ ಅನ್ನು S3 ಗೆ ಕಳುಹಿಸಲಾಗುತ್ತದೆ.

ನಾವು ಈ ಯೋಜನೆಯ ಪ್ರಕಾರ ಕೆಲಸ ಮಾಡುತ್ತೇವೆ - ಇದು ಬಾಹ್ಯ AWS ಪೂರೈಕೆದಾರ ಅಥವಾ ರಷ್ಯಾದ ಸಮಾನವಾಗಿದೆ (ಇದು ವೇಗವಾಗಿರುತ್ತದೆ ಮತ್ತು ಡೇಟಾವು ರಷ್ಯಾದ ಒಕ್ಕೂಟವನ್ನು ಬಿಡುವುದಿಲ್ಲ). ಅಥವಾ ಈ ಉದ್ದೇಶಗಳಿಗಾಗಿ ನಾವು ಕ್ಲೈಂಟ್‌ಗಾಗಿ ಅವರ ಸೈಟ್‌ನಲ್ಲಿ ಪ್ರತ್ಯೇಕ ಮಿನಿಯೊ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಸ್ಥಾಪಿಸುತ್ತೇವೆ. ನಾವು ಸಾಮಾನ್ಯವಾಗಿ ಭದ್ರತಾ ಕಾರಣಗಳಿಗಾಗಿ ಇದನ್ನು ಮಾಡುತ್ತೇವೆ, ಕ್ಲೈಂಟ್ ಡೇಟಾವು ಅವರ ಸರ್ಕ್ಯೂಟ್ ಅನ್ನು ಬಿಡಲು ಬಯಸದಿದ್ದಾಗ.

ನಾವು ssh ಮೂಲಕ ಬ್ಯಾಕಪ್ ಕಳುಹಿಸುವ ವೈಶಿಷ್ಟ್ಯವನ್ನು ಬಳಸಲಿಲ್ಲ. ಇದು ಭದ್ರತೆಯನ್ನು ಸೇರಿಸುವುದಿಲ್ಲ ಮತ್ತು S3 ಪೂರೈಕೆದಾರರ ನೆಟ್‌ವರ್ಕ್ ಸಾಮರ್ಥ್ಯಗಳು ನಮ್ಮ ಒಂದು ssh ಯಂತ್ರಕ್ಕಿಂತ ಹೆಚ್ಚಾಗಿರುತ್ತದೆ.

ನಿಮ್ಮ ಸ್ಥಳೀಯ ಯಂತ್ರವನ್ನು ಹ್ಯಾಕರ್‌ನಿಂದ ರಕ್ಷಿಸಲು, ಅವರು S3 ನಲ್ಲಿ ಡೇಟಾವನ್ನು ಅಳಿಸಬಹುದು, ನೀವು ಆವೃತ್ತಿಯನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಬೇಕು.
ಬ್ಯಾಕಪ್ ಯಾವಾಗಲೂ ಬ್ಯಾಕಪ್ ಅನ್ನು ಎನ್‌ಕ್ರಿಪ್ಟ್ ಮಾಡುತ್ತದೆ.

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

ಪ್ರತ್ಯೇಕ ಶೆಡ್ಯೂಲರ್ ಸೂಚ್ಯಂಕಗಳು ಮತ್ತು ವಿಷಯದ ಸಮಗ್ರತೆಗಾಗಿ ಬ್ಯಾಕಪ್‌ಗಳನ್ನು ಪರಿಶೀಲಿಸುತ್ತದೆ. ಚೆಕ್ ನಿಧಾನ ಮತ್ತು ಉದ್ದವಾಗಿದೆ, ಆದ್ದರಿಂದ ನಾವು ಅದನ್ನು ತಿಂಗಳಿಗೊಮ್ಮೆ ಪ್ರತ್ಯೇಕವಾಗಿ ನಡೆಸುತ್ತೇವೆ. ಇದು ಹಲವಾರು ದಿನಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳಬಹುದು.

ರಷ್ಯನ್ ಭಾಷೆಯಲ್ಲಿ ಓದಿ

ಮುಖ್ಯ ಕಾರ್ಯಗಳು

prepare ಸಿದ್ಧತೆ
testcheck ಸಿದ್ಧತೆ ಪರಿಶೀಲನೆ
maincommand ಕೋರ್ ತಂಡ
forcepostscript ಒಂದು ಕಾರ್ಯವನ್ನು ಕೊನೆಯಲ್ಲಿ ಅಥವಾ ದೋಷದಿಂದ ಕಾರ್ಯಗತಗೊಳಿಸಲಾಗುತ್ತದೆ. ವಿಭಾಗವನ್ನು ಅನ್ಮೌಂಟ್ ಮಾಡಲು ನಾವು ಅದನ್ನು ಬಳಸುತ್ತೇವೆ.

ಸೇವಾ ಕಾರ್ಯಗಳು

cleanup ನಾವು ದೋಷಗಳನ್ನು ದಾಖಲಿಸುತ್ತೇವೆ ಅಥವಾ ಲಾಗ್ ಫೈಲ್ ಅನ್ನು ಅಳಿಸುತ್ತೇವೆ.
checklog ದೋಷದೊಂದಿಗೆ ಸಾಲಿನ ಸಂಭವಕ್ಕಾಗಿ ಲಾಗ್ ಅನ್ನು ಪಾರ್ಸ್ ಮಾಡಿ.
ret ನಿರ್ಗಮನ ನಿರ್ವಾಹಕ.
checktimeout ಸಮಯ ಮೀರಿದೆ ಎಂದು ಪರಿಶೀಲಿಸಿ.

ಪರಿಸರ

VERBOSE=1 ನಾವು ತಕ್ಷಣ ಪರದೆಯ ಮೇಲೆ ದೋಷಗಳನ್ನು ಪ್ರದರ್ಶಿಸುತ್ತೇವೆ (stdout).
SAVELOGSONSUCCES=1 ಯಶಸ್ಸಿನ ಮೇಲೆ ಲಾಗ್ ಅನ್ನು ಉಳಿಸಿ.
INIT_REPO_IF_NOT_EXIST=1 ಅದು ಅಸ್ತಿತ್ವದಲ್ಲಿಲ್ಲದಿದ್ದರೆ ರೆಪೊಸಿಟರಿಯನ್ನು ರಚಿಸಿ. ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಲಾಗಿದೆ.
TIMEOUT ಮುಖ್ಯ ಕಾರ್ಯಾಚರಣೆಗೆ ಗರಿಷ್ಠ ಸಮಯ. ನೀವು ಅದನ್ನು ಕೊನೆಯಲ್ಲಿ 'm', 'h' ಅಥವಾ 'd' ಎಂದು ಹೊಂದಿಸಬಹುದು.

ಹಳೆಯ ಪ್ರತಿಗಳಿಗೆ ಶೇಖರಣಾ ಮೋಡ್. ಡೀಫಾಲ್ಟ್:

KEEP_DAILY=7
KEEP_WEEKLY=4
KEEP_MONTHLY=6

ಸ್ಕ್ರಿಪ್ಟ್ ಒಳಗೆ ಅಸ್ಥಿರ

ERROR_STRING - ದೋಷಕ್ಕಾಗಿ ಚೆಕ್ ಇನ್ ಲಾಗ್‌ಗಾಗಿ ಸ್ಟ್ರಿಂಗ್.
EXTRACT_ERROR_STRING - ದೋಷದ ವೇಳೆ ಶೋ ಸ್ಟ್ರಿಂಗ್‌ಗಾಗಿ ಅಭಿವ್ಯಕ್ತಿ.
KILL_TIMEOUT_SIGNAL - ಸಮಯ ಮೀರಿದರೆ ಕೊಲ್ಲುವ ಸಂಕೇತ.
TAIL - ಪರದೆಯ ಮೇಲೆ ದೋಷಗಳೊಂದಿಗೆ ಎಷ್ಟು ತಂತಿಗಳು.
COLORMSG - ಸಂದೇಶದ ಬಣ್ಣ (ಡೀಫಾಲ್ಟ್ ಹಳದಿ).

ವರ್ಡ್ಪ್ರೆಸ್ ಎಂದು ಕರೆಯಲ್ಪಡುವ ಆ ಸ್ಕ್ರಿಪ್ಟ್ ಷರತ್ತುಬದ್ಧ ಹೆಸರನ್ನು ಹೊಂದಿದೆ, ಅದರ ತಂತ್ರವೆಂದರೆ ಅದು mysql ಡೇಟಾಬೇಸ್ ಅನ್ನು ಸಹ ಬ್ಯಾಕಪ್ ಮಾಡುತ್ತದೆ. ಇದರರ್ಥ ಇದನ್ನು ಸಿಂಗಲ್-ನೋಡ್ ನೆಕ್ಸ್‌ಕ್ಲೌಡ್ ಸ್ಥಾಪನೆಗಳಿಗಾಗಿ ಬಳಸಬಹುದು, ಅಲ್ಲಿ ನೀವು ಡೇಟಾಬೇಸ್ ಅನ್ನು ಸಹ ಬ್ಯಾಕಪ್ ಮಾಡಬಹುದು. ಅನುಕೂಲವೆಂದರೆ ಎಲ್ಲವೂ ಒಂದೇ ಸ್ಥಳದಲ್ಲಿರುವುದು ಮಾತ್ರವಲ್ಲ, ಡೇಟಾಬೇಸ್‌ನ ವಿಷಯಗಳು ಫೈಲ್‌ಗಳ ವಿಷಯಗಳಿಗೆ ಹತ್ತಿರದಲ್ಲಿವೆ, ಏಕೆಂದರೆ ಸಮಯದ ವ್ಯತ್ಯಾಸವು ಕಡಿಮೆಯಾಗಿದೆ.

ರೆಸ್ಟಿಕ್ ವಿರುದ್ಧ ಬೋರ್ಗ್

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

ನಮ್ಮ ಆಯ್ಕೆಯ ಮಾನದಂಡಗಳು, ಈಗಾಗಲೇ ಉಲ್ಲೇಖಿಸಿರುವವುಗಳ ಜೊತೆಗೆ (ಡಪ್ಲಿಕೇಶನ್, ತ್ವರಿತ ಚೇತರಿಕೆ, ಇತ್ಯಾದಿ):

ಅಪೂರ್ಣ ಕೆಲಸಕ್ಕೆ ಪ್ರತಿರೋಧ. ಕೊಲ್ಲಲು ಪರಿಶೀಲಿಸಿ -9.
ಡಿಸ್ಕ್ನಲ್ಲಿ ಗಾತ್ರ.
ಸಂಪನ್ಮೂಲಗಳ ಅವಶ್ಯಕತೆ (CPU, ಮೆಮೊರಿ).
ಸಂಗ್ರಹಿಸಲಾದ ಬ್ಲಾಬ್‌ಗಳ ಗಾತ್ರ.
S3 ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲಾಗುತ್ತಿದೆ.
ಸಮಗ್ರತೆಯ ಪರಿಶೀಲನೆ.

ಪರೀಕ್ಷೆಗಾಗಿ, ನಾವು ನೈಜ ಡೇಟಾ ಮತ್ತು ಒಟ್ಟು 1,6 TB ಗಾತ್ರದೊಂದಿಗೆ ಒಂದು ಕ್ಲೈಂಟ್ ಅನ್ನು ತೆಗೆದುಕೊಂಡಿದ್ದೇವೆ.
ಷರತ್ತುಗಳು.

S3 ನೊಂದಿಗೆ ನೇರವಾಗಿ ಕೆಲಸ ಮಾಡುವುದು ಹೇಗೆ ಎಂದು ಬೋರ್ಗ್ಗೆ ತಿಳಿದಿಲ್ಲ, ಮತ್ತು ನಾವು ಡಿಸ್ಕ್ ಅನ್ನು ಫ್ಯೂಸ್ ಆಗಿ ಅಳವಡಿಸಿದ್ದೇವೆ ಅವಿವೇಕಿಗಳು. ರೆಸ್ಟಿಕ್ ಅದನ್ನು S3 ಗೆ ಕಳುಹಿಸಿದೆ.

ಗೂಫಿಗಳು ಬಹಳ ಬೇಗನೆ ಮತ್ತು ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ, ಮತ್ತು ಇವೆ ಡಿಸ್ಕ್ ಸಂಗ್ರಹ ಮಾಡ್ಯೂಲ್, ಇದು ಕೆಲಸವನ್ನು ಇನ್ನಷ್ಟು ವೇಗಗೊಳಿಸುತ್ತದೆ. ಇದು ಬೀಟಾ ಹಂತದಲ್ಲಿದೆ ಮತ್ತು, ನಾನೂ, ಪರೀಕ್ಷೆಗಳ ಸಮಯದಲ್ಲಿ (ಇತರರು) ಡೇಟಾ ನಷ್ಟದೊಂದಿಗೆ ನಾವು ಕ್ರ್ಯಾಶ್ ಆಗಿದ್ದೇವೆ. ಆದರೆ ಅನುಕೂಲವೆಂದರೆ ಬ್ಯಾಕ್‌ಅಪ್ ಕಾರ್ಯವಿಧಾನವು ಹೆಚ್ಚು ಓದುವ ಅಗತ್ಯವಿಲ್ಲ, ಆದರೆ ಹೆಚ್ಚಾಗಿ ಬರೆಯುವುದು, ಆದ್ದರಿಂದ ನಾವು ಸಮಗ್ರತೆಯ ಪರಿಶೀಲನೆಯ ಸಮಯದಲ್ಲಿ ಮಾತ್ರ ಸಂಗ್ರಹವನ್ನು ಬಳಸುತ್ತೇವೆ.

ನೆಟ್ವರ್ಕ್ನ ಪ್ರಭಾವವನ್ನು ಕಡಿಮೆ ಮಾಡಲು, ನಾವು ಸ್ಥಳೀಯ ಪೂರೈಕೆದಾರರನ್ನು ಬಳಸಿದ್ದೇವೆ - ಯಾಂಡೆಕ್ಸ್ ಮೇಘ.

ಹೋಲಿಕೆ ಪರೀಕ್ಷೆಯ ಫಲಿತಾಂಶಗಳು.

ಮತ್ತಷ್ಟು ಪುನರಾರಂಭದೊಂದಿಗೆ ಕಿಲ್ -9 ಎರಡೂ ಯಶಸ್ವಿಯಾಗಿವೆ.
ಡಿಸ್ಕ್ನಲ್ಲಿ ಗಾತ್ರ. ಬೋರ್ಗ್ ಸಂಕುಚಿತಗೊಳಿಸಬಹುದು, ಆದ್ದರಿಂದ ಫಲಿತಾಂಶಗಳು ನಿರೀಕ್ಷೆಯಂತೆ ಇರುತ್ತವೆ.

ಬ್ಯಾಕ್ಅಪರ್
ಗಾತ್ರ

ಬೋರ್ಗ್
562Gb

ರೆಸ್ಟಿಕ್
628Gb

CPU ಮೂಲಕ
ಬೋರ್ಗ್ ಸ್ವತಃ ಡೀಫಾಲ್ಟ್ ಕಂಪ್ರೆಷನ್‌ನೊಂದಿಗೆ ಸ್ವಲ್ಪವೇ ಬಳಸುತ್ತದೆ, ಆದರೆ ಅದನ್ನು ಗೂಫಿಸ್ ಪ್ರಕ್ರಿಯೆಯೊಂದಿಗೆ ಮೌಲ್ಯಮಾಪನ ಮಾಡಬೇಕು. ಒಟ್ಟಾರೆಯಾಗಿ, ಅವುಗಳನ್ನು ಹೋಲಿಸಬಹುದಾಗಿದೆ ಮತ್ತು ಅದೇ ಪರೀಕ್ಷಾ ವರ್ಚುವಲ್ ಗಣಕದಲ್ಲಿ ಸುಮಾರು 1,2 ಕೋರ್‌ಗಳನ್ನು ಬಳಸಿಕೊಳ್ಳುತ್ತವೆ.
ಸ್ಮರಣೆ. ರೆಸ್ಟಿಕ್ ಸರಿಸುಮಾರು 0,5GB, ಬೋರ್ಗ್ ಸರಿಸುಮಾರು 200MB. ಆದರೆ ಸಿಸ್ಟಮ್ ಫೈಲ್ ಸಂಗ್ರಹಕ್ಕೆ ಹೋಲಿಸಿದರೆ ಇದು ಅತ್ಯಲ್ಪವಾಗಿದೆ. ಆದ್ದರಿಂದ ಹೆಚ್ಚಿನ ಮೆಮೊರಿಯನ್ನು ನಿಯೋಜಿಸಲು ಸಲಹೆ ನೀಡಲಾಗುತ್ತದೆ.
ಆಕೃತಿಯ ಗಾತ್ರದಲ್ಲಿನ ವ್ಯತ್ಯಾಸವು ಗಮನಾರ್ಹವಾಗಿದೆ.

ಬ್ಯಾಕ್ಅಪರ್
ಗಾತ್ರ

ಬೋರ್ಗ್
ಸುಮಾರು 500MB

ರೆಸ್ಟಿಕ್
ಸುಮಾರು 5MB

Restic ನ S3 ಅನುಭವವು ಅತ್ಯುತ್ತಮವಾಗಿದೆ. ಗೂಫಿಗಳ ಮೂಲಕ ಬೋರ್ಗ್‌ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವುದು ಯಾವುದೇ ಪ್ರಶ್ನೆಗಳನ್ನು ಹುಟ್ಟುಹಾಕುವುದಿಲ್ಲ, ಆದರೆ ಸಂಗ್ರಹವನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಮರುಹೊಂದಿಸಲು ಬ್ಯಾಕಪ್ ಪೂರ್ಣಗೊಂಡ ನಂತರ umount ಮಾಡಲು ಸಲಹೆ ನೀಡಲಾಗುತ್ತದೆ ಎಂದು ಗಮನಿಸಲಾಗಿದೆ. S3 ನ ವಿಶಿಷ್ಟತೆಯೆಂದರೆ ಅಂಡರ್-ಪಂಪ್ ಮಾಡಿದ ಭಾಗಗಳನ್ನು ಎಂದಿಗೂ ಬಕೆಟ್‌ಗೆ ಕಳುಹಿಸಲಾಗುವುದಿಲ್ಲ, ಅಂದರೆ ಅಪೂರ್ಣವಾಗಿ ತುಂಬಿದ ಡೇಟಾವು ದೊಡ್ಡ ಹಾನಿಗೆ ಕಾರಣವಾಗುತ್ತದೆ.
ಸಮಗ್ರತೆಯ ಪರಿಶೀಲನೆಯು ಎರಡೂ ಸಂದರ್ಭಗಳಲ್ಲಿ ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ, ಆದರೆ ವೇಗವು ಗಮನಾರ್ಹವಾಗಿ ಭಿನ್ನವಾಗಿರುತ್ತದೆ.
ರೆಸ್ಟಿಕ್ 3,5 ಗಂಟೆಗಳ.
ಬೋರ್ಗ್, 100GB SSD ಫೈಲ್ ಸಂಗ್ರಹದೊಂದಿಗೆ - 5 ಗಂಟೆಗಳಡೇಟಾ ಸ್ಥಳೀಯ ಡಿಸ್ಕ್‌ನಲ್ಲಿದ್ದರೆ ಸರಿಸುಮಾರು ಅದೇ ವೇಗದ ಫಲಿತಾಂಶ.
Borg ಸಂಗ್ರಹವಿಲ್ಲದೆಯೇ S3 ನಿಂದ ನೇರವಾಗಿ ಓದುತ್ತದೆ 33 ಗಂಟೆಗಳ. ದೈತ್ಯಾಕಾರದ ಉದ್ದ.

ಬಾಟಮ್ ಲೈನ್ ಎಂದರೆ ಬೋರ್ಗ್ ಸಂಕುಚಿತಗೊಳಿಸಬಹುದು ಮತ್ತು ದೊಡ್ಡ ಬ್ಲಾಬ್‌ಗಳನ್ನು ಹೊಂದಬಹುದು - ಇದು S3 ನಲ್ಲಿ ಸಂಗ್ರಹಣೆ ಮತ್ತು GET/PUT ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ಅಗ್ಗವಾಗಿಸುತ್ತದೆ. ಆದರೆ ಇದು ಹೆಚ್ಚು ಸಂಕೀರ್ಣ ಮತ್ತು ನಿಧಾನವಾದ ಪರಿಶೀಲನೆಯ ವೆಚ್ಚದಲ್ಲಿ ಬರುತ್ತದೆ. ಚೇತರಿಕೆಯ ವೇಗಕ್ಕೆ ಸಂಬಂಧಿಸಿದಂತೆ, ನಾವು ಯಾವುದೇ ವ್ಯತ್ಯಾಸವನ್ನು ಗಮನಿಸಲಿಲ್ಲ. ರೆಸ್ಟಿಕ್ ನಂತರದ ಬ್ಯಾಕಪ್‌ಗಳನ್ನು (ಮೊದಲನೆಯ ನಂತರ) ಸ್ವಲ್ಪ ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ, ಆದರೆ ಗಮನಾರ್ಹವಾಗಿ ಅಲ್ಲ.

ಆಯ್ಕೆಯಲ್ಲಿ ಕೊನೆಯದು ಆದರೆ ಸಮುದಾಯದ ಗಾತ್ರ.

ಮತ್ತು ನಾವು ಬೋರ್ಗ್ ಅನ್ನು ಆರಿಸಿದ್ದೇವೆ.

ಸಂಕೋಚನದ ಬಗ್ಗೆ ಕೆಲವು ಪದಗಳು

ಬೋರ್ಗ್ ತನ್ನ ಆರ್ಸೆನಲ್ - zstd ನಲ್ಲಿ ಅತ್ಯುತ್ತಮವಾದ ಹೊಸ ಸಂಕುಚಿತ ಅಲ್ಗಾರಿದಮ್ ಅನ್ನು ಹೊಂದಿದೆ. ಸಂಕೋಚನ ಗುಣಮಟ್ಟವು gzip ಗಿಂತ ಕೆಟ್ಟದ್ದಲ್ಲ, ಆದರೆ ಹೆಚ್ಚು ವೇಗವಾಗಿರುತ್ತದೆ. ಮತ್ತು ಡೀಫಾಲ್ಟ್ lz4 ಗೆ ವೇಗದಲ್ಲಿ ಹೋಲಿಸಬಹುದು.

ಉದಾಹರಣೆಗೆ, MySQL ಡೇಟಾಬೇಸ್ ಡಂಪ್ ಅನ್ನು ಅದೇ ವೇಗದಲ್ಲಿ lz4 ಗಿಂತ ಎರಡು ಪಟ್ಟು ಉತ್ತಮವಾಗಿ ಸಂಕುಚಿತಗೊಳಿಸಲಾಗುತ್ತದೆ. ಆದಾಗ್ಯೂ, ನೈಜ ಡೇಟಾದೊಂದಿಗಿನ ಅನುಭವವು ನೆಕ್ಸ್ಟ್‌ಕ್ಲೌಡ್ ನೋಡ್‌ನ ಸಂಕೋಚನ ಅನುಪಾತದಲ್ಲಿ ಬಹಳ ಕಡಿಮೆ ವ್ಯತ್ಯಾಸವಿದೆ ಎಂದು ತೋರಿಸುತ್ತದೆ.

ಬೋರ್ಗ್ ಬೋನಸ್ ಕಂಪ್ರೆಷನ್ ಮೋಡ್ ಅನ್ನು ಹೊಂದಿದೆ - ಫೈಲ್ ಹೆಚ್ಚಿನ ಎಂಟ್ರೊಪಿಯನ್ನು ಹೊಂದಿದ್ದರೆ, ನಂತರ ಸಂಕೋಚನವನ್ನು ಅನ್ವಯಿಸುವುದಿಲ್ಲ, ಅದು ವೇಗವನ್ನು ಹೆಚ್ಚಿಸುತ್ತದೆ. ರಚಿಸುವಾಗ ಆಯ್ಕೆಯಿಂದ ಸಕ್ರಿಯಗೊಳಿಸಲಾಗಿದೆ
-C auto,zstd
zstd ಅಲ್ಗಾರಿದಮ್‌ಗಾಗಿ
ಆದ್ದರಿಂದ ಈ ಆಯ್ಕೆಯೊಂದಿಗೆ, ಡೀಫಾಲ್ಟ್ ಕಂಪ್ರೆಷನ್‌ಗೆ ಹೋಲಿಸಿದರೆ, ನಾವು ಪಡೆದುಕೊಂಡಿದ್ದೇವೆ
ಕ್ರಮವಾಗಿ 560Gb ಮತ್ತು 562Gb. ಮೇಲಿನ ಉದಾಹರಣೆಯಿಂದ ಡೇಟಾ, ನಾನು ನಿಮಗೆ ನೆನಪಿಸುತ್ತೇನೆ, ಸಂಕೋಚನವಿಲ್ಲದೆ ಫಲಿತಾಂಶವು 628Gb ಆಗಿದೆ. 2GB ವ್ಯತ್ಯಾಸದ ಫಲಿತಾಂಶವು ನಮಗೆ ಸ್ವಲ್ಪ ಆಶ್ಚರ್ಯವನ್ನುಂಟುಮಾಡಿತು, ಆದರೆ ನಾವು ಅದನ್ನು ಆಯ್ಕೆ ಮಾಡುತ್ತೇವೆ ಎಂದು ನಾವು ಭಾವಿಸಿದ್ದೇವೆ. auto,zstd.

ಬ್ಯಾಕಪ್ ಪರಿಶೀಲನೆ ವಿಧಾನ

ಶೆಡ್ಯೂಲರ್ ಪ್ರಕಾರ, ವರ್ಚುವಲ್ ಯಂತ್ರವನ್ನು ನೇರವಾಗಿ ಪೂರೈಕೆದಾರರಿಂದ ಅಥವಾ ಕ್ಲೈಂಟ್‌ನಿಂದ ಪ್ರಾರಂಭಿಸಲಾಗುತ್ತದೆ, ಇದು ನೆಟ್‌ವರ್ಕ್ ಲೋಡ್ ಅನ್ನು ಹೆಚ್ಚು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ. ಕನಿಷ್ಠ ಅದನ್ನು ನೀವೇ ಹೆಚ್ಚಿಸುವುದಕ್ಕಿಂತ ಮತ್ತು ಸಂಚಾರವನ್ನು ಚಾಲನೆ ಮಾಡುವುದಕ್ಕಿಂತ ಅಗ್ಗವಾಗಿದೆ.

goofys --cache "--free:5%:/mnt/cache" -o allow_other --endpoint https://storage.yandexcloud.net --file-mode=0666 --dir-mode=0777 xxxxxxx.com /mnt/goofys
export BORG_PASSCOMMAND="cat /home/borg/.borg-passphrase"
borg list /mnt/goofys/borg1/
borg check --debug -p --verify-data /mnt/goofys/borg1/

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

ವಿಭಿನ್ನ ಟ್ಯಾಗ್‌ಗಳೊಂದಿಗೆ ವಿಭಿನ್ನ ನೋಡ್‌ಗಳಲ್ಲಿ ರನ್ನರ್‌ಗಳನ್ನು ಚಲಾಯಿಸುವ ಮೂಲಕ ಸ್ಕೇಲೆಬಿಲಿಟಿ ಸಾಧಿಸಲಾಗುತ್ತದೆ.
ನಮ್ಮ ಮೇಲ್ವಿಚಾರಣೆಯು ಒಂದು ವಿಂಡೋದಲ್ಲಿ GitLab API ಮೂಲಕ ಬ್ಯಾಕಪ್ ಸ್ಥಿತಿಗಳನ್ನು ಸಂಗ್ರಹಿಸುತ್ತದೆ; ಅಗತ್ಯವಿದ್ದರೆ, ಸಮಸ್ಯೆಗಳನ್ನು ಸುಲಭವಾಗಿ ಗಮನಿಸಬಹುದು ಮತ್ತು ಸುಲಭವಾಗಿ ಸ್ಥಳೀಕರಿಸಲಾಗುತ್ತದೆ.

ತೀರ್ಮಾನಕ್ಕೆ

ಪರಿಣಾಮವಾಗಿ, ನಾವು ಬ್ಯಾಕ್‌ಅಪ್‌ಗಳನ್ನು ಮಾಡುತ್ತೇವೆ, ನಮ್ಮ ಬ್ಯಾಕ್‌ಅಪ್‌ಗಳು ಮಾನ್ಯವಾಗಿರುತ್ತವೆ, ಅವರೊಂದಿಗೆ ಉದ್ಭವಿಸುವ ಸಮಸ್ಯೆಗಳು ಸ್ವಲ್ಪ ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುತ್ತವೆ ಮತ್ತು ಕರ್ತವ್ಯ ನಿರ್ವಾಹಕರ ಮಟ್ಟದಲ್ಲಿ ಪರಿಹರಿಸಲ್ಪಡುತ್ತವೆ ಎಂದು ನಮಗೆ ಖಚಿತವಾಗಿ ತಿಳಿದಿದೆ. tar.gz ಅಥವಾ Bacula ಗೆ ಹೋಲಿಸಿದರೆ ಬ್ಯಾಕಪ್‌ಗಳು ಕಡಿಮೆ ಜಾಗವನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತವೆ.

ಮೂಲ: www.habr.com

ದೊಡ್ಡ NextCloud ಸಂಗ್ರಹಣೆಗಳನ್ನು ಬ್ಯಾಕಪ್ ಮಾಡಲು GitLab ನಿಮಗೆ ಹೇಗೆ ಸಹಾಯ ಮಾಡುತ್ತದೆ