pg_dump და pg_restore: პრაქტიკული backup გზამკვლევი

ორი ბრძანება თითქმის ყველა შემთხვევას ფარავს. pg_dump --format=custom --file=app.dump app წერს ერთ შეკუმშულ, თანმიმდევრულ არქივს ერთი ბაზისა, სანამ ის მომსახურებას აგრძელებს. pg_restore --dbname=app_new --jobs=4 app.dump კი მას პარალელურად აბრუნებს ცარიელ ბაზაში. ამ გზამკვლევში დანარჩენი ყველაფერი ამ ორი ხაზის გარშემო არსებული დეტალებია: რას არ შეიცავს არქივი, რომელი ვერსიის ინსტრუმენტები გამოიყენო, როგორ აღადგინო ერთი ცხრილი დანარჩენზე შეხების გარეშე და რატომ არის ნებისმიერი აღდგენის შემდეგ პირველი საქმე ANALYZE.

მისი სწავლის მიზეზი, იმის მაგივრად, რომ მთლიანად შენი ჰოსტის backup ღილაკს დაეყრდნო, პორტატულობაა. ლოგიკური dump არის შენი მონაცემების აღწერა, რომელსაც ნებისმიერ იმავე ან უფრო ახალი major ვერსიის PostgreSQL-ს შეუძლია წაიკითხოს, ნებისმიერ მანქანაზე, სამუდამოდ. ეს არის backup, რომელიც ჰოსტის შეცვლას, ვერსიების შეცვლას და სერვერის შემთხვევით წაშლას გადაურჩება.

რა არის dump და რა არ არის#

pg_dump უერთდება როგორც ჩვეულებრივი კლიენტი და მონაცემებს SQL-ით კითხულობს. თანმიმდევრული სურათის მისაღებად ის ხსნის ერთ ტრანზაქციას REPEATABLE READ იზოლაციის დონეზე და snapshot-ს იქ იღებს, ამიტომ არქივში ყოველი ცხრილი ერთსა და იმავე მომენტს ასახავს, თუნდაც dump ერთ საათს გრძელდებოდეს. ის მკითხველებსა და მწერლებს არ ბლოკავს.

თუმცა ის იღებს ACCESS SHARE lock-ს ყოველ ცხრილზე, რომელსაც კითხულობს. ეს ყველაზე სუსტი lock-ია და ის ერთადერთ რამესთან კონფლიქტობს: ACCESS EXCLUSIVE-თან, რომელსაც DROP TABLE, ALTER TABLE-ის უმეტესი ფორმა, TRUNCATE და VACUUM FULL იღებს. ამიტომ ერთდროულად მომუშავე dump და მიგრაცია ერთმანეთის რიგს დაბლოკავს, და რადგან lock-ის მოთხოვნები დალაგებულია, dump-ის უკან მდგომი მიგრაცია ყველა შემდეგ მოსულ მოთხოვნას ბლოკავს. გამოიყენე --lock-wait-timeout=10s, რომ dump-მა თავი დაანებოს და არა გროვას შეუერთდეს, და dump-ებსა და მიგრაციებს ერთ ფანჯარაში ნუ დაგეგმავ. მიგრაციები downtime-ის გარეშე ამ პრობლემის მეორე ნახევარს შეიცავს.

გრძელი dump-ის მეორე ფასი დაკავებული snapshot-ია. სანამ ის მუშაობს, vacuum ვერ შლის მასზე უფრო ახალ row ვერსიას, ამიტომ dump, რომელიც დატვირთულ ცხრილზე ოთხ საათს გრძელდება, ოთხი საათის მკვდარ row-ებს ტოვებს. ეს ნორმალურია და მერე იწმინდება, მაგრამ სწორედ ამიტომ ჯობს დიდი, ხშირად განახლებადი ბაზის dump მაშინ აიღო, როცა ბაზა მშვიდადაა. Postgres vacuum და bloat განმარტავს, რა ჯდება ეს მკვდარი row-ები.

რაც dump არ არის, არის point-in-time recovery სისტემა. ის ერთ მომენტს იჭერს. თუ გჭირდება „აღადგინე 14:32-ზე, ცუდი UPDATE-ის წინ“, ეს არის pg_basebackup პლუს დაარქივებული write-ahead ლოგები, რაც სხვა და გაცილებით მძიმე მოწყობაა. უმეტესი აპლიკაციისთვის ღამის dump და საათის შესაძლო დანაკარგი სწორი გაცვლაა, და სხვაგვარად თავის მოჩვენება არის ის, რითაც ხალხი ორივეს გარეშე რჩება.

ოთხი გამოტანის ფორმატი#

გამოიყენე custom ფორმატი, თუ საპირისპირო მიზეზი არ გაქვს. ის ერთი ფაილია, შეკუმშულია, შერჩევით აღდგება და pg_restore-ს მისი აღდგენა რამდენიმე worker-ით შეუძლია.

გამოიყენე directory ფორმატი, როცა ბაზა იმდენად დიდია, რომ თავად dump არის შემაფერხებელი, რადგან --jobs dump-ისთვის მხოლოდ ამ ფორმატში მუშაობს. ის ქმნის საქაღალდეს, სადაც თითო ცხრილზე ერთი ფაილია და შემცველობის ცხრილი, რაც ასევე ნიშნავს, რომ ნახავ, რომელი ცხრილია უზარმაზარი, უბრალოდ საქაღალდის ჩამოთვლით.

გამოიყენე plain ფორმატი, როცა ადამიანს SQL-ის წაკითხვა ან რედაქტირება სჭირდება, ან როცა პატარა ბაზას ისეთ ადგილას გადააქვს, სადაც მხოლოდ psql არის. ის არც შერჩევითია, არც შეკუმშული, ამიტომ რაიმე ზომის ბაზის plain dump ცუდი ნაგულისხმევია. Tar ფორმატი ისტორიული მიზეზებით არსებობს და იმას არაფერს გვთავაზობს, რასაც დანარჩენი ორი არ იძლევა.

PostgreSQL 16-სა და შემდეგზე --compress იღებს მეთოდსაც და დონესაც, ამიტომ --compress=zstd:3 directory dump-ზე მსგავსი ზომით gzip-ზე ბევრად სწრაფია. ადრეულ ვერსიებზე -Z 0-დან -Z 9-მდე zlib-ის დონეს ირჩევს, და არქივის ფორმატებისთვის ნაგულისხმევი უკვე ზომიერია.

Dump-ის აღება#

$ export PGHOST=db.example.net PGPORT=5432 PGUSER=appuser$ pg_dump --format=custom --no-owner --no-privileges \      --file=app-$(date +%F).dump app

კავშირის პარამეტრები მოდის flag-ებიდან (-h, -p, -U, -d) ან PG* გარემოს ცვლადებიდან. პაროლი ბრძანების ხაზზე არასოდეს ჩასვა, სადაც ის shell-ის ისტორიასა და ps-ის გამოტანაში აღმოჩნდება. გამოიყენე ~/.pgpass, ერთი ხაზი თითო სერვერზე, რეჟიმი 0600:

db.example.net:5432:*:appuser:the-generated-password

flag-ები, რომლებიც იცოდე:

• --no-owner (-O) - გამოტოვებს ALTER ... OWNER TO ინსტრუქციებს. აუცილებელია, როცა როლების სახელები სამიზნეზე განსხვავდება, და უვნებელია, როცა არა.
• --no-privileges (-x) - გამოტოვებს GRANT და REVOKE-ს. გამოიყენე, როცა აღადგენ ბაზაში, რომლის უფლებებსაც ცალკე მართავ.
• --schema-only და --data-only - ერთი მეორის გარეშე. schema-only dump-ის შენახვა ვერსიის კონტროლში სასარგებლოა.
• -t, -T, -n, -N - ცხრილებისა და სქემების ჩართვა ან გამორიცხვა სახელით ან შაბლონით. გაითვალისწინე, რომ -t orders იმ ცხრილებს არ ეწევა, რომლებზეც orders მიუთითებს, ამიტომ ასე აწყობილი dump ჩვეულებრივ ცარიელ ბაზაში თავისით არ აღდგება.
• --exclude-table-data='audit_log*' - ცხრილის განმარტებას ინახავს, row-ებს აგდებს. ასე იღებ 200 MB dump-ს 40 GB ბაზიდან staging ასლისთვის.
• --jobs=4 (-j) - მხოლოდ directory ფორმატი, თითო worker-ზე ერთი კავშირი. ნუ დააყენებ იმ ბირთვების რაოდენობაზე მეტზე, რასაც ბაზას მისცემ.
• --verbose - ბეჭდავს ყოველ ობიექტს, როგორც მიდის, რაც ჩუმ საათს რაღაცად აქცევს, რასაც უყურებ.

მთელი კლასტერისთვის არსებობს pg_dumpall, რომელიც ყველა ბაზას გადის. მისი მხოლოდ plain-SQL გამოტანა მას დიდი მონაცემებისთვის ცუდ არჩევანს ხდის, მაგრამ ის ერთადერთი გზაა, რომ მიიღო ის, რაც ბაზის გარეთ ცხოვრობს:

$ pg_dumpall --globals-only --file=globals.sql

როლები, გლობალური ობიექტები და რას არ შეიცავს dump#

აქ ჩავარდება აღდგენა, ამიტომ სია წაიკითხე. ერთი ბაზის pg_dump არ შეიცავს:

• როლებსა და მათ პაროლებს. ისინი მთელი კლასტერისაა. pg_dumpall --globals-only მათ იჭერს, პაროლის hash-ების ჩათვლით, და ბაზის dump-მდე აღადგენ psql -f globals.sql-ით. იხილე PostgreSQL როლები და უფლებები, როგორ უნდა გამოიყურებოდეს ეს როლები თავიდანვე.
• Tablespace-ებს. ესეც კლასტერულია, ესეც გლობალურ ფაილშია. დირექტორიები, რომლებზეც ისინი მიუთითებენ, სამიზნეზე წინასწარ უნდა არსებობდეს.
• `CREATE DATABASE` ინსტრუქციას, თუ -C არ გადასცე. ჩვეულებრივ ცარიელ ბაზას თავად ქმნი სწორი მფლობელით, კოდირებითა და collation-ით, და მერე მასში აღადგენ.
• სერვერის კონფიგურაციას. postgresql.conf და pg_hba.conf დისკზე ფაილებია და არა ბაზის ობიექტები. ისინი ცალკე გადაიტანე.
• Extension-ის კოდს. dump შეიცავს CREATE EXTENSION postgis;-ს და არა PostGIS-ს. თუ პაკეტი სამიზნე მანქანაზე დაყენებული არ არის, აღდგენა იქ ჩერდება.
• Planner-ის სტატისტიკას. ყოველი აღდგენილი ცხრილი სტატისტიკის გარეშე მოდის, სწორედ ამიტომ შეიძლება ახლად აღდგენილი ბაზა იმაზე დრამატულად ნელი იყოს, საიდანაც მოვიდა, სანამ ANALYZE-ს არ გაუშვებ. ზოგიერთ ძალიან ახალ ვერსიას სტატისტიკის გადატანა შეუძლია; ANALYZE-ის შემდეგ გაშვება მცირე ღირს და ეჭვს აქრობს. Postgres query plan-ის კითხვა განმარტავს, რას აკეთებს ეს სტატისტიკა.

დიდი ობიექტები ნაგულისხმევად შედის, როცა მთელ ბაზას იღებ, და გამოირიცხება, როცა dump-ს -t ან -n-ით ზღუდავ, თუ -b-საც არ გადასცემ. თანმიმდევრობის მნიშვნელობები შედის setval ზარებად, ამიტომ identity სვეტები იქიდან აგრძელებენ, სადაც გაჩერდნენ, და პირველ insert-ზე არ ეჯახებიან.

აღდგენა და flag-ები, რომლებიც მნიშვნელოვანია#

$ createdb -T template0 app_restore$ pg_restore --dbname=app_restore --jobs=4 --no-owner \      --verbose app-2026-09-21.dump

-T template0 უფრო მნიშვნელოვანია, ვიდრე ჩანს: ის გაძლევს ბაზას, რომელშიც არაფერია, ამიტომ ობიექტები, რომლებსაც dump ქმნის, ვერ დაეჯახებიან template1-დან მემკვიდრეობით მიღებულებს.

• --clean --if-exists - თითოეულ ობიექტს ხელახლა შექმნამდე წაშლის. გამოიყენე ორივე ერთად, ან --clean პირველივე ობიექტზე, რომელიც არ არსებობს, ხმაურით ჩავარდება.
• --single-transaction (-1) - ყველაფერი ან არაფერი. თუ რამე ჩავარდა, ბაზა ზუსტად ისე რჩება, როგორც იყო. მისი --jobs-თან შეთავსება არ შეიძლება, ამიტომ სიჩქარესა და ატომურობას შორის ირჩევ.
• --jobs=N - ცხრილის მონაცემებს აღადგენს და ინდექსებს ერთდროულად აშენებს. ნებისმიერი ზომის აღდგენაზე ეს განსხვავებაა ოც წუთსა და ორ საათს შორის. მხოლოდ custom და directory ფორმატები.
• --no-owner --role=appuser - ყველაფერს ერთი როლით აღადგენს, ორიგინალში ვინც არ უნდა ყოფილიყო მფლობელი.
• --section=pre-data|data|post-data - სქემა, row-ები, შემდეგ ინდექსები, შეზღუდვები და trigger-ები. გამოსადეგია, როცა მონაცემები გინდა ჩატვირთო და ინდექსის აგება გადადო.
• -t, -n, -L - შერჩევითი აღდგენა, ქვემოთ განხილულია.

plain ფორმატის dump საერთოდ არ აღდგება pg_restore-ით. ის SQL-ია, ამიტომ:

$ psql --dbname=app_restore --set ON_ERROR_STOP=1 --file=app.sql

ON_ERROR_STOP=1-ის გარეშე psql შეცდომებს ბეჭდავს, გრძელდება და ამთავრებს ნულოვანი გასვლის სტატუსით და ნახევრად აშენებული ბაზით. ამ ნაგულისხმევმა ისე ბევრი აღდგენა გააფუჭა, როგორც სხვა არცერთმა ერთმა რამემ.

არქივიდან ერთი ცხრილის აღსადგენად ჯერ შემცველობა ჩამოთვალე, დატოვე ხაზები, რომლებიც გინდა, და სია უკან მიაწოდე:

$ pg_restore --list app.dump > toc.list$ grep -E 'TABLE DATA public (orders|order_items)' toc.list > wanted.list$ pg_restore --dbname=app_restore --data-only --use-list=wanted.list app.dump

ეს -t orders-ზე უფრო საიმედოა, რადგან სიის ფაილი გაძლევს საშუალებას, დატოვო თანმიმდევრობაც, ინდექსებიც და შეზღუდვებიც, რომლებიც ცხრილს ეკუთვნის.

ვერსიების წესები სერვერებს შორის გადასვლისას#

სამი წესი ყველაფერს ფარავს:

1. Dump აიღე ყველაზე ახალი `pg_dump`-ით, რაც გაქვს. ვერსია 17-ის pg_dump-ს შეუძლია 13 ვერსიის სერვერის სრულყოფილად dump-ვა. საპირისპირო უარყოფილია: ძველი pg_dump უფრო ახალ სერვერზე ვერსიის შეუსაბამობით წყდება, რადგან არ იცის, რას შეიცავს ახალი კატალოგი.
2. აღადგინე იმავე major ვერსიაში ან უფრო ახალში. უკან გადასვლა, 17-დან 16-ზე, მხარდაჭერილი არ არის. ზოგჯერ თითქოს მუშაობს და მერე ისეთ სინტაქსზე ვარდება, რომელიც ძველ სერვერს არასოდეს სმენია.
3. `pg_restore` მინიმუმ იმავე სიახლის უნდა იყოს, რასაც არქივის დამწერი `pg_dump`. ძველი pg_restore ახალ არქივს unsupported version ... in file header-ით უარყოფს.

სამივეს პრაქტიკული ვერსია: განახლებისას ან მიგრაციისას ახალი სერვერის pg_dump და pg_restore ბინარები გაუშვი ძველ სერვერზე. Minor ვერსიები (17.2-დან 17.6-მდე) აქ არასოდეს ითვლება.

დიდი აღდგენის დაჩქარება#

აღდგენა არის insert-ების ძალიან გრძელი სერია, რასაც მოჰყვება ინდექსების აგების ძალიან გრძელი სერია, ნაგულისხმევი კონფიგურაცია კი დაყენებულია სერვერისთვის, რომელიც query-ებს პასუხობს და არა ამისთვის. სამიზნეზე, მხოლოდ ამ დროისთვის:

ALTER SYSTEM SET maintenance_work_mem = '1GB';ALTER SYSTEM SET max_wal_size = '8GB';ALTER SYSTEM SET synchronous_commit = 'off';SELECT pg_reload_conf();

maintenance_work_mem არის ის, რასაც ინდექსების აგება და დალაგება იყენებს, და ის ყველაზე დიდი ბერკეტია. max_wal_size აღდგენას ხელს უშლის, ყოველ რამდენიმე წამში checkpoint გამოიწვიოს. synchronous_commit = off ნიშნავს, რომ აღდგენის შუაში crash-მა უახლესი commit-ები შეიძლება დაკარგოს, რაც არ აქვს მნიშვნელობა, რადგან აღდგენას ისედაც თავიდან დაიწყებდი. დაბრუნე ისინი უკან და მთელ ბაზაზე გაუშვი ANALYZE:

$ vacuumdb --analyze-only --jobs=4 --dbname=app_restore

სამიზნის ზომაც რეალისტურად შეარჩიე. აღდგენას სჭირდება ადგილი მონაცემებისთვის, ინდექსებისთვის და მათი აგებისას გენერირებული write-ahead ლოგისთვის, რაც dump-ის შეუკუმშავი ზომის ორ-სამჯერ მეტს ნიშნავს. 20 GB გეგმაზე ეს შეზღუდვაა, რომელსაც ჯერ შეხვდები, და ბაზის სერვერი, რომლის დისკიც ივსება, ჩაწერებს აღარ იღებს.

Dump-ების დაგეგმვა და იმის დამტკიცება, რომ ერთი აღდგება#

Dump, რომელიც არავის აღუდგენია, ჰიპოთეზაა. რუტინა, რომელიც მას backup-ად აქცევს:

1. Dump ღამით აიღე, საათზე, როცა აპლიკაცია მშვიდადაა, ფაილის სახელში თარიღით.
2. გადაიტანე ის მანქანის გარეთ, საიდანაც მოვიდა. dump, რომელიც ბაზის იმავე დისკზე დევს, გიცავს DROP TABLE-სგან და სხვა არაფრისგან.
3. შეინახე შვიდი ყოველდღიური, ოთხი ყოველკვირეული და რამდენიც შენი ვალდებულებები მოითხოვს ყოველთვიური. გაწმინდე ავტომატურად, რადგან ხელით წმენდა სავსე დისკით მთავრდება.
4. კვარტალში ერთხელ აღადგინე ყველაზე ახალი დროებით ბაზაში, დათვალე row-ები სამ შენთვის მნიშვნელოვან ცხრილში, მიუთითე აპლიკაციის ასლი მასზე და წაშალე.

RE:NODE-ზე Schedules ჩანართი იღებს cron გამოსახულებას და ასრულებს მიმდევრობით დავალებებს მათ შორის დაყოვნებებით - backup, power action, კონსოლის ბრძანება - ამიტომ ამის ღამის ნახევარი კონფიგურაციაა და არა სკრიპტი, რომლის ცოცხლად შენახვაც გიწევს. Backup slot-ები ყველა ბაზის გეგმას მოჰყვება, backup-ები იღება მოთხოვნით ან განრიგით, ინახება იმ მანქანის გარეთ, რომელსაც იცავს, აღდგება ღილაკით, ჩამოიტვირთება და იკეტება, რომ როტაციამ ის არ წაშალოს, რომელიც გიყვარს. ორი რამ, რაც დასამახსოვრებელია: სერვერის წაშლა მის backup-ებს შლის, ჩაკეტილებსაც, და ჩამოტვირთული pg_dump არქივი ერთადერთი ასლია, რომელიც სხვა ჰოსტზე გადატანადია. შეინახე ორივე. Backup-ები, რომლებიც მართლა აღდგება და აღდგენის ტესტირება, სანამ დაგჭირდება საქმეს უფრო ვრცლად ასაბუთებს, პანელის გზამკვლევები კი აჩვენებს, სად არის ღილაკები.

შეცდომები, რომლებსაც რეალურად შეხვდები#

`pg_dump: error: aborting because of server version mismatch` - შენი pg_dump სერვერზე ძველია. დააყენე შესაბამისი კლიენტის ინსტრუმენტები; ნუ აიძულებ.

`pg_restore: error: input file appears to be a text format dump. Please use psql.` - plain dump გააკეთე და არასწორი ინსტრუმენტი აიღე. გაუშვი psql -f.

`role "someone" does not exist` - აღადგინე dump, რომელიც მფლობელობას ან grant-ებს შეიცავს, კლასტერში ამ როლების გარეშე. ჯერ გლობალური ობიექტები აღადგინე, ან ხელახლა აიღე dump --no-owner --no-privileges-ით.

`permission denied for schema public` - PostgreSQL 15-დან public სქემა აღარ აძლევს ყველა როლს მასში ობიექტების შექმნის უფლებას. მიანიჭე ის აღმდგენ როლს აშკარად, ან ეს როლი ბაზის მფლობელად გახადე.

`ERROR: relation "orders" already exists` - აღდგენა ბაზაზე, რომელიც ცარიელი არ არის. გამოიყენე ახალი ბაზა, ან --clean --if-exists.

`could not execute query: ERROR: extension "pg_trgm" is not available` - extension-ის ფაილები სამიზნე მანქანაზე დაყენებული არ არის. დააყენე პაკეტი და აღდგენა თავიდან დაიწყე.

აღდგენა, რომელიც წარმატებულია და აპლიკაციას გატეხილს ტოვებს - თითქმის ყოველთვის დაკარგული sequence-ები ან დაკარგული grant-ები, -t dump-იდან, რომელმაც ცხრილი აიღო და მასზე მიმაგრებული არაფერი.

FAQ#

ბლოკავს pg_dump ჩემს ცხრილებს ან თიშავს ბაზას?

არა. ის ყოველ ცხრილზე იღებს ACCESS SHARE lock-ს, რომელსაც მკითხველები და მწერლები უგულებელყოფენ. მხოლოდ ინსტრუქციებს, რომლებსაც ACCESS EXCLUSIVE lock სჭირდებათ, როგორიცაა ALTER TABLE ან TRUNCATE, უწევთ ლოდინი. ბაზა მთელი დროის განმავლობაში ჩვეულებრივ ემსახურება ტრაფიკს.

შემიძლია dump-ის აღდგენა PostgreSQL-ის სხვა ვერსიაში?

იმავე major ვერსიაში ან უფრო ახალში - დიახ, და ეს განახლების სტანდარტული გზაა. უფრო ძველ major ვერსიაში - არა. როცა წინ მიგრირებ, უფრო ახალი სერვერის pg_dump გამოიყენე ძველის წასაკითხად.

რა განსხვავებაა pg_dump-სა და pg_dumpall-ს შორის?

pg_dump ერთ ბაზას ამუშავებს და შეუძლია შეკუმშული, შერჩევით აღდგენადი არქივების ჩაწერა. pg_dumpall კლასტერის ყველა ბაზას გადის და მხოლოდ plain SQL-ის ჩაწერა შეუძლია. პრაქტიკაში როლებისა და tablespace-ებისთვის pg_dumpall --globals-only-ს იყენებ, ხოლო თითო ბაზისთვის pg_dump-ს.

რამდენ ხანს უნდა გასტანოს dump-მა?

დაახლოებით იმდენს, რამდენიც მთელი ბაზის დისკიდან წაკითხვას სჭირდება, პლუს კომპრესია. რამდენიმე გიგაბაიტი NVMe-ზე ერთი-ორი წუთია. თუ ბევრად მეტს გრძელდება, ჩვეული მიზეზებია დატვირთული CPU, plain ფორმატი ნელ კომპრესორში pipe-ით, ან დიდი ობიექტებით სავსე ცხრილი.

pg_dump გამოვიყენო თუ ჩემი ჰოსტის backup ღილაკი?

ორივე. პლატფორმის backup სწრაფად იღება და სწრაფად აღდგება ადგილზე, და სერვერის წაშლისას ქრება. ჩამოტვირთული pg_dump არქივი უფრო ნელია, მაგრამ პორტატულია, ვერსიების მიმართ შემწყნარებელია და შენია. ისინი სხვადასხვანაირად ვარდება, რაც ორის ქონის მთელი არგუმენტია.

ჩემი აღდგენილი ბაზა ორიგინალზე ბევრად ნელია. რატომ?

იმიტომ, რომ სტატისტიკა dump-ის ნაწილი არ არის, ამიტომ planner ყოველ ცხრილზე ხვდება, სანამ ANALYZE-ს არ გაუშვებ. ყოველი აღდგენის ბოლო ნაბიჯად მთელ ბაზაზე გაუშვი vacuumdb --analyze-only და განსხვავება ჩვეულებრივ ქრება.