প্রতিটি ডেটাবেস অ্যাডমিনিস্ট্রেটর (DBA) এবং সিস্টেমস ইঞ্জিনিয়ার তাদের কর্মজীবনের কোনো না কোনো সময়ে ডেটাবেস ব্যাকআপ নেওয়ার জন্য একটি কাস্টম শেল স্ক্রিপ্ট লিখেছেন। এটি কার্যত একটি দীক্ষা বা রীতির মতো। প্রকল্পের প্রাথমিক পর্যায়ে, gzip-এ পাইপ করা mysqldump বা pg_dump চালানো একটি সাধারণ ক্রন জব (cron job) বেশ মার্জিত, হালকা এবং সাশ্রয়ী সমাধান বলে মনে হয়।
যাইহোক, পরিকাঠামো বড় হওয়ার সাথে সাথে, ডেটার পরিমাণ বৃদ্ধি পায় এবং আপটাইম এসএলএ (SLA) আরও কঠোর হয়ে ওঠে, তখন সেই ১০ লাইনের ব্যাশ (Bash) স্ক্রিপ্টটি নীরবে একটি টাইম বোমায় পরিণত হয়। প্রোডাকশন এনভায়রনমেন্টে উচ্চ প্রাপ্যতা (High Availability), কঠোর রিকভারি পয়েন্ট অবজেক্টিভস (RPO) এবং দ্রুত রিকভারি টাইম অবজেক্টিভস (RTO) প্রয়োজন হয়। এই পরিবেশে ডিআইওয়াই (DIY) ব্যাকআপ স্ক্রিপ্টের ওপর নির্ভর করা ডেটা কনসিস্টেন্সি, নীরব ব্যর্থতা, নিরাপত্তার দুর্বলতা এবং অগোছালো রিকভারি প্রক্রিয়ার মতো মারাত্মক ঝুঁকি তৈরি করে।
এই নিবন্ধে, আমরা ডিআইওয়াই ডেটাবেস ব্যাকআপ স্ক্রিপ্টের স্থাপত্যগত ত্রুটি এবং লুকানো বিপদগুলো বিশ্লেষণ করব, লজিক্যাল বনাম ফিজিক্যাল ব্যাকআপের প্রযুক্তিগত সমস্যাগুলো অন্বেষণ করব এবং আপনার মিশন-ক্রিটিক্যাল ডেটা সুরক্ষিত রাখতে ক্লাউডসেভ (CloudSave)-এর মতো এন্টারপ্রাইজ-গ্রেড সলিউশনে কীভাবে স্থানান্তরিত হওয়া যায় তা নিয়ে আলোচনা করব।
সরলতার বিভ্রম: ক্লাসিক ডিআইওয়াই স্ক্রিপ্টের ব্যবচ্ছেদ
বিপদটি বোঝার জন্য, আমাদের প্রথমে একটি সাধারণ ডিআইওয়াই ব্যাকআপ স্ক্রিপ্টের গঠন দেখতে হবে। একটি মাইএসকিউএল (MySQL) ডেটাবেসের জন্য সাধারণ পদ্ধতিটি প্রায়শই এরকম হয়:
#!/bin/bash
# সাধারণ ডিআইওয়াই মাইএসকিউএল ব্যাকআপ স্ক্রিপ্ট
BACKUP_DIR="/mnt/backups"
DATE=$(date +%F)
DB_USER="admin"
DB_PASS="SuperSecret123!"
mysqldump -u $DB_USER -p$DB_PASS my_database | gzip > $BACKUP_DIR/mydb_$DATE.sql.gz
# ৩০ দিনের বেশি পুরনো ব্যাকআপ মুছে ফেলুন
find $BACKUP_DIR -type f -name "*.sql.gz" -mtime +30 -exec rm {} ;
প্রথম দেখায়, এই স্ক্রিপ্টটি তার লক্ষ্য পূরণ করে: এটি ডেটা বের করে, সংকুচিত করে এবং রিটেনশন পরিচালনা করে। কিন্তু পর্দার আড়ালে, এটি মারাত্মক ত্রুটিতে পূর্ণ যা শেষ পর্যন্ত প্রোডাকশন এনভায়রনমেন্টে ডেটা হারানোর দিকে নিয়ে যাবে।
বিপদ ১: নীরব ব্যর্থতা এবং পাইপ ট্র্যাপ
ডিআইওয়াই স্ক্রিপ্টের অন্যতম কুখ্যাত বিপদ হলো নীরব ব্যর্থতা। উপরের স্ক্রিপ্টে, mysqldump কমান্ডটি সরাসরি gzip-এ পাইপ (|) করা হয়েছে।
ব্যাশ-এ, একটি পাইপলাইনের এক্সিট স্ট্যাটাস হলো পাইপলাইনের শেষ কমান্ডের এক্সিট স্ট্যাটাস। যদি ডেটাবেস সার্ভারের মেমরি শেষ হয়ে যায়, সংযোগ বিচ্ছিন্ন হয়ে যায়, অথবা ডাম্পের মাঝপথে কোনো লক করা টেবিলের সম্মুখীন হয়, তবে mysqldump ব্যর্থ হবে এবং একটি ত্রুটি দেখাবে। যাইহোক, gzip সফলভাবে প্রাপ্ত আংশিক আউটপুট সংকুচিত করবে এবং 0 (সাফল্য) স্ট্যাটাস কোড নিয়ে শেষ হবে।
আপনার মনিটরিং সিস্টেম, যা ক্রন জবের এক্সিট কোড পরীক্ষা করে, সেটি একটি সফল ব্যাকআপ রিপোর্ট করবে। আপনার ডিস্কে একটি বৈধ .gz ফাইল থাকবে, কিন্তু ভেতরে থাকবে একটি অসম্পূর্ণ, অকেজো এসকিউএল ফাইল। আপনি এটি ততক্ষণ পর্যন্ত জানতে পারবেন না যতক্ষণ না আপনি একটি গুরুত্বপূর্ণ রিস্টোর করার চেষ্টা করছেন।
প্রশমন (এবং এর সীমাবদ্ধতা)
ইঞ্জিনিয়াররা প্রায়শই ব্যাশ-এ কঠোর এরর হ্যান্ডলিং সক্রিয় করে এটি ঠিক করার চেষ্টা করেন:
set -e
set -o pipefail
যদিও set -o pipefail নিশ্চিত করে যে পাইপলাইনের কোনো কমান্ড ব্যর্থ হলে স্ক্রিপ্টটি ব্যর্থ হবে, তবুও এটি আপনাকে স্ক্রিপ্টের চারপাশে শক্তিশালী অ্যালার্টিং, লগিং এবং রিট্রাই মেকানিজম তৈরি করতে বাধ্য করে। যখন একটি ক্ষণস্থায়ী নেটওয়ার্ক ত্রুটির কারণে রাত ২টায় ব্যর্থতা ঘটে, তখন একটি ডিআইওয়াই স্ক্রিপ্ট কেবল বন্ধ হয়ে যায়। এন্টারপ্রাইজ প্ল্যাটফর্মগুলো বুদ্ধিমান, এক্সপোনেনশিয়াল ব্যাকঅফ রিট্রাইয়ের মাধ্যমে এই ক্ষণস্থায়ী ত্রুটিগুলো পরিচালনা করে।
বিপদ ২: ডেটা কনসিস্টেন্সি এবং লকিং নাইটমেয়ার
ডিআইওয়াই স্ক্রিপ্টগুলো মূলত লজিক্যাল ব্যাকআপের (mysqldump, pg_dump) ওপর ব্যাপকভাবে নির্ভর করে। লজিক্যাল ব্যাকআপ সমস্ত টেবিল জুড়ে SELECT স্টেটমেন্ট চালিয়ে ডেটা বের করে। একটি উচ্চ ট্রানজ্যাকশনাল প্রোডাকশন ডেটাবেসে, ডেটা ক্রমাগত পরিবর্তিত হচ্ছে। যদি একটি ১০০ জিবি ডেটাবেস ডাম্প করতে স্ক্রিপ্টের ৪৫ মিনিট সময় লাগে, তবে ডাম্পের শুরুর ডেটা শেষের ডেটার চেয়ে ৪৫ মিনিট পুরনো হবে, যা এসিড (ACID) কমপ্লায়েন্স লঙ্ঘন করে।
মাইএসকিউএল ট্রানজ্যাকশনাল কনসিস্টেন্সি
InnoDB ব্যবহার করে মাইএসকিউএল-এ একটি সামঞ্জস্যপূর্ণ স্ন্যাপশট পেতে, আপনাকে নির্দিষ্ট ফ্ল্যাগ ব্যবহার করতে হবে:
mysqldump --single-transaction --quick --routines --events -u user -p db > dump.sql
--single-transaction ফ্ল্যাগটি আইসোলেশন লেভেলকে REPEATABLE READ-এ সেট করে এবং ডাম্প করার আগে একটি ট্রানজ্যাকশন শুরু করে। যাইহোক, যদি আপনার ডেটাবেসে এখনও পুরনো MyISAM টেবিল থাকে, তবে এই ফ্ল্যাগটি সেগুলোকে লক হওয়া থেকে আটকাতে পারবে না, যা ব্যাকআপ চলার সময় প্রোডাকশন রিড/রাইট ট্রাফিক বন্ধ করে দিতে পারে। এছাড়া, ব্যাকআপ চলাকালীন ডেভেলপারদের দ্বারা চালানো যেকোনো ALTER TABLE, DROP TABLE, বা RENAME TABLE স্টেটমেন্ট REPEATABLE READ স্ন্যাপশট ভেঙে দেবে, যার ফলে ডাম্পটি ব্যর্থ হবে।
পোস্টগ্রেএসকিউএল এবং ডাব্লিউএএল (WAL) আর্কাভিং
পোস্টগ্রেএসকিউএল-এর জন্য, pg_dump সামঞ্জস্যপূর্ণ লজিক্যাল ব্যাকআপ প্রদান করে, কিন্তু শুধুমাত্র লজিক্যাল ব্যাকআপ পয়েন্ট-ইন-টাইম রিকভারি (PITR) প্রদান করতে পারে না। যদি আপনার ডেটাবেস বিকেল ৪টায় ক্র্যাশ করে এবং আপনার শেষ ক্রন স্ক্রিপ্টটি মধ্যরাতে চলে থাকে, তবে আপনি ১৬ ঘণ্টার ডেটা হারাবেন।
PITR অর্জনের জন্য রাইট-অহেড লগস (WAL)-এর ক্রমাগত আর্কাভিং প্রয়োজন। archive_command নিরাপদে পরিচালনা করার জন্য একটি ডিআইওয়াই স্ক্রিপ্ট লেখা অত্যন্ত কঠিন।
# postgresql.conf
wal_level = replica
archive_mode = on
archive_command = 'test ! -f /mnt/wal_archive/%f && cp %p /mnt/wal_archive/%f'
যদি গন্তব্য স্টোরেজ (/mnt/wal_archive/) পূর্ণ হয়ে যায় বা অনুপলব্ধ হয়ে পড়ে, তবে archive_command ব্যর্থ হবে। পোস্টগ্রেএসকিউএল তখন প্রাথমিক ডিস্ক পূর্ণ না হওয়া পর্যন্ত স্থানীয়ভাবে WAL ফাইলগুলো জমা করবে, যার ফলে সম্পূর্ণ ডেটাবেস অচল হয়ে যাবে। ডিআইওয়াই স্ক্রিপ্টগুলোতে খুব কমই এমন টেলিমেট্রি থাকে যা WAL জমা হওয়া পর্যবেক্ষণ করতে পারে এবং বিভ্রাট ঘটার আগেই অ্যাডমিনিস্ট্রেটরদের সতর্ক করতে পারে।
বিপদ ৩: রিটেনশন রুলেট
আমাদের প্রাথমিক স্ক্রিপ্টের রিটেনশন কমান্ডটি আবার দেখুন:
find $BACKUP_DIR -type f -name "*.sql.gz" -mtime +30 -exec rm {} ;
এটি একটি বিপর্যয়কর ডেটা হারানোর ঘটনা যা ঘটার অপেক্ষায় আছে। এমন একটি পরিস্থিতির কথা কল্পনা করুন যেখানে কনফিগারেশন পরিবর্তনের ফলে mysqldump অথেন্টিকেশন ভেঙে গেছে। স্ক্রিপ্টটি নতুন ব্যাকআপ তৈরি করতে ব্যর্থ হচ্ছে, কিন্তু find কমান্ডটি প্রতি রাতে চলছে এবং ৩০ দিনের বেশি পুরনো ফাইলগুলো মুছে ফেলছে।
৩০ দিন নীরব ব্যাকআপ ব্যর্থতার পর, find কমান্ডটি আপনার শেষ অবশিষ্ট ভালো ব্যাকআপটিও মুছে ফেলবে। এখন আপনার কাছে কোনো ব্যাকআপই অবশিষ্ট থাকবে না।
ক্লাউডসেভ-এর মতো এন্টারপ্রাইজ ব্যাকআপ সফটওয়্যার স্টেটফুল রিটেনশন পলিসি ব্যবহার করে। এটি “৩০ দিনের বেশি পুরনো ব্যাকআপ মুছে ফেলুন” এবং “পুরনো ডেটা ছাঁটাই করার আগে অন্তত ৩০টি সফল রিকভারি পয়েন্ট নিশ্চিত করুন”-এর মধ্যে পার্থক্য বোঝে।
বিপদ ৪: নিরাপত্তা, এনক্রিপশন এবং কমপ্লায়েন্সের অন্ধ দিক
র্যানসমওয়্যার এবং কঠোর কমপ্লায়েন্স ফ্রেমওয়ার্কের (GDPR, HIPAA, SOC 2) যুগে, ব্যাকআপগুলো একটি প্রধান লক্ষ্যবস্তু। ডিআইওয়াই স্ক্রিপ্টগুলো প্রায়শই নিরাপত্তার সর্বোত্তম অনুশীলনগুলো লঙ্ঘন করে:
- হার্ডকোডেড ক্রেডেনশিয়ালস: প্লেইনটেক্সট স্ক্রিপ্ট বা ক্রন ডেফিনিশনে ডেটাবেস পাসওয়ার্ড সংরক্ষণ করা একটি বিশাল নিরাপত্তা ঝুঁকি। যদিও মাইএসকিউএল-এর
mysql_config_editorবা পোস্টগ্রেএসকিউএল-এর.pgpassফাইলের মতো টুলগুলো এটি প্রশমিত করে, তবুও সেগুলোর জন্য সার্ভারে স্থানীয় কী ফাইল পরিচালনা করতে হয়। - স্টোরেজে এনক্রিপশনের অভাব: ডিস্কে কাঁচা এসকিউএল ডাম্প করা সংবেদনশীল PII/PHI-কে উন্মুক্ত রাখে।
- জটিল এনক্রিপশন পাইপলাইন: GPG ব্যবহার করে অন-দ্য-ফ্লাই ব্যাকআপ এনক্রিপ্ট করার চেষ্টা করলে তা মারাত্মক সিপিইউ ওভারহেড এবং কী ম্যানেজমেন্টের জটিলতা তৈরি করে।
# একটি ডিআইওয়াই এনক্রিপ্টেড ব্যাকআপ পাইপলাইন
pg_dump mydb | gzip | gpg --symmetric --cipher-algo AES256 --passphrase-file /etc/keys/backup.key > backup.sql.gz.gpg
যদি সার্ভারটি আপসড (compromised) হয়, তবে আক্রমণকারীর কাছে এনক্রিপ্টেড ব্যাকআপ এবং /etc/keys/backup.key ফাইল উভয়েরই অ্যাক্সেস থাকবে, যা এনক্রিপশনকে অকেজো করে দেবে। এছাড়া, যদি যে ডিবিএ (DBA) GPG কী তৈরি করেছিলেন তিনি কোম্পানি ছেড়ে চলে যান এবং কীটি হারিয়ে যায়, তবে ব্যাকআপগুলো আর পুনরুদ্ধার করা সম্ভব হবে না।
বিপদ ৫: আরটিও (RTO) রিয়ালিটি চেক (রিস্টোর করা ব্যাকআপের চেয়ে কঠিন)
ব্যাকআপের চূড়ান্ত পরীক্ষা হলো রিস্টোর করা। ডিআইওয়াই স্ক্রিপ্ট দ্বারা তৈরি লজিক্যাল ব্যাকআপগুলো রিস্টোর করা কুখ্যাতভাবে ধীর। একটি ৫০০ জিবি এসকিউএল ডাম্প তৈরি করতে ১৫ মিনিট সময় লাগতে পারে, কিন্তু এটি রিস্টোর করতে ডেটাবেস ইঞ্জিনকে এসকিউএল পার্স করতে হয়, ইনডেক্স পুনর্নির্মাণ করতে হয় এবং কনস্ট্রেইন্টগুলো পুনরায় গণনা করতে হয়। এতে কয়েক ঘণ্টা বা এমনকি কয়েক দিন সময় লাগতে পারে, যা আপনার RTO-কে ধ্বংস করে দেয়।
বড় প্রোডাকশন ডেটাবেসের জন্য, ফিজিক্যাল ব্যাকআপ (প্রকৃত ডেটা ফাইলগুলো কপি করা) বাধ্যতামূলক। যদিও Percona XtraBackup বা pg_basebackup-এর মতো টুল রয়েছে, সেগুলোকে ডিআইওয়াই ব্যাশ স্ক্রিপ্টে মোড়ানো অত্যন্ত জটিল। আপনাকে LVM স্ন্যাপশট পরিচালনা করতে হবে, ফাইল সিস্টেম কুইসিং সামলাতে হবে এবং নেটওয়ার্ক ইন্টারফেস স্যাচুরেট না করে ব্যাকআপটি অফসাইটে স্থানান্তর নিশ্চিত করতে হবে।
এলভিএম (LVM) স্ন্যাপশট ট্র্যাপ
অনেক ইঞ্জিনিয়ার LVM স্ন্যাপশট ব্যবহার করে “জিরো ডাউনটাইম” ফিজিক্যাল ব্যাকআপের চেষ্টা করেন:
# একটি স্ন্যাপশট তৈরি করুন
lvcreate --size 20G --snapshot --name db_snap /dev/vg0/db_vol
# মাউন্ট এবং কপি করুন
mount /dev/vg0/db_snap /mnt/snap
tar -czf /backups/db_physical.tar.gz /mnt/snap/mysql
যদি ডেটাবেসে রাইট I/O-এর হঠাৎ বৃদ্ধি ঘটে, তবে ২০ জিবি LVM স্ন্যাপশটটি তাৎক্ষণিকভাবে পূর্ণ হয়ে যেতে পারে। যখন একটি LVM স্ন্যাপশট পূর্ণ হয়, তখন এটি অবৈধ হয়ে যায় এবং ব্যাকআপ ব্যর্থ হয়। আরও খারাপ হলো, অতিরিক্ত ব্যবহৃত LVM স্ন্যাপশটগুলো প্রাথমিক ডেটাবেস ভলিউমের I/O পারফরম্যান্স মারাত্মকভাবে কমিয়ে দিতে পারে, যার ফলে অ্যাপ্লিকেশনে ল্যাটেন্সি স্পাইক দেখা দেয়।
এন্টারপ্রাইজ-গ্রেড সুরক্ষায় স্থানান্তর
ডিআইওয়াই স্ক্রিপ্ট থেকে এন্টারপ্রাইজ প্ল্যাটফর্মে স্থানান্তর যেকোনো পরিকাঠামো দলের জন্য একটি গুরুত্বপূর্ণ পরিপক্কতার মাইলফলক। লক্ষ্য হলো “স্ক্রিপ্টটি চলেছে বলে আশা করা” থেকে সরে এসে পুনরুদ্ধারযোগ্যতার ক্রিপ্টোগ্রাফিক প্রমাণ থাকা।
ক্লাউডসেভ-এর মতো প্ল্যাটফর্মগুলো বিশেষভাবে ডিআইওয়াই স্ক্রিপ্টিংয়ের অন্ধ দিকগুলো দূর করার জন্য তৈরি করা হয়েছে। অ্যাপ্লিকেশন-অ্যাওয়ার এজেন্ট মোতায়েন করে, ক্লাউডসেভ সরাসরি ডেটাবেস এপিআই (MySQL, PostgreSQL, MS SQL, Oracle)-এর সাথে যোগাযোগ করে টেবিল লক না করে বা পারফরম্যান্স না কমিয়ে সামঞ্জস্যপূর্ণ ফিজিক্যাল এবং লজিক্যাল ব্যাকআপ পরিচালনা করে।
স্ক্রিপ্ট থেকে দূরে সরে যাওয়ার মূল সুবিধা:
- স্বয়ংক্রিয় যাচাইকরণ: আধুনিক প্ল্যাটফর্মগুলো কেবল ব্যাকআপ নেয় না; তারা সেগুলো পরীক্ষা করে। ক্লাউডসেভ স্বয়ংক্রিয়ভাবে একটি অস্থায়ী ডেটাবেস ইনস্ট্যান্স চালু করতে পারে, ব্যাকআপ রিস্টোর করতে পারে, কনসিস্টেন্সি চেক (যেমন:
DBCC CHECKDB) চালাতে পারে এবং এটি মুছে ফেলতে পারে, যা ব্যাকআপটি আসলে ব্যবহারযোগ্য কিনা তার একটি যাচাইকৃত রিপোর্ট প্রদান করে। - ইমিউটেবল স্টোরেজ: র্যানসমওয়্যারের বিরুদ্ধে লড়াই করার জন্য, ব্যাকআপগুলো অবশ্যই ইমিউটেবল (অপরিবর্তনযোগ্য) হতে হবে। ডিআইওয়াই স্ক্রিপ্টগুলো সহজে WORM (Write Once, Read Many) স্টোরেজে লিখতে পারে না। এন্টারপ্রাইজ সলিউশনগুলো নেটিভভাবে S3 অবজেক্ট লক এবং ইমিউটেবল ক্লাউড স্টোরেজের সাথে ইন্টিগ্রেট করে, যা নিশ্চিত করে যে সার্ভারটি পুরোপুরি আপসড হলেও, ব্যাকআপগুলো কোনো আক্রমণকারীর দ্বারা মুছে ফেলা বা এনক্রিপ্ট করা যাবে না।
- সরলীকৃত পিআইটিআর (PITR): জটিল
recovery.confবাpostgresql.auto.confপ্যারামিটার ব্যবহার করে ম্যানুয়ালি একটি বেস ব্যাকআপ এবং শত শত WAL ফাইল জোড়া দেওয়ার পরিবর্তে, প্ল্যাটফর্মগুলো একটি ভিজ্যুয়াল টাইমলাইন প্রদান করে। আপনি কেবল সেই সঠিক মিনিটটি নির্বাচন করেন যেখানে আপনি রিস্টোর করতে চান এবং সফটওয়্যারটি স্বয়ংক্রিয়ভাবে লগ রিপ্লে পরিচালনা করে। - ডিডুপ্লিকেশন এবং কম্প্রেশন: ডিআইওয়াই স্ক্রিপ্টগুলো
gzip-এর ওপর নির্ভর করে, যা প্রতিটি ফাইল আলাদাভাবে সংকুচিত করে। এন্টারপ্রাইজ ব্যাকআপ সফটওয়্যার গ্লোবাল ব্লক-লেভেল ডিডুপ্লিকেশন ব্যবহার করে, যা অফসাইটে ব্যাকআপ স্থানান্তর করার সময় স্টোরেজ খরচ এবং নেটওয়ার্ক ব্যান্ডউইথ নাটকীয়ভাবে হ্রাস করে।
উপসংহার
একটি ডেটাবেস ব্যাকআপ করার জন্য একটি কাস্টম ব্যাশ স্ক্রিপ্ট লেখা সহজ। কিন্তু এমন একটি স্ক্রিপ্ট লেখা যা নীরব পাইপলাইন ব্যর্থতা পরিচালনা করে, এসিড (ACID) কনসিস্টেন্সি নিশ্চিত করে, ক্রিপ্টোগ্রাফিক কীগুলো নিরাপদে পরিচালনা করে, রিটেনশন-ভিত্তিক ডেটা হারানো প্রতিরোধ করে এবং কঠোর RTO/RPO SLA নিশ্চিত করে, তা প্রায় অসম্ভব।
প্রোডাকশন এনভায়রনমেন্টে, ডেটাবেস হলো ব্যবসার সবচেয়ে গুরুত্বপূর্ণ সম্পদ। কয়েকশ লাইনের শেল স্ক্রিপ্ট দ্বারা রক্ষণাবেক্ষণ করা একটি সাইড-প্রজেক্ট হিসেবে এর সুরক্ষাকে দেখা এমন একটি ঝুঁকি যা কোনো এন্টারপ্রাইজ নিতে পারে না। আপনার বর্তমান ব্যাকআপ কৌশলগুলো অডিট করে, লজিক্যাল ডাম্পের সীমাবদ্ধতাগুলো বুঝে এবং ক্লাউডসেভ-এর মতো শক্তিশালী, স্বয়ংক্রিয় প্ল্যাটফর্মে স্থানান্তরিত হয়ে, ডেভঅপস (DevOps) এবং ডিবিএ (DBA) দলগুলো কাস্টম স্ক্রিপ্টের “বাস ফ্যাক্টর” দূর করতে পারে এবং নিশ্চিত করতে পারে যে তাদের ডেটা সত্যিই স্থিতিস্থাপক।
