მოკლე ვერსია ორი ბრძანებაა. mongodump --uri="$MONGODB_URI" --archive=shop-2026-09-21.gz --gzip ყველა collection-ს ერთ შეკუმშულ ფაილში წერს, სანამ სერვერი მუშაობს. mongorestore --uri="$MONGODB_URI" --archive=shop-2026-09-21.gz --gzip --drop მას უკან აბრუნებს. ორივე ბაზისგან განცალკევებული პროგრამაა, ორივე დაკავშირების მონაცემებს ისე იღებს, როგორც შენი აპლიკაცია, და არცერთი სერვერს არ ხსნის.
გრძელი ვერსია ის ნაწილია, რომელიც წყვეტს, წელიწადში მონაცემები კიდევ გექნება თუ არა. mongodump არის ლოგიკური backup: დოკუმენტების ასლი, გამოკითხული ჩვეულებრივი query-ებით. ეს მას ვერსიებსა და მანქანებს შორის გადატანადს ხდის და ასევე ნიშნავს, რომ ის წამიერი არ არის. standalone სერვერზე dump ერთ collection-ს მეორის მიყოლებით კითხულობს, სანამ ჩაწერები მის ქვეშ გრძელდება, ამიტომ არქივი თითო collection-ის შიგნით თანმიმდევრულია და collection-ებს შორის - არა. ზუსტად იმის ცოდნა, რას იძლევა და რას არა ეს გარანტია, ამ პოსტის უმეტესი ნაწილია.
რას აწარმოებს mongodump და საიდან ავიღო#
MongoDB 4.4-დან ინსტრუმენტები სერვერთან ერთად აღარ მოდის. mongodump, mongorestore, mongoexport, mongoimport და bsondump მოდის როგორც MongoDB Database Tools, ცალკე პაკეტი საკუთარი ვერსიის ნომრებით 100.x სერიაში. დააყენე ისინი იმ მანქანაზე, რომელიც backup-ებს გააკეთებს - შენი აპლიკაციის სერვერი, შენი ლეპტოპი, ნებისმიერი ადგილი, სადაც შენი scheduler მუშაობს - და ისინი ბაზას იმავე host-ითა და პორტით დაუკავშირდებიან, როგორც შენი აპლიკაცია.
ნაგულისხმევად mongodump დირექტორიას წერს:
dump/ shop/ orders.bson orders.metadata.json customers.bson customers.metadata.jsonთითოეული .bson ფაილი არის დოკუმენტები ნედლად, ბინარულად. თითოეული .metadata.json შეიცავს collection-ის პარამეტრებს და ინდექსების განსაზღვრებებს, რითაც mongorestore იგებს, რომ შენი ინდექსები მერე თავიდან ააგოს. წაშალე metadata ფაილი და მონაცემებს ინდექსების გარეშე აღადგენ, რაც ძვირი შეცდომაა production-ში აღმოსაჩენად.
--archive ამ დირექტორიას ერთი ნაკადით ცვლის, რაც თითქმის ყოველთვის გინდა: ერთი ფაილი, რომლის დარქმევაც, გადატანაც, checksum-ის აღებაც და ჩამოტვირთვაც შეიძლება. --archive ფაილის სახელის გარეშე სტანდარტულ გამოსავალზე წერს, ამიტომ dump პირდაპირ შეიძლება აღდგენაზე გადაიგზავნოს სხვა მანქანაზე, არცერთზე დისკის შეხების გარეშე.
Dump-ის აღება#
$ mongodump --uri="mongodb://backup:pw@db.example.net:27017/?authSource=admin" \ --db=shop \ --archive="shop-$(date +%F).gz" --gzipდაკავშირების მონაცემები მოდის --uri-დან ან ცალკეული flag-ებიდან (--host, --port, -u, -p, --authenticationDatabase), არა ორივესგან ერთდროულად. მომხმარებელს სჭირდება backup როლი, რომელიც ზუსტად იმ პრივილეგიების ნაკრებია, რაც ინსტრუმენტს სჭირდება და არაფერი მეტი. თუ ჯერ კიდევ არკვევ, როგორი უნდა იყოს URI, MongoDB connection string-ები მას დაშლის.
| პარამეტრი | ნაგულისხმევი | რას აკეთებს |
|---|---|---|
--db, --collection | ყველა | ზღუდავს, რა იწერება |
--archive=FILE | დირექტორიის გამოსავალი | ერთი ფაილი საქაღალდის ნაცვლად |
--gzip | გამორთული | შეკუმშავს; ხშირად მეოთხედის ზომაა |
--out=DIR | dump/ | სად მიდის დირექტორიის გამოსავალი |
--query='{...}' | არაფერი | ქვესიმრავლის dump; სჭირდება --collection |
--excludeCollection | არაფერი | collection-ის გამოტოვება, განმეორებადი |
--numParallelCollections | 4 | ერთდროულად dump-ირებული collection-ები |
--readPreference | primary | კითხულობს secondary-დან |
--oplog | გამორთული | მხოლოდ replica set-ებისთვის, იხილე ქვემოთ |
--dumpDbUsersAndRoles | გამორთული | ამ ბაზაში განსაზღვრული მომხმარებლების ჩართვა |
მათგან ორს მეორე გახედვა უღირს. --query dump-ს collection-ის ნაწილის ექსპორტად აქცევს, რითაც ერთი კლიენტის მონაცემებს support მოთხოვნისთვის იღებ 40 GB-ის კოპირების გარეშე. და --numParallelCollections=4 ნაგულისხმევია, რადგან ოთხი worker უმეტეს პატარა სერვერს ავსებს; 1 GB გეგმაზე მისი 1-ზე დაწევა dump-ს უფრო ნელს ხდის და ბაზას მისი მუშაობისას შესამჩნევად ნაკლებ უხერხულობას უქმნის.
მომხმარებლები და როლები არ შედის, სანამ არ მოითხოვ. ისინი ინახება admin.system.users და admin.system.roles-ში, ამიტომ ან admin ბაზაც dump-ე, ან გამოიყენე --dumpDbUsersAndRoles --db-თან ერთად. აღდგენა, რომელიც წარმატებით სრულდება და შემდეგ ყველა login-ს უარყოფს, ჩვეულებრივ ესაა.
თანმიმდევრულობა: რასაც ყველა არასწორად იგებს#
mongodump collection-ებს თანმიმდევრულად კითხულობს. თუ ის 02:00-ზე იწყება და 02:06-ზე მთავრდება, users.bson 02:00-ს ასახავს და orders.bson - 02:06-ს. შეკვეთა, ჩაწერილი 02:03-ზე და მიბმული მომხმარებელზე, რომელიც 02:03-ზე შეიქმნა, არქივში შეიძლება მოხვდეს შეკვეთით და მომხმარებლის გარეშე. უმეტესი აპლიკაციისთვის ეს თეორიული პრობლემაა; ყველაფრისთვის, სადაც გაწყვეტილი მითითება ეკრანს არღვევს, არა.
გამოსავალია --oplog, რომელიც დამატებით იღებს ოპერაციების ლოგს იმ ფანჯრისთვის, რომელსაც dump ფარავს. --oplogReplay-ით აღდგენა ამ ოპერაციებს ზემოდან იყენებს და ყველა collection-ს ერთ მომენტამდე მიიყვანს: იმ მომენტამდე, როცა dump დასრულდა. მას ორი მოთხოვნა აქვს, რაც ბევრს გამორიცხავს. სჭირდება replica set, რადგან standalone mongod-ს oplog საერთოდ არ აქვს, და ის მთელ ინსტანციას dump-ავს, ამიტომ --db-სა და --collection-თან ვერ შეხამდება.
ერთ standalone სერვერზე, მაშასადამე, პატიოსანი არჩევანია: მიიღო თითო collection-ის თანმიმდევრულობა, რაც აპლიკაციათა დიდი უმრავლესობისთვის კარგია; შეაჩერო ჩაწერები ამ დროისთვის, რაც პატარა ბაზისთვის რეალისტურია, რომელიც ოცი წამში dump-ირდება; ან ინსტანცია გაუშვა როგორც ერთწევრიანი replica set, რომ oplog არსებობდეს. ერთადერთი, რაც არ უნდა გააკეთო, არის ვივარაუდო, რომ წერტილოვანი აღდგენა გაქვს, იმიტომ რომ ღამის dump გაქვს. არ გაქვს, და ამის აღმოჩენის მომენტი ინციდენტი არ უნდა იყოს. იგივე განსხვავება რელაციურ სამყაროშიც მოქმედებს - pg_dump და pg_restore იმავე ხაზს ავლებს ლოგიკურ dump-სა და ჭეშმარიტ წერტილოვან აღდგენას შორის.
აღდგენა#
$ mongorestore --uri="mongodb://root:pw@db.example.net:27017/?authSource=admin" \ --archive=shop-2026-09-21.gz --gzip --drop| პარამეტრი | რას აკეთებს |
|---|---|
--drop | აღდგენამდე ყოველ collection-ს, რომელიც dump-შია, აგდებს |
--nsInclude, --nsExclude | აღადგენს მხოლოდ, ან ყველას გარდა, შესაბამის namespace-ებს |
--nsFrom, --nsTo | აღდგენისას ბაზებს ან collection-ებს სახელს ცვლის |
--noIndexRestore | ინდექსების აგებას აცდენს, ჩვეულებრივ ცუდი იდეაა |
--numParallelCollections | ერთდროულად აღდგენილი collection-ები, ნაგულისხმევი 4 |
--numInsertionWorkersPerCollection | ნაგულისხმევი 1; გაზარდე ერთი უზარმაზარი collection-ისთვის |
--stopOnError | პირველივე წარუმატებლობაზე წყდება და არ გრძელდება |
--oplogReplay | მონაცემების შემდეგ იყენებს oplog.bson-ს, --oplog dump-ებისთვის |
--preserveUUID | ინახავს collection-ის UUID-ებს; სჭირდება --drop |
--writeConcern | დაწიე მასობრივი ჩატვირთვის დროს |
--drop-ის ნიუანსი ყველას სულ მცირე ერთხელ ატყუებს. ის აგდებს collection-ებს, რომლებიც dump-შია. ის არ ეხება collection-ებს, რომლებიც სამიზნეზეა, მაგრამ არქივში არ არის, ამიტომ აღდგენა ჭუჭყიან ბაზაში ძველ collection-ებს ტოვებს და ისე გამოიყურება, თითქოს იმუშავა. თუ სუფთა შედეგი გინდა, ჯერ ბაზა ჩააგდე, ან აღადგინე ახალში.
ინდექსების აღდგენა ჩვეულებრივ აღდგენის ყველაზე ნელი ნაწილია, რადგან ყოველი ინდექსი თავიდან შენდება მას შემდეგ, რაც დოკუმენტები მოვა. სწორედ ამიტომ არის აღდგენილი ბაზა ხშირად უფრო სწრაფი, ვიდრე ის, საიდანაც მოვიდა: ინდექსები ახლად გამოდის და არა ფრაგმენტირებულად. --noIndexRestore-ს სისწრაფისთვის ნუ მოჰკიდებ ხელს, თუ ინდექსებს მაშინვე თვითონ არ აპირებ აგებას - აპლიკაცია გამოუსადეგარი იქნება, სანამ არ გააკეთებ. MongoDB-ის სქემის დიზაინი და ინდექსები გიჩვენებს, რას აკეთებს ეს აგებები.
სანამ რამეს აღადგენ, რაშიც დარწმუნებული არ ხარ, შიგნით ჩახედე. bsondump --quiet dump/shop/orders.bson | head -n 3 პირველ რამდენიმე დოკუმენტს JSON-ად ბეჭდავს, ხოლო არქივისთვის შეგიძლია აღადგინო დროებით ბაზაში და დათვალო:
$ mongorestore --archive=shop-2026-09-21.gz --gzip \ --nsFrom='shop.*' --nsTo='shop_check.*'$ mongosh --quiet --eval 'db.getSiblingDB("shop_check").orders.countDocuments()'ერთი collection-ის აღდგენა, ან სხვა სახელით#
გავრცელებული ავარია არ არის „სერვერი გაქრა“. ეს არის „ვიღაცამ ერთ collection-ზე delete გაუშვა ფილტრის გარეშე 11:40-ზე“. გინდა ეს collection ბოლო ღამიდან, დანარჩენს შეხების გარეშე.
$ mongorestore --archive=shop-2026-09-21.gz --gzip \ --nsInclude='shop.orders' --drop--nsInclude შაბლონებს იღებს, ამიტომ --nsInclude='shop.*' მთელი ინსტანციის არქივიდან ერთ ბაზას აღადგენს. იმავე ოპერაციის უფრო უსაფრთხო ვერსია მას ცოცხალი მონაცემების გვერდით აღადგენს და არა მათ თავზე, რომ commit-მდე შეადარო:
$ mongorestore --archive=shop-2026-09-21.gz --gzip \ --nsInclude='shop.orders' \ --nsFrom='shop.orders' --nsTo='rescue.orders'ახლა rescue.orders გუშინდელ ასლს შეიცავს. დათვალე, რამდენიმე დოკუმენტი შეამოწმე, გაარკვიე, რომელი აკლია ცოცხალ collection-ს, და გადაიტანე მხოლოდ ისინი aggregation-ით და $merge-ით. ეს --drop-ზე ნელია და არ აგდებს ჩაწერებს, რომლებიც backup-სა და შეცდომას შორის მოხდა, რაც ჩვეულებრივ სწორედ ის არის, რაც გინდა.
--nsFrom და --nsTo staging ასლის შესაქმნელადაც გამოიყენება: production-ის არქივი აღადგინე ბაზაში სახელად shop_staging სხვა სერვერზე და staging მასზე მიუთითე. ეს სხვა სერვერზე გააკეთე და არა production-ზე, თუ არ გინდა აღმოაჩინო, რომ აღდგენამ დისკი შეავსო.
mongoexport და mongoimport backup არ არის#
mongoexport წერს JSON-ს ან CSV-ს. ის ნამდვილად სასარგებლოა მონაცემების ვინმესთვის გადასაცემად, ვისაც spreadsheet აქვს, ან fixture-ის ჩასატვირთად. ის backup არ არის ერთი კონკრეტული მიზეზით: ნაგულისხმევად ის relaxed extended JSON-ს წერს, რომელიც BSON ტიპებს ორმხრივად არ ინახავს. 64-ბიტიანი მთელი რიცხვი შეიძლება double-ად დაბრუნდეს, Decimal128 სიზუსტეს კარგავს, ხოლო თარიღები და ობიექტის იდენტიფიკატორები ორაზროვანი ხდება. --jsonFormat=canonical ტიპებს ინახავს, მაგრამ გამოსავალი მაინც უფრო დიდია, უფრო ნელია და შენი ინდექსების განსაზღვრებები აკლია.
წესი მარტივია. mongodump და mongorestore backup-ებისთვის და MongoDB ინსტანციებს შორის გადატანისთვის, რადგან ისინი BSON ტიპებსა და metadata-ს ერთგულად გადააქვთ. mongoexport და mongoimport ყველაფერთან გაცვლისთვის, რაც MongoDB არ არის.
backup-ის სხვა სახეობები და მათი კომპრომისები#
ფაილური სისტემის ან volume snapshot-ები. სწრაფია და მთელ ინსტანციას ფარავს, მაგრამ მხოლოდ მაშინ არის ვალიდური, თუ snapshot ატომურია ყველა volume-ზე, სადაც მონაცემები და journal არის. ერთი წამის დაშორებით გადაღებული ორი volume იძლევა ბაზას, რომელიც შეიძლება არ გაიშვას. სადაც ატომურობას ვერ უზრუნველყოფ, db.fsyncLock() ჩაწერებს ხანგრძლივობისთვის ბლოკავს და flush-ს აკეთებს, რაც რეალური გათიშვაა, რაც უნდა მოკლე იყოს.
მუშა სერვერის მონაცემთა დირექტორიის კოპირება. ეს backup არ არის. ფაილები იწერება, სანამ აკოპირებ, და შედეგი დაზიანებული ბაზაა, რომელიც კარგად გამოიყურება, სანამ არ იქცევა ერთადერთ ასლად, რაც გაქვს.
შენი ჰოსტის backup slot-ები. ისინი მთელ სერვერს იცავს, წამებში იწყება და სწორია „სერვერი გაფუჭდა“-სთვის. RE:NODE-ზე ყველა ბაზის გეგმა backup slot-ებს შეიცავს, რომლებიც მოთხოვნით ან გრაფიკით იღება, ინახება იმ მანქანის გარეთ, რომელსაც იცავს, აღდგება ღილაკით, ჩამოიტვირთება და დაიბლოკება, რომ როტაციამ ის, რასაც ეყრდნობი, არ წაშალოს. პატიოსანი შეზღუდვა ყველა პლატფორმის წვრილ შრიფტშია: სერვერის წაშლა მისი backup-ებს შლის, დაბლოკილებსაც. ამიტომ mongodump არქივი სადმე სხვაგანაც შეინახე ჩამოტვირთული. ორი მექანიზმი, რომლებიც სხვადასხვანაირად ფუჭდება, მთელი აზრია - backup-ები, რომლებიც მართლა აღდგება იმავე არგუმენტს უფრო დაწვრილებით ამბობს.
გრაფიკი, შენახვის ვადა და დისკის რეზერვი#
რუტინა, რომელიც მუშაობს, და ის ყველა ბაზაზე ერთია:
- აიღე dump ყოველ ღამე ყველაზე მშვიდ საათზე, სახელში თარიღით, შეკუმშული.
- გადაიტანე არქივი იმ მანქანის გარეთ, საიდანაც მოვიდა. იმავე დისკზე dump გიცავს ცუდი query-სგან და სხვა არაფრისგან.
- შეინახე შვიდი ყოველდღიური და ოთხი ყოველკვირეული ასლი და ავტომატურად გაასუფთავე. ხელით გასუფთავება სავსე დისკით მთავრდება, და ბაზის სერვერი სავსე დისკით ჩაწერებს აღარ იღებს.
- კვარტალში ერთხელ აღადგინე უახლესი არქივი დროებით ბაზაში, დათვალე დოკუმენტები collection-ებში, რომლებიც გაინტერესებს, აპლიკაციის ასლი მასზე მიუთითე და ბაზა ჩააგდე.
მეოთხე ნაბიჯი ის არის, რომელსაც ყველა ტოვებს, და ერთადერთია, რაც ფაილს backup-ად აქცევს. აღდგენის ტესტირება, სანამ გჭირდება და ბაზის backup და დამტკიცება, რომ ის აღდგება არსებობს იმიტომ, რამდენად ხშირად გამოტოვებენ მეოთხე ნაბიჯს.
პანელის Schedules tab იღებს cron გამოსახულებას და უშვებს დალაგებულ ამოცანებს მათ შორის დაგვიანებებით - backup, power action - ამიტომ ღამის backup პლატფორმის მხრიდან კონფიგურაციაა და არა სკრიპტი, რომლის ცოცხლად შენახვაც გიწევს. mongodump-ის ნახევარი ეკუთვნის იქ, სადაც შენი აპლიკაცია ან scheduler მუშაობს, მიმართული ბაზის host-სა და პორტზე. პანელის სახელმძღვანელოები გიჩვენებს, სად არის ეს მართვის ელემენტები.
უყურე დისკს. ბაზის სერვერის საკუთარ საცავზე ჩაწერილ dump-ს შეკუმშული არქივისთვის ადგილი სჭირდება მონაცემებსა და ინდექსებზე ზემოდან, და 20 GB გეგმაზე, სადაც 12 GB გამოყენებულია, შეიძლება საერთოდ არ იყოს. ჩაწერე არქივი სხვაგან, ან გადააგზავნე: mongodump --archive --gzip | ssh backup-host 'cat > shop.gz' ფაილს ბაზის სერვერზე საერთოდ არ აყენებს.
შეცდომები, რომლებსაც მართლა ნახავ#
`Failed: error connecting to db server` - დაკავშირების პრობლემაა და არა backup-ის. არასწორი host ან პორტი, სერვერი მხოლოდ loopback მისამართზეა მიბმული, ან firewall. ჯერ იგივე URI სცადე mongosh-ში.
`Failed: ... Authentication failed` - ჩვეულებრივ აკლია --authenticationDatabase admin, რაც იგივე authSource კითხვაა, რასაც driver-ები სვამენ.
`E11000 duplicate key error collection` - აღდგენა collection-ში, რომელსაც ეს დოკუმენტები უკვე აქვს. გინდოდა --drop, ან ახალი ბაზა.
`Failed: restore error: ... oplog.bson: no such file` - --oplogReplay dump-ზე, რომელიც --oplog-ის გარეშე გაკეთდა. oplog მხოლოდ მაშინ არის, თუ dump-ის დროს მოითხოვე.
`Failed: cannot use --oplog with --db or --collection` - --oplog ყველაფერია ან არაფერი მთელ ინსტანციაზე.
აღდგენა, რომელიც ინდექსების გარეშე მთავრდება - metadata ფაილები დაიკარგა, ან --noIndexRestore იყო დაყენებული. აღადგინე ისინი შენი სქემის განსაზღვრებებიდან.
აღდგენა, რომელსაც მეხსიერება ან დისკი ეწურება - ინდექსების აგება და პარალელური ჩასმა მეხსიერებას ხარჯავს. დაწიე --numParallelCollections და შეამოწმე, რომ სამიზნეს მონაცემებისა და ინდექსებისთვის ადგილი აქვს, რაც შეკუმშული არქივის ზომაზე მეტია.
FAQ#
ბლოკავს mongodump ბაზას?
არა. ის ჩვეულებრივი query-ის გზით კითხულობს, ამიტომ სერვერი მუშაობს. ის კონკურენციას უწევს CPU-ს, მეხსიერებასა და დისკის გამტარუნარიანობას, რაც პატარა ინსტანციაზე შესამჩნევია, ამიტომ გაუშვი როცა აპლიკაცია მშვიდადაა და განიხილე --numParallelCollections-ის შემცირება.
არის mongodump წერტილოვანი backup?
მხოლოდ --oplog-ით replica set-ზე, აღდგენილი --oplogReplay-ით. მის გარეშე თითოეული collection თავის შიგნით თანმიმდევრულია, მაგრამ collection-ები ოდნავ განსხვავებულ დროს იკითხება. უმეტესი აპლიკაციისთვის ეს მისაღებია; გადაწყვიტე შეგნებულად და არა ვარაუდით.
შემიძლია dump-ის აღდგენა MongoDB-ის უფრო ახალ ვერსიაში?
ჩვეულებრივ დიახ - BSON დოკუმენტები გადატანადია, და ვერსიებს შორის გადასვლის სტანდარტული გზა ესაა. ძველი dump-ები, აღდგენილი გაცილებით ახალ სერვერებში, ხანდახან ინდექსის პარამეტრებს აწყდება, რომლებიც მას შემდეგ შეიცვალა; --convertLegacyIndexes ზუსტად ამ შემთხვევისთვის არსებობს. აღდგენა უფრო ძველ major ვერსიაში, ვიდრე dump-ი მოვიდა, ისეთი რამ არ არის, რაზეც უნდა დაეყრდნო.
როგორ აღვადგინო მხოლოდ ერთი collection?
mongorestore --archive=file.gz --gzip --nsInclude='db.collection'. თუ ცოცხალ collection-ში ჯერ კიდევ არის მონაცემები, რომელიც გინდა შეინარჩუნო, აღადგინე სხვა სახელით --nsFrom-ითა და --nsTo-თი და შეაერთე, ცოცხლის ჩაგდების ნაცვლად.
mongodump თუ ჩემი ჰოსტის backup ღილაკი?
ორივე, რადგან ისინი სხვადასხვანაირად ფუჭდება. პლატფორმის backup მთელ სერვერს სწრაფად აღადგენს და სერვერთან ერთად ქრება. mongodump არქივი, რომელიც ჩამოტვირთე, გადატანადია ნებისმიერ ჰოსტსა და ნებისმიერ მხარდაჭერილ ვერსიაზე. არცერთი მარტო backup სტრატეგია არ არის.
რამდენ ხანს გრძელდება აღდგენა?
დოკუმენტების ჩატვირთვა დაახლოებით იმდენად სწრაფია, რამდენადაც დისკი და მეხსიერება იძლევა; ინდექსების აგება ჩვეულებრივ ამაზე მეტს გრძელდება. რამდენიმე გიგაბაიტი NVMe-ზე წუთებია. თუ გჭირდება რიცხვი, რომელიც ვინმეს შეგიძლია აღუთქვა, გაზომე ის შენს მონაცემებზე აღდგენის წვრთნისას, რადგან ეს ერთადერთი მაჩვენებელია, რომელსაც აზრი აქვს.
კომენტარები
სრულიად ანონიმურად: ანგარიშის, ელფოსტის და cookie-ის გარეშე. ინახება მხოლოდ სახელი, ტექსტი და დრო - სხვა არაფერი. ბმულების რაოდენობა ლიმიტირებულია.