የአገልጋይ ዲስክ 100% ሙሉ (0 ባይት ነፃ)፡ የተበላሸ ዳታቤዝ መቼ መልሶ ማግኘት rm እና apt የ Inodes/Space እጥረት አለመሳካት።¶

የምርት ሊኑክስ አገልጋይ እንደደረሰ በማወቅ ላይ 100% የዲስክ አጠቃቀም (0 bytes free) ወይም 100% የኢኖድ አጠቃቀም (df -i) ገባሪ PostgreSQL፣ MySQL/InnoDB፣ MariaDB ወይም SQLite ዳታቤዝ በስርዓት አስተዳደር ውስጥ ካሉት በጣም አደገኛ የውድቀት ሁነታዎች አንዱ ነው። በዜሮ ባይት ወይም በዜሮ ነፃ ኢንኖዶች፣ ቀውሱ በፍጥነት ይሸጋገራል፡ የስርዓተ ክወናው ከርነል ከአሁን በኋላ የዩኒክስ ዶሜይን ሶኬቶችን መፍጠር አይችልም። /tmp ወይም /var/run, bash ጊዜያዊ የሼል ቧንቧዎችን መፃፍ ስለማይችል ትር ማጠናቀቅ አልቻለም, apt ወይም dnf ፓኬጆችን ለማጽዳት መሮጥ አይችልም ምክንያቱም የጥቅል አስተዳዳሪዎች ጊዜያዊ የመቆለፊያ ፋይሎች ስለሚያስፈልጋቸው እና የውሂብ ጎታዎ ሞተር በጽሑፍ ወደፊት ምዝግብ ማስታወሻ መካከል ይወድቃል (WAL) አንድ 4 ኪሎባይት (0.004 ሜጋባይት) ብሎክ መመደብ ስለማይችል በንጽህና ለመዝጋት ፈቃደኛ አልሆነም .pid ወይም የመቆለፊያ ፋይል. ይባስ ብሎ፣ የተደናገጡ አስተዳዳሪዎች ብዙ ጊዜ ይሮጣሉ rm -rf /var/log/*.log በባለብዙ ጊጋባይት ሎግ ፋይሎች ላይ እና በአስፈሪ ሁኔታ ይመልከቱ df -h አሁንም ሪፖርት ያደርጋል 100% Use% (0 Avail) ወይም በሞት ይሰርዛሉ pg_wal (pg_xlog) ወይም ib_logfile0 ቦታ ለማስለቀቅ፣ ከግብይት ማገገም ባለፈ የውሂብ ጎታውን በቋሚነት ያበላሻል። በማጽዳት ሙከራ ወቅት ወሳኝ የሆኑ የውሂብ ጎታ ፋይሎችን በድንገት ከሰረዙ ወዲያውኑ ያቁሙ እና ወደዚህ ይቀይሩ ድንገተኛ rm -rf ወይም Shift-Delete ተነባቢ-ብቻ ዳግም መጫን እና inode መቅረጽ; የእርስዎ የስር ማከማቻ ሃርድዌር የI/O ስህተቶችን እየጣለ ከሆነ ወይም እራሱን ከጽሁፎች ላይ ከቆለፈ፣ ያማክሩ SSD እና NVMe ድንገተኛ ተነባቢ-ብቻ ሁነታ እና TRIM ማዳንን ያሰናክላል ወይም የተበላሸ የ Word፣ Excel፣ PDF እና የውሂብ ጎታ ፋይል መልሶ ማግኛ. ይህ መቋረጥ የሆስፒታል ህይወት-ደህንነት ስርዓቶችን፣ የአደጋ ጊዜ መላኪያን ወይም ወሳኝ የህዝብ መገልገያዎችን የሚጎዳ ከሆነ፣ ወደ አካባቢዎ የድንገተኛ አደጋ ቁጥር ይደውሉ (911 በዩናይትድ ስቴትስ እና በካናዳ, 112 በመላው አውሮፓ ህብረት ፣ 999 በዩናይትድ ኪንግደም) ወይም የእኛን ዓለም አቀፍ ማውጫ ይመልከቱ የአደጋ ጊዜ ቁጥሮች.

ይህንን አሁን ያድርጉ¶

1. ** አትሰርዝ pg_wal/, pg_xlog/, pg_multixact/, ib_logfile*, undo_*, ወይም -wal / -shm ቦታዎችን ለመስራት ፋይሎች**፡- የመጻፊያ ሎግ መሰረዝ ወይም InnoDB የምዝግብ ማስታወሻ ፋይሎችን መድገም/መቀልበስ ዳታቤዝ ሲበላሽ ወይም ሳይፈተሽ የቀሩ እና በበረራ ላይ ያሉ ገጾችን ብቸኛ ሪከርድ ያጠፋል። ሙሉ ዲስክ ያለው የውሂብ ጎታ ቦታ ከተለቀቀ በኋላ 100 በመቶ መልሶ ማግኘት ይቻላል; የWAL ፋይሎች በእጅ የተሰረዙ የውሂብ ጎታ rm የማይቀለበስ ቢ-ዛፍ እና ክምር ሙስና ይሰቃያል።
2. ** ከዲስክ ብሎኮች ውጭ መሆንዎን በ 5 ሰከንድ ውስጥ ይወቁ (df -hከፋይል ስርዓት inodes ውጭ (df -i) ወይም ያልተገናኙ ፋይሎችን በመያዝ (lsof +L1***:
3. ሩጡ df -h የማገጃ አቅምን ለማረጋገጥ እና df -i የኢኖድ አቅምን ለመፈተሽ. 50 ጊጋባይት (53.6 ቢሊዮን ባይት) ነፃ የዲስክ ቦታ ያለው አገልጋይ አሁንም ይጣላል No space left on device (ENOSPC) ከሆነ df -i ያሳያል IUse% = 100% (ብዙውን ጊዜ በሚሊዮኖች በሚቆጠሩ ጥቃቅን ክፍለ-ጊዜዎች፣ መሸጎጫዎች ወይም የደብዳቤ ማጭበርበሪያ ፋይሎች የተከሰተ)።
4. ከሆነ df -h ያሳያል 100% ጥቅም ላይ የዋለ (0 Avail) ከሮጡ በኋላም rm በትላልቅ የሎግ ፋይሎች ላይ, አሂድ sudo lsof +L1. ማንኛውም ፋይል ተሰርዟል። rm እያለ nginx, rsyslog, docker, postgres, ወይም mysqld አሁንም ክፍት የሆነ ፋይል ገላጭ ሂደቱ እንደገና እስኪጀመር ድረስ 100 ፐርሰንት የዲስክ ብሎኮችን መብላቱን ይቀጥላል ወይም ገላጩን በቀጥታ እስኪቆርጡ ድረስ።
5. ** ክፍት ጊጋባይት ቦታ በ1 ሰከንድ ውስጥ የተከፈቱ ፋይሎችን በቦታቸው በመቁረጥ ዴሞንን እንደገና ሳይጀምሩ: > /path/to/logfile ወይም : > /proc/<pid>/fd/<n>***:
6. ይልቅ rm /var/log/syslog (በሮጫ ሎገር የተቆለፉትን ብሎኮች የሚተው)፣ የሼል null አቅጣጫውን በመጠቀም ፋይሉን ዜሮ ማድረግ፡- sudo sh -c ': > /var/log/syslog' ወይም sudo truncate -s 0 /var/log/syslog.
7. አስቀድመው ከሮጡ rm በትልቅ የምዝግብ ማስታወሻ ፋይል እና df -h አልወደቀም ፣ የሂደቱን መታወቂያ አግኝ (PID) እና የፋይል ገላጭ (FD) ውስጥ sudo lsof +L1 እና በቀጥታ በ kernel procfs በይነገጽ በኩል ይከርክሙት፡ sudo sh -c ': > /proc/<PID>/fd/<FD>'. ቦታ ወደ ይመለሳል df -h በቅጽበት.
8. ** ፈጣን የአደጋ ጊዜ መተንፈሻ ክፍልን ይክፈቱ ext4 / ext3 የተያዘውን የስር ማገጃ መቶኛ ዝቅ በማድረግ (tune2fs -m 1***: በነባሪ, ext4 ከጠቅላላው ክፍል 5 በመቶውን ይይዛል (25 gigabytes በ ሀ 500 gigabyte ዲስክ) ብቻ ለ UID 0 (root)) ማለት ሥር ነክ ያልሆኑ አገልግሎቶች እንደ ማለት ነው። postgres (UID 109), mysql, እና www-data መምታት No space left on device በ 95 በመቶ አጠቃቀም. 80 ከመቶ ያህሉን በ1 ሰከንድ ውስጥ በመስመር ላይ ከዜሮ ማቆያ ጊዜ ጋር በመሮጥ ያስመልሱ sudo tune2fs -m 1 /dev/sda1 (ወይም የ root block መሣሪያዎ ከ findmnt /).
9. ** ቫክዩም systemd-journald ሁለትዮሽ ምዝግብ ማስታወሻዎች እና የድሮ ጥቅል መሸጎጫዎች ደህንነቱ በተጠበቀ ሁኔታ ***: አሂድ sudo journalctl --vacuum-size=50M (ይህም በደህና ይሽከረከራል እና ሁለትዮሽ ያጸዳል። /var/log/journal ማህደሮች እስከ 50 ሜጋባይት) እና sudo apt-get clean (ወይም sudo dnf clean allየወረደውን የሚሰርዝ .deb / .rpm ማህደሮች ውስጥ /var/cache/apt/archives/ ወደ dpkg የውሂብ ጎታ መጻፍ ሳያስፈልግ.
10. ** አንድ ጊዜ ቢያንስ 1 ጊጋባይት እስከ 5 ጊጋባይት (ከ1.07 ቢሊዮን እስከ 5.36 ቢሊዮን ባይት) ቦታ ነፃ ከሆነ፣ የደንበኛ ትራፊክን ከመፍቀዱ በፊት ዳታቤዙን በአንድ ተጠቃሚ ወይም በመልሶ ማግኛ ሁኔታ ያቅርቡ።WAL), የቆሸሹ ገጾችን ወደ ዋና የውሂብ ፋይሎች ያጥፉ እና የ ‹WAL› ክፍሎቹን አፕሊኬሽኑን ፋየርዎል ወይም ድር አገልጋይዎን እንደገና ከመክፈትዎ በፊት በንጽህና እንደገና ጥቅም ላይ ይውላሉ።

የውሳኔ ዛፍ፡- ዜሮ ቦታ አገልጋይ እና የተበላሸ የውሂብ ጎታ ልዩነት¶

ስርዓተ ክወናው ለምን ሪፖርት እንደሚያደርግ ለመለየት ይህንን የውሳኔ ዛፍ ይጠቀሙ ENOSPC (No space left on device) እና ትክክለኛውን የመልሶ ማግኛ መንገድ ይምረጡ፡-

flowchart TD
    Start["አገልጋይ ወይም ዳታቤዝ መወርወር፡ በመሳሪያው ላይ ምንም ቦታ አልቀረም (ENOSPC)"] --> CheckDF["አሂድ: df -h AND df -i"]

    CheckDF --> DiagType{"ዲኤፍ ምን ሪፖርት ያደርጋል?"}

    DiagType -->|"df -h 100% አጠቃቀምን ያሳያል (0 Avail) እና df -i < 95%"| BlockFull["መሟጠጥን አግድ፡ du -shx/ተዛማጆች df -h ከሆነ ያረጋግጡ"]
    DiagType -->|"df -h ነፃ GBs ያሳያል ግን df -i 100% IUse ያሳያል"| InodeFull["የኢኖድ ድካም፡ በሚሊዮኖች የሚቆጠሩ ጥቃቅን ከ0 እስከ 4 ኪባ ፋይሎች"]
    DiagType -->|"ሁለቱም df -h እና df -i አሳይ <90% ጥቅም ላይ ይውላሉ"| RamOrQuota["የተደበቀ ገደብ፡ df -h/tmp (tmpfs RAM ሙሉ)፣ Docker Overlay2 ወይም XFS/ext4 Disk ኮታዎችን ያረጋግጡ"]

    BlockFull --> GhostCheck{"ዲኤፍ ሳይወርዱ በትልቁ ፋይሎች ላይ rm ቀድመህ አሂድ ነበር?"}
    GhostCheck -->|"አዎ፡ du ከዲኤፍኤፍ በጣም ያነሰ ነው።"| UnlinkedFD["አሂድ፡ sudo lsof +L1 -> Ghost ፋይልን በ: > /proc/PID/fd/FD ቁረጥ"]
    GhostCheck -->|"አይ፡ እውነተኛ ፋይሎች ዲስክ እየሞሉ ነው።"| EmergencySpace["አፋጣኝ የመተንፈሻ ክፍል ይፍጠሩ (ከ1 ጊባ እስከ 5 ጂቢ)"]

    EmergencySpace --> Ext4Check{"የፋይል ስርዓት ext4/ext3 ነው?"}
    Ext4Check -->|"አዎ"| Tune2fs["አሂድ፡ sudo tune2fs -m 1 /dev/root_dev (ስርወ-ዲቢ ላልሆነ ተጠቃሚ 4% ዲስክን ወዲያውኑ ነፃ ያወጣል)"]
    Ext4Check -->|"የለም (XFS/Btrfs/ZFS)"| TruncLogs["Truncate Logs In-Place (: > /var/log/syslog) እና Run journalctl --vacuum-size=50M"]

    InodeFull --> InodeClean["Find / -xdev -printf '%h\n' በመጠቀም ማውጫ በሚሊዮኖች የሚቆጠሩ ፋይሎችን ያግኙ | መደርደር | uniq -c | መደርደር -k 1 -r | head -20 -> አግኝ -ሰርዝ ጋር ሰርዝ"]

    UnlinkedFD --> DBRecover["ወደ የውሂብ ጎታ ሞተር WAL እና B-Tree Recovery ይቀጥሉ"]
    Tune2fs --> DBRecover
    TruncLogs --> DBRecover
    InodeClean --> DBRecover
    RamOrQuota --> DBRecover

    DBRecover --> WhichDB{"የትኛው የመረጃ ቋት ሞተር ተበላሽቷል?"}
    WhichDB -->|"PostgreSQL"| PGFlow["Pg_wal ያልተነካ አቆይ -> ዋልን ለመድገም ጀምር Postgres -> ቼክፖይንትን አሂድ፤ -> የቆየ መባዛት ቁማር ጣል"]
    WhichDB -->|"MySQL / MariaDB (InnoDB)"| MyFlow["ib_logfile* ያልተነካ አቆይ -> mysqld ጀምር -> ሁለትዮሽ ምዝግብ ማስታወሻዎችን በPURGE ሁለትዮሽ ሎግስ ያጽዱ -> ሰንጠረዦችን ያመቻቹ"]
    WhichDB -->|"SQLite3"| SqFlow["ምትኬ .db + .db-wal + .db-shm -> PRAGMA wal_checkpoint(TRUNCATE) ወይም sqlite3 broken.db አሂድ '.recover'"]

ደረጃ 1፡ ለምን መደበኛ ትዕዛዞችrm, apt, tab-completion) በ0 ባይት ነፃ¶

የሊኑክስ ክፍልፍል 100 በመቶ ብሎክ ወይም የኢኖድ ድካም ሲመታ፣ መደበኛ የማሻሻያ ትዕዛዞች ባልተጠበቁ መንገዶች አይሳኩም፡ - ** በመጫን ላይ Tab ውስጥ bash ይጥላል cannot create temp file for here-document: No space left on device**: ዘመናዊ bash-completion ስክሪፕቶች ጊዜያዊ ፋይሎችን ይፈጥራሉ /tmp. ከሆነ /tmp ሥሩ ላይ ይኖራል / ክፍልፍል ከ ሀ tmpfs RAM mount, ሼል ማጠናቀቅ እና heredocs (<<EOF) አልተሳካም። ይህንን ወዲያውኑ በመጠቆም ያስተካክሉት። TMPDIR ለጋራ ማህደረ ትውስታ RAM;

export TMPDIR=/dev/shm

sudo find /var/lib/php/sessions -type f -delete

5ቱ ልዩ ምክንያቶች No space left on device (ENOSPC)¶

ማንኛውንም የውሂብ ጎታ ፋይሎችን ከመንካትዎ በፊት፣ ምን አይነት ሃብት በትክክል እንደደከመ ለማረጋገጥ እነዚህን አምስት ሁኔታዎች ያወዳድሩ።

ደረጃ 2፡ ከ60 ሰከንድ ባነሰ ጊዜ ውስጥ የዲስክ ቦታን በአስተማማኝ ሁኔታ ማስመለስ¶

ንቁ ሂደቶችን ሳይበላሹ ከ 500 ሜጋባይት እስከ 50 ጊጋባይት (0.53 ቢሊዮን እስከ 53.6 ቢሊዮን ባይት) ቦታን ለማስመለስ እነዚህን ትክክለኛ ደረጃዎች ይከተሉ።

ደረጃ 1፡ የተሰረዙ ("ghost") ፋይሎችን በክፍት ይቁረጡ /proc/<pid>/fd/¶

እርስዎ ወይም አውቶሜትድ የሎግሮቴት ስክሪፕት ትልልቅ ፋይሎችን ከሰረዙ ነገር ግን የዲስክ ቦታ ካልተመለሰ የከርነሉን ያልተገናኘ ክፍት የፋይል ሰንጠረዥ ይመልከቱ፡

sudo lsof +L1

COMMAND    PID     USER   FD   TYPE DEVICE    SIZE/OFF NLINK    NODE NAME
mysqld    1942    mysql    6u   REG  259,1 34896609280     0  918273 /tmp/ibXz91aB (deleted)
rsyslogd   612   syslog    7w   REG  259,1 18253611008     0  131092 /var/log/syslog.1 (deleted)

sudo sh -c ': > /proc/612/fd/7'

ደረጃ 2፡ መልሰው ይጠይቁ ext4 ጋር በመስመር ላይ የተያዙ ብሎኮች tune2fs¶

በማንኛውም ላይ ext4 ወይም ext3 የፋይል ስርዓት፣ አሁን ያለውን የተከለለ የማገጃ ብዛት ያረጋግጡ፡-

df -h /
sudo tune2fs -l /dev/nvme0n1p1 | grep -i "reserved block"

sudo tune2fs -m 1 /dev/nvme0n1p1

ደረጃ 3፡ ንቁ የጽሁፍ ምዝግብ ማስታወሻዎችን በቦታቸው ይቁረጡ እና ባዶ ያድርጉ journald¶

በስር ፋይል ስርዓቱ ላይ ትልቁን ፋይሎች ያግኙ (በተመሳሳዩ የፋይል ስርዓት ከ ጋር መቆየት -xdev ስለዚህ ለመቃኘት ጊዜ አያባክኑም። /proc ወይም ውጫዊ መጫኛዎች):

sudo find / -xdev -type f -size +100M -exec ls -lh {} + 2>/dev/null | sort -k 5 -hr | head -n 25

sudo truncate -s 0 /var/log/nginx/error.log
sudo truncate -s 0 /var/lib/docker/containers/*/*-json.log

sudo journalctl --vacuum-size=50M

ደረጃ 3፡ ከ100% ዲስክ ሙሉ ብልሽት በኋላ PostgreSQLን በማገገም ላይ (pg_wal እብጠት)¶

የ PostgreSQL አገልጋይ የዲስክ ቦታ ሲያልቅ ይመዘግባል PANIC: could not write to file "pg_wal/xlogtemp.1234": No space left on device, ወዲያውኑ የፖስታ ማስተር ልጅ ሂደቶችን ያስወግዳል, እና ለመጀመር ፈቃደኛ አይሆንም.

ለምን? pg_wal (pg_xlog በ PostgreSQL 9.6 እና ከዚያ በላይ) ሙሉውን ዲስክ ይሞላል¶

በመደበኛ አሠራር PostgreSQL እያንዳንዱን ለውጥ ወደ 16 ሜጋባይት (16.7 ሚሊዮን ባይት) የውስጥ ፋይሎች ይጽፋል $PGDATA/pg_wal/ እና ከእያንዳንዱ በኋላ እንደገና ጥቅም ላይ ይውላሉ CHECKPOINT አንዴ ካለፈ max_wal_size. ሆኖም፣ PostgreSQL ** አሮጌውን ከመሰረዝ ወይም እንደገና ጥቅም ላይ እንዳይውል የተከለከለ ነው። pg_wal ፋይሎች *** በሶስት ሁኔታዎች: 1. ** ወላጅ አልባ ወይም የዘገየ አካላዊ/ሎጂካዊ ማባዛት ማስገቢያ**፡ የተባዛ አገልጋይ (standby), Debezium/Kafka አያያዥ, ወይም pg_receivewal ደንበኛ ከቀናት በፊት ግንኙነቱ ተቋርጧል፣ ነገር ግን የማባዛት ቦታው (pg_replication_slots) አሁንም ነው። active = false በመጀመሪያ ደረጃ፣ ግንኙነቱ ከተቋረጠ በኋላ የተፈጠረውን እያንዳንዱን የWAL ክፍል እንዲይዝ PostgreSQL በማዘዝ። 2. ** አልተሳካም። archive_command**: archive_mode = on ውስጥ ነቅቷል። postgresql.confእና የመጠባበቂያ ስክሪፕት (pgBackRest, WAL-G, Barman, ወይም aws s3 cp) ዜሮ ያልሆነ የመውጫ ኮድ እየመለሰ ነው (ለምሳሌ ጊዜው ያለፈበት S3 ቁልፍ ወይም የማይደረስ የመጠባበቂያ አስተናጋጅ)። PostgreSQL በማህደር ያልተመዘገበውን እያንዳንዱን የWAL ክፍል ያስቀምጣል። pg_wal/ ድረስ archive_command ይመለሳል 0. 3. በዲስክ የተሞላ መቆለፊያ pg_wal ድረስ አድጓል። 0 bytes ላይ ቆየ /var/lib/postgresql, እና አሁን PostgreSQL የማባዛት ክፍተቱን መጣል ወይም የፍተሻ ነጥብ ማጠናቀቅ እንኳን አይችልም ምክንያቱም ጅምር መልሶ ማግኛ ጊዜያዊ ፋይሎችን ለመፃፍ ብዙ ሜጋባይት ነፃ የዲስክ ቦታ ይፈልጋል።

ደረጃ በደረጃ PostgreSQL ዜሮ-ክፍተት ማዳን (ዜሮ የውሂብ መጥፋት)¶

1. ** ከ 1 ጊጋባይት እስከ 5 ጊጋባይት (1.07 ቢሊዮን እስከ 5.36 ቢሊዮን ባይት) ጊዜያዊ ቦታ ፍጠር ውጭ pg_wal/**:
2. መጀመሪያ መጠቀም sudo tune2fs -m 0 /dev/<partition> እና ስርዓት/PostgreSQL የጽሑፍ ምዝግብ ማስታወሻዎችን ይቁረጡ (sudo truncate -s 0 /var/lib/postgresql/*/main/log/*.log ወይም /var/log/postgresql/*.log).
3. ** የመረጃ ቋቱ የራሱ የሆነ ክፍል ከዜሮ የጽሑፍ ምዝግብ ማስታወሻዎች እና XFS ጋር ቢኖረውስ (ስለዚህ tune2fs አይገኝም)?** ከመጀመሪያዎቹ* ከ10 እስከ 20 ያንቀሳቅሱ .ready ወይም የቦዘኑ ፋይሎች WAL ካልሆኑ ማውጫ ውስጥ ወጥተዋል፣ ወይም ዝርዝሩን ወደ ሌላ ቦታ ያስተላልፉ pg_wal ምሳሌያዊ ማገናኛን በመጠቀም ነፃ ቦታ ወዳለው ለሌላ ክፍልፍል ማውጫ ለጊዜው፡-

   # ONLY while PostgreSQL is completely stopped (verify with: ps aux | grep postgres)
   sudo mkdir -p /mnt/extra_space/pg_wal_rescue
   sudo chown -R postgres:postgres /mnt/extra_space/pg_wal_rescue
   sudo mv /var/lib/postgresql/16/main/pg_wal/* /mnt/extra_space/pg_wal_rescue/
   sudo rmdir /var/lib/postgresql/16/main/pg_wal
   sudo ln -s /mnt/extra_space/pg_wal_rescue /var/lib/postgresql/16/main/pg_wal
   sudo chown -h postgres:postgres /var/lib/postgresql/16/main/pg_wal
   

4. ** ከሆነ archive_command እየወደቀ ነው እና የWAL መልሶ ጥቅም ላይ ማዋልን እየከለከለ ነው፣ ለጊዜው አልፈውታል። postgresql.conf**: የእርስዎ S3/የምትኬ ኢላማ ከወረደ እና pg_wal/archive_status/ በሺዎች የሚቆጠሩ ይዟል .ready ፋይሎች, አርትዕ postgresql.conf (archive_command = '/bin/true') እንደ የመጨረሻ ሪዞርት የአደጋ ጊዜ እርምጃ ብቻ ዲስኩን እንዳይሞት ለማድረግ አዲስ መውሰድ እንዳለቦት በማወቅ pg_basebackup ወዲያውኑ ካገገመ በኋላ የWAL ማህደር ሰንሰለት ክፍተት ይኖረዋል።
5. ** PostgreSQL ይጀምሩ እና ወዲያውኑ የማባዛት ቦታዎችን ይመርምሩ ***: PostgreSQL ጀምር (sudo systemctl start postgresql) እና በ በኩል ይገናኙ sudo -u postgres psql:

   SELECT slot_name, plugin, slot_type, active,
          pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn)) AS retained_wal
   FROM pg_replication_slots;
   

6. ** ጊጋባይት ዋልን እያጠራቀመ ያለ የሞተ/የቦዘነ የማባዛት ማስገቢያ ጣል*። የቦዘነ ማስገቢያ ካዩ (active = f) 80 ጊጋባይት ይይዛል retained_wal:

   SELECT pg_drop_replication_slot('name_of_dead_slot');
   

7. ** ወዲያውኑ አስገድድ CHECKPOINT የተበሳጨውን እንደገና ጥቅም ላይ ለማዋል pg_wal ክፍሎች ***

   CHECKPOINT;
   

   ቅፅበት CHECKPOINT; የሞተውን ቦታ ከጣለ በኋላ ያበቃል፣ PostgreSQL በራስ-ሰር ግንኙነቱን ያቋርጣል ወይም ጊጋባይት የድሮ 16 ሜጋባይት ክፍል ፋይሎችን እንደገና ይጠቀማል። pg_wal/, የእርስዎን የዲስክ አጠቃቀም ወደ መደበኛው መመለስ.
8. **ወደፊት መባዛት ማስገቢያ ዲስክ ሞት መከልከል ***: አዘጋጅ max_slot_wal_keep_size ውስጥ postgresql.conf (በPostgreSQL 13+ ውስጥ ይገኛል) ወደ ደህና ካፕ (እንደ፡ max_slot_wal_keep_size = 20GB) ስለዚህ PostgreSQL ዋናውን ዳታቤዝ በ0 ባይት በነፃ ከማሰናከል ይልቅ የሞተ ብዜት ክፍተትን ዋጋ ያሳጣዋል።

ደረጃ 4፡ MySQL / MariaDBን መልሶ ማግኘት (InnoDB) በ0 ባይት ነፃ¶

MySQL ወይም MariaDB ሲመታ 100% የዲስክ አጠቃቀም (/var/lib/mysql), InnoDB ሁሉንም ይጽፋል ወይም ይበላሻል [ERROR] [MY-012640] [InnoDB] Error number 28 means 'No space left on device'.

የተሞላውን መለየት /var/lib/mysql¶

ሩጡ sudo du -sh /var/lib/mysql/* | sort -hr | head -n 15 ከእነዚህ አራት ወንጀለኞች መካከል የትኛው ዲስኩን እንደበላው ለማየት፡- 1. ** ያልተገደቡ ሁለትዮሽ ምዝግብ ማስታወሻዎች (binlog.000001, mysql-bin.000042: በነባሪ በ MySQL 8.0+ ውስጥ፣ የሁለትዮሽ ምዝግብ ማስታወሻ በ30 ቀን ማቆየት ነቅቷል (binlog_expire_logs_seconds = 2592000በጅምላ ወደ ሀገር ውስጥ በሚገቡበት ጊዜ በመቶዎች የሚቆጠሩ ጊጋባይት ተከታታይ ክስተቶችን በቀላሉ ሊያመነጭ ይችላል። 2. ** የሸሸ ጥያቄ ግዙፍ ጊዜያዊ ጠረጴዛዎችን በመጻፍ (#sql* ወይም ibtmp1: ግዙፍ GROUP BY ወይም ORDER BY ጥያቄ ተሞልቷል። ibtmp1 ወይም /tmp/#sql_* ዲስኩ 0 ባይት እስኪመታ ድረስ። 3. ** ሞኖሊቲክ ibdata1 የስርዓት የጠረጴዛ ቦታ እብጠት *: ከሆነ innodb_file_per_table ተሰናክሏል ወይም ለረጅም ጊዜ የቆዩ ግብይቶች የ InnoDB ታሪክ ዝርዝሩን ከልክለዋል (ውስጥ ምዝግብ ማስታወሻዎችን ይቀልብሱ ibdata1 ወይም undo_001) ከማጽዳት። 4. ** MySQL የዘገየ መጠይቅ ምዝግብ ማስታወሻ ወይም የስህተት መዝገብ/var/log/mysql/mysql-slow.log)።

ደረጃ በደረጃ MySQL / MariaDB ዜሮ-ክፍተት ማዳን¶

1. ** በጭራሽ አይሰርዝ ibdata1, ib_logfile0, ib_logfile1, #innodb_redo/*, ወይም undo_001 ጋር rm** ከእነዚህ ፋይሎች ውስጥ ማናቸውንም መሰረዝ ሁሉንም ያደርገዋል .ibd በመረጃ ቋትዎ ውስጥ ያለው የሰንጠረዥ ፋይል ሊነበብ አይችልም።
2. ** ነፃ የመነሻ ቦታ (ከ500 ሜጋባይት እስከ 2 ጊጋባይት)**፡
3. መቆራረጥ /var/log/mysql/error.log እና mysql-slow.log በኩል sudo truncate -s 0 /var/log/mysql/*.log.
4. በርቷል ext4፣ ሩጡ sudo tune2fs -m 1 /dev/<partition>.
5. ከሆነ mysqld በአሁኑ ጊዜ ቆሟል እና /var/lib/mysql/ibtmp1 (ያልተጨመቀ ጊዜያዊ የጠረጴዛ ቦታ) ትልቅ ነው ፣ ibtmp1 በሚነሳበት ጊዜ በራስ-ሰር ይፈጠራል ወይም ** በጣም ጥንታዊውን ሁለት ወይም ሶስት ** ሁለትዮሽ ምዝግብ ማስታወሻዎችን ማንቀሳቀስ ይችላሉ (binlog.000001, binlog.000002 - በጭራሽ ከፍተኛ ቁጥር ያለው ገባሪ ቢንሎግ) ወደ /dev/shm ለጊዜው እንዲሁ mysqld ማስነሳት ይችላል.
6. ** MySQLን ያስጀምሩ እና SQLን በመጠቀም የሁለትዮሽ ምዝግብ ማስታወሻዎችን በደህና ያጽዱ (PURGE BINARY LOGS***: ለምን ይልቅ SQL መጠቀም አለብዎት rm /var/lib/mysql/binlog.*? ምክንያቱም MySQL እያንዳንዱን የሁለትዮሽ መዝገብ ፋይል ስም ይከታተላል binlog.index. የሁለትዮሽ ምዝግብ ማስታወሻዎችን ከሰረዙ rm ሳይዘመን binlog.index, MySQL ለመጀመር ፈቃደኛ አይሆንም ወይም ማባዛት ይሰበራል. አንዴ mysqld ይጀምራል ፣ ይግቡ (sudo mysql) እና ሩጡ:

   SHOW BINARY LOGS;
   PURGE BINARY LOGS BEFORE NOW() - INTERVAL 1 DAY;
   

7. (ወይም ሁሉንም ነገር በታችኛው ክፍል ላይ እስከሚታየው የአሁኑ ንቁ የምዝግብ ማስታወሻ ፋይል ያጽዱ SHOW BINARY LOGS; በመጠቀም PURGE BINARY LOGS TO 'binlog.000085';)*
8. ** ቋሚ የሁለትዮሽ ምዝግብ ማስታወሻ መጠን እና የማቆያ ቆብ ያዘጋጁ /etc/mysql/mysql.conf.d/mysqld.cnf**:

   [mysqld]
   binlog_expire_logs_seconds = 259200   # Keep only 3 days (259,200 seconds)
   max_binlog_size = 256M
   innodb_temp_data_file_path = ibtmp1:12M:autoextend:max:5G
   

   ካፕ ማድረግ ibtmp1 በ max:5G አጭበርባሪው ኢንዴክስ አለመደረጉን ያረጋግጣል JOIN ወይም ORDER BY ጥያቄው ከሀ table is full ከማስፋፋት ይልቅ ስህተት ibtmp1 ሙሉው የሊኑክስ አገልጋይ በ0 ባይት ነፃ እስኪሞት ድረስ።

ደረጃ 5፡ የተበላሸ የSQLite3 ዳታቤዝ መልሶ ማግኘት (database or disk is full / SQLITE_FULL / malformed)¶

የተከተቱ መተግበሪያዎች፣ ዶከር ኮንቴይነሮች (Nextcloud, Vaultwarden, Home Assistant, Plex, Grafana, Gitea), እና የሞባይል/ዴስክቶፕ አገልግሎቶች በSQLite3 ላይ ይመረኮዛሉ። SQLite በመጽሔት መመለሻ ወይም የመጻፊያ መዝገብ መሃል ላይ እያለ አንድ ዲስክ 0 ባይት በነጻ ሲመታ (-wal) የፍተሻ ቦታ፣ ከሁለቱ ድንገተኛ አደጋዎች አንዱን ያጋጥምዎታል፡- 1. ** ግዙፍ .db-wal የፋይል እብጠት *** (የ .db-wal ፋይሉ ወደ 10 ጊጋባይት አድጓል። .db ፋይሉ 200 ሜጋ ባይት ብቻ ነው፣ ምክንያቱም ረጅም ጊዜ የቆዩ አንባቢዎች ተገብሮ የWAL ፍተሻ ስለከለከሉ እና አሁን ዲስኩ 100 በመቶ ሙሉ ነው)። 2. RuntimeError: database disk image is malformed (SQLITE_CORRUPT) በተበላሸ ሃርድዌር የተከሰተ fsync()፣ አንድ ኮንቴይነር በ0 ባይት ነፃ ፣ ወይም የሆነ ሰው የሰረዘውን መሃል መመለስን ተገድሏል። -wal ወይም -journal በእጅ ፋይል.

ደረጃ 1: እብጠትን መቀነስ .db-wal የዲስክ ቦታ ወደ ዜሮ በሚጠጋበት ጊዜ SQLite ፋይል እና ቫክዩም ማድረግ¶

1. የ SQLite ዳታቤዝ ክፍት ሆኖ የመተግበሪያውን መያዣ ወይም አገልግሎት ያቁሙ (sudo systemctl stop app ወይም docker stop container_name).
2. ቅዳ app.db, app.db-wal, እና app.db-shm ብዙ ነፃ ቦታ ወዳለው ክፍልፍል ወይም ውጫዊ አንፃፊ (ወይም መጠኑ 2x ነፃ app.db በመጀመሪያ በአካባቢው ዲስክ ላይ).
3. የውሂብ ጎታውን በ sqlite3 CLI እና ሁሉንም የገቡ ክፈፎች የሚያጠፋውን የWAL ፍተሻ ያስገድዱ app.db-wal ውስጥ app.db እና ይቀንሳል app.db-wal ወደ ** 0 ባይት ***:

   sqlite3 /path/to/app.db "PRAGMA wal_checkpoint(TRUNCATE);"
   

4. ቢ-ዛፍ እና ነፃ ዝርዝር መዋቅራዊ ታማኝነትን ያረጋግጡ፡

   sqlite3 /path/to/app.db "PRAGMA integrity_check;"
   

   ከታተመ okየመረጃ ቋትህ 100 በመቶ ጤናማ ነው።
5. ** እንዴት VACUUM የአካባቢ ዲስክ በቂ ነፃ ቦታ ከሌለው ትልቅ የ SQLite ዳታቤዝ ***: መደበኛ VACUUM; እስከ ** 2x የውሂብ ጎታ መጠን ** በነጻ የዲስክ ቦታ በተመሳሳይ ክፋይ እና /var/tmp. በምትኩ, ተጠቀም VACUUM INTO (በSQLite 3.27.0 ውስጥ የተገለጸ) አዲስ የታመቀ፣ የተበላሸ ቅጂ በቀጥታ ወደተለየ የተገጠመ ዲስክ ወይም የአውታረ መረብ መጋራት ለመፃፍ፡-

   sqlite3 /path/to/app.db "VACUUM INTO '/mnt/external_usb/app_compacted.db';"
   

ደረጃ 2፡ የተበላሸ ቢ-ዛፍ ማዳን (database disk image is malformed) ጋር .recover¶

ከሆነ PRAGMA integrity_check; ሪፖርቶች row 412 missing from index, btreeInitPage() returns error code 11, ወይም database disk image is malformed:

1. ** መጀመሪያ የተበላሹ ሁለተኛ ኢንዴክሶችን እንደገና ለመገንባት ይሞክሩ (REINDEX***: ብዙውን ጊዜ ትክክለኛው የሠንጠረዥ ውሂብ (table B-trees) 100 ፐርሰንት ያልተነካ ነው እና ዲስኩ ሲሞላ ሁለተኛ ደረጃ ጠቋሚ ቢ-ዛፍ ብቻ ተበላሽቷል. አሂድ፡

   sqlite3 /mnt/external_usb/copy_of_app.db "REINDEX;"
   sqlite3 /mnt/external_usb/copy_of_app.db "PRAGMA integrity_check;"
   

   ከሆነ PRAGMA integrity_check; አሁን ይመለሳል ok100 በመቶ የሚሆነውን የውሂብ ጎታህን በዜሮ የጠፉ ረድፎች መልሰዋል።
2. ** ከሆነ REINDEX አልተሳካም፣ የፎረንሲክ ቢ-ዛፍ ስካነርን ያሂዱ (.recover***: ከአሮጌው በተለየ .dump ትዕዛዝ (የተበላሸ ቢ-ዛፍ ጠቋሚን በተመታ ጊዜ ጠረጴዛን ወደ ውጭ መላክ ያቆማል) .recover (የተሰራ sqlite3 ስሪት 3.29.0+) የተበላሸውን የውስጥ ቢ-ዛፍ ጠቋሚዎችን ሙሉ በሙሉ በማለፍ እያንዳንዱን ጥሬ 4 ኪሎባይት ቅጠል ገጽ ከባይት 0 እስከ EOF በቅደም ተከተል ይቃኛል ፣ እያንዳንዱን ሊነበብ የሚችል ረድፍ እንደገና ይገነባል እና ማንኛውንም ወላጅ አልባ መዝገቦችን ያስቀምጣል lost_and_found ጠረጴዛ፡

   sqlite3 /mnt/external_usb/copy_of_app.db ".recover" | sqlite3 /mnt/external_usb/repaired_app.db
   

3. አዲስ የተገነባውን የውሂብ ጎታ ያረጋግጡ፡-

   sqlite3 /mnt/external_usb/repaired_app.db "PRAGMA integrity_check;"
   

   ሀ ከሆነ ያረጋግጡ lost_and_found ሠንጠረዥ ተፈጠረ (sqlite3 /mnt/external_usb/repaired_app.db ".tables") ግንኙነት ከሌላቸው የቅጠል ገጾች የተገኙ ማናቸውንም ወላጅ አልባ ረድፎችን ለመመርመር። ለተመሰጠረ የSQLCipher ዳታቤዝ (እንደ ሲግናል ወይም ዋትስአፕ መጠባበቂያዎች) ልዩ መመሪያችንን ይመልከቱ የተመሰጠረ SQLite፣ ሲግናል እና WhatsApp የውይይት ምትኬ ሙስና እና የአካባቢ ቁልፍ ማውጣት.

ደረጃ 6፡ የአደጋ ጊዜ "Tripwire Ballast File" እና የክትትል መከላከያ ማረጋገጫ ዝርዝር¶

አንዴ አገልጋይዎ እና የውሂብ ጎታዎ መስመር ላይ ከተመለሱ በኋላ በ0 ባይት ነጻ እንዳይያዙ እነዚህን አራት መከላከያዎች ወዲያውኑ ይተግብሩ።

• ** 1 ጊጋባይት ይፍጠሩ (1,073,741,824 ባይት) የአደጋ ጊዜ Ballast ፋይል በእያንዳንዱ የውሂብ ጎታ ክፍልፍል ላይ**፡ አሂድ sudo fallocate -l 1G /var/lib/EMERGENCY_DELETE_ME.ballast. አገልጋዩ መቼም ቢመታ 100% ዲስክ ሙሉ ፣ እየሮጠ sudo rm /var/lib/EMERGENCY_DELETE_ME.ballast በ1 ሚሊሰከንድ ውስጥ 1 ጊጋባይት ተከታታይ ብሎኮችን ነፃ ያወጣል።
• ** ካፕ systemd-journald እና Docker ኮንቴይነር ምዝግብ ማስታወሻዎች በቋሚነት ***: አዘጋጅ SystemMaxUse=200M ውስጥ /etc/systemd/journald.conf እና ማዋቀር /etc/docker/daemon.json ጋር "log-opts": {"max-size": "20m", "max-file": "3"}.
• ** ማግለል። /var/log, /tmp, እና /var/lib/postgresql በተለየ የኤል.ኤም.ኤም ጥራዞች ላይ ***: በማስቀመጥ ላይ /var/log እና /tmp ከዳታ ቤዝ ጥራዞች የተለየ የሸሸ የድር ምዝግብ ማስታወሻ ዳታቤዙን እንደማይሰብር ወይም የኤስኤስኤች መግባቶችን እንደማይዘጋ ያረጋግጣል።
• ** በሁለቱም ላይ ማንቂያ df -h (> 80%) እና df -i (> 80%) ሲደመር pg_replication_slots መዘግየት ***: ክትትልን ያዋቅሩ (node_filesystem_avail_bytes እና node_filesystem_files_free) ጥቅም ላይ የዋለው 85 በመቶ ከማለፉ በፊት ለማስጠንቀቅ።

የክልል የአደጋ ጊዜ ቁጥሮች እና የኤጀንሲ ፕሮቶኮሎች¶

ሙሉ የአገልጋይ ዲስክ በመደበኛነት የውስጥ የአይቲ ኦፕሬሽኖች ድንገተኛ አደጋ ቢሆንም፣ በጤና አጠባበቅ ኤሌክትሮኒክ የጤና መዝገብ ላይ የሚደርሰው መቋረጥ (EHRየውሂብ ጎታዎች፣ የአደጋ ጊዜ መላኪያ (CAD))፣ የማዘጋጃ ቤት ውሃ/ኃይል ቴሌሜትሪ፣ ወይም በህግ የተደነገገው የግል መረጃ መገኘት መደበኛ የአደጋ ጊዜ መጨመር ሊያስፈልገው ይችላል።

• ** ዩናይትድ ስቴትስ እና ካናዳ : ይደውሉ 911 የአገልጋይ ብልሽት ክሊኒካዊ ክትትልን ወይም መላክን ካሰናከለ እና የእረፍት ጊዜ ሂደቶችን ካነቃቁ። ወሳኝ የሆኑ የመሠረተ ልማት ሀብቶችን ማሟጠጥ ወይም ራንሰምዌር ጥቃቶችን ለ ** CISA ሪፖርት ያድርጉ (1-844-Say-CISA / cisa.gov/report ወይም ** የካናዳ የሳይበር ደህንነት ማዕከል (1-833-CYBER-88)**።
• ** ዩናይትድ ኪንግደም : ይደውሉ 999 ለሕይወት አስጊዎች ወይም ወሳኝ የኤንኤችኤስ ስርዓቶች። በ UK GDPR እና NIS ደንቦች፣ ቋሚ የውሂብ ጎታ መጥፋት ለ ** ICO ማሳወቂያ የሚፈልግ መሆኑን ይገምግሙ0303 123 1113 በ 72 ሰዓታት ውስጥ።
• ** የአውሮፓ ህብረት ***: ይደውሉ 112 በሁሉም የአውሮፓ ህብረት አባል ሀገራት። በ NIS2 መመሪያ ስር ያሉ አስፈላጊ አካላት ጉልህ የሆነ መቋረጥ በደረሰባቸው በ24 ሰአታት ውስጥ ለሀገራቸው CSIRT ማሳወቅ አለባቸው እና ያለ ምትኬ ማግኛ ቋሚ የግል መረጃ መጥፋት የGDPR አንቀጽ 33 በ72 ሰአታት ውስጥ ሪፖርት ማድረግን ያስከትላል።
• አውስትራሊያ እና ኒውዚላንድ፡ ይደውሉ 000 በአውስትራሊያ ወይም 111 በኒው ዚላንድ; ** ACSC ያነጋግሩ (1300 CYBER1*** ለመሠረተ ልማት አደጋዎች።
• ህንድ እና እስያ-ፓሲፊክ፡ ደውል 112 ለአደጋ ጊዜ ምላሽ; በሳይበር-የተፈጠሩ መቋረጥን ለ CERT-In (incident@cert-in.org.in* አስገዳጅ በሆነው የ6-ሰዓት መስኮት ውስጥ።

በተደጋጋሚ የሚጠየቁ ጥያቄዎች¶

ለምን አደረገ df -h 100% ይቆዩ (0 Avail) 50 ጂቢ የምዝግብ ማስታወሻ ፋይልን ከሰረዝኩ በኋላ እንኳን rm?¶

በሊኑክስ ፋይል ስርዓቶች ውስጥ ፣ rm ጥሪዎች ብቻ ግንኙነት አቋርጥ()ከርነል የዲስክ ብሎኮችን ሲይዝ የፋይል ስሙን ከማውጫው ውስጥ በማስወገድ እያንዳንዱ ሂደት የፋይሉን ገላጭ እስኪዘጋ ድረስእቆጥራለሁ = 0). ሩጡ sudo lsof +L1 የሂደት መታወቂያውን ለማግኘት (PID) እና ፋይል ገላጭ (ኤፍ.ዲ) የ (ተሰርዟል) ፋይል ያድርጉ ፣ ከዚያ ያሂዱ sudo sh -c ': > /proc/PID/fd/FD' አገልግሎቱን እንደገና ሳይጀምር ወዲያውኑ በቦታው ያሉትን ብሎኮች ዜሮ ለማድረግ።

ኤስኤስኤች እንኳን ወደ አገልጋዩ መግባት ካልቻልኩ ምን ማድረግ አለብኝ /tmp ወይም /var/run 100% ሙሉ እና sshd ክፍለ ጊዜ ለመመደብ ፈቃደኛ አይደለም?¶

መጀመሪያ በይነተገናኝ አስመሳይ-ተርሚናል ሳትመደብ በኤስኤስኤች ላይ ያልሆነ የPTY ቀጥተኛ ትዕዛዝ ለመፈጸም ሞክር፡- ssh -T root@server "sh -c ': > /var/log/syslog'". ከሆነ ሥር መግባት ተሰናክሏል፣ በቀጥታ ለመግባት የደመና አቅራቢህን ከባንድ ውጪ ያለውን ተከታታይ ኮንሶል (AWS EC2 Serial Console፣ DigitalOcean Console፣ Linode Lish፣ ወይም Proxmox/VMware VNC) ተጠቀም። ttyS0 ወይም ወደ ነጠላ ተጠቃሚ መልሶ ማግኛ ሁነታ ቡት.

የሆነ ሰው አስቀድሞ በPostgreSQL ውስጥ ፋይሎችን ሰርዟል። pg_wal ይህንን መመሪያ ከማንበብ በፊት ማውጫ፣ እና አሁን PostgreSQL ለመጀመር ፈቃደኛ አይደለም። PANIC: could not locate a valid checkpoint record. ሁሉም ውሂብ ጠፍቷል?¶

አይ፣ አብዛኛዎቹ የጠረጴዛ ረድፎች አሁንም ውስጥ ናቸው። $PGDATA/ቤዝ/ምንም እንኳን በበረራ ውስጥ የተሰረዙ የWAL ፋይሎች ቢጠፉም እና አንዳንድ ገፆች ሊቀደዱ ይችላሉ። በመጀመሪያ ሙሉውን ቅጂ ያዘጋጁ $PGDATA ማውጫ (cp -a /var/lib/postgresql/16/ዋና /mnt/መጠባበቂያ/pgdata_raw). ከዚያ ሩጡ sudo -u postgres /usr/lib/postgresql/16/bin/pg_resetwal -f /var/lib/postgresql/16/ዋና, PostgreSQL በነጠላ ተጠቃሚ ሁነታ ይጀምሩ እና ወዲያውኑ ያሂዱ pg_dumpall ወደ አዲስ ጅምር (initdb) ክላስተር; በፍፁም የምርት ትራፊክን በክላስተር ላይ ማስኬድዎን አይቀጥሉም። pg_ዳግም ማስጀመር.

በሚሊዮን የሚቆጠሩ ትናንሽ ፋይሎችን እንዴት መሰረዝ እችላለሁ? rm -rf ባልደረቀ ድካም ላይ ተንጠልጥሏል ወይም አልተሳካም (df -i 100%) አገልጋይ?¶

ማውጫ በሚሊዮን የሚቆጠሩ ጥቃቅን ክፍለ ጊዜ ወይም መሸጎጫ ፋይሎችን ሲይዝ፣ የማውጫ ማውጫው (htree) ትልቅ ያድጋል, ያስከትላል ls እና rm -rf በ RAM ውስጥ የፋይል ስሞችን መደርደር ለማስቆም። ይልቁንስ ሩጡ sudo አግኝ / መንገድ / ወደ / million_files -mindepth 1 -ሰርዝወይም ባዶ ራም ማውጫ ይፍጠሩ (mkdir /dev/shm/ባዶ) እና መሮጥ sudo rsync -a - ሰርዝ /dev/shm/ባዶ//መንገድ/ወደ/ሚሊዮን_ፋይሎች/ የኢኖዶችን ግንኙነት በፍጥነት ለማቋረጥ።

የእኔ ኮንቴይነሮች እራሳቸው ጥቃቅን ሲሆኑ Docker ለምን ሙሉውን የአገልጋይ ዲስኩን ሞላው እና እንዴት አጸዳለሁ። /var/lib/docker በአስተማማኝ ሁኔታ?¶

ዶከር የዲስክ ቦታን ባልተሽከረከረ የ JSON stdout ምዝግብ ማስታወሻዎች ውስጥ ይሰበስባል (/var/lib/docker/containers/*/*-json.log), ተንጠልጣይ ተደራቢ2 የምስል ንብርብሮች እና የግንባታ ኪት መሸጎጫ። በጭራሽ በእጅ rm -rf ውስጥ ያሉ አቃፊዎች /var/lib/docker/ተደራቢ2/. መጀመሪያ የJSON ምዝግብ ማስታወሻዎችን ይቁረጡ (sudo truncate -s 0 /var/lib/docker/containers/*/*-json.log) ስለዚህ ዴሞን መተንፈሻ ክፍል አለው፣ ከዚያ ሩጡ sudo docker ስርዓት ፕሪን -a -f (መተው --ጥራዞች ስለዚህ የውሂብ ጎታ ጥራዞች ሳይነኩ ይቀራሉ).

አገልጋዩ 100% የዲስክ አጠቃቀም ላይ እያለ የደመና ኢቢኤስ/ቋሚ የዲስክ መጠንን በቀጥታ ማስፋፋት እችላለሁን?¶

አዎ፣ የመስመር ላይ የድምጽ መጠን ማስፋፊያ ዳግም ሳይነሳ ይሰራል፣ ከአንድ መያዝ ጋር፡ የረዳት ስክሪፕት። growpart /dev/nvme0n1 1 ጊዜያዊ ፋይል ለመፍጠር ይሞክራል። /tmp በመጠቀም mktemp እና በ 0 ባይት በነጻ አይሳካም። በመሮጥ ያንን ውድቀት ማለፍ sudo TMPDIR=/dev/shm growpart /dev/nvme0n1 1 (በ RAM የሚደገፈውን በመጠቀም /dev/shm ተራራ) ተከትሎ sudo resize2fs /dev/nvme0n1p1 (ext4) ወይም sudo xfs_growfs / (XFS).

ተዛማጅ መመሪያዎች¶

• ድንገተኛ rm -rf ወይም Shift+ Delete በሊኑክስ፣ ማክኦኤስ ወይም ዊንዶውስ ላይ፡ ተነባቢ-ብቻ ዳግም መጫን
• የተመሰጠረ SQLite፣ ሲግናል እና WhatsApp የውይይት ምትኬ ሙስና እና የአካባቢ ቁልፍ ማውጣት
• የተበላሸ ቃል፣ ኤክሴል፣ ፒዲኤፍ እና የውሂብ ጎታ ፋይል እና ያልተቀመጠ ሰነድ መልሶ ማግኘት
• SSD እና NVMe ድንገተኛ ተነባቢ-ብቻ ሁነታ፣ 0% መለዋወጫ ብሎኮች እና TRIM ማዳንን ያሰናክላል
• የድር ማስተናገጃ ቀውስ፣ ፍልሰት እና ምትኬ ወደነበረበት መመለስ
• የአደጋ ጊዜ ቁጥሮች በአገር

ምንጮች እና ኦፊሴላዊ መመሪያ¶

• PostgreSQL የአለምአቀፍ ልማት ቡድን፡ PostgreSQL 16 ይፋዊ ሰነድ - ምዕራፍ 30፡ ተአማኒነት እና ወደፊት የመፃፍ ምዝግብ ማስታወሻ (WAL ውቅር፣ ማባዛት ማስገቢያ እና ከዲስክ ሙሉ ውድቀቶች ማገገም)።
• SQLite Consortium (sqlite.orgየSQLite ዳታቤዝ ፋይልን እንዴት ማበላሸት እንደሚቻል (ፋይል መቆለፊያ፣ ያልተገናኘ ጆርናል/WAL ፋይሎች፣ እና .recover CLI ቅጥያ)*.
• Oracle ኮርፖሬሽን/ MySQL ዶክመንቴሽን እና ማሪያዲቢ ፋውንዴሽን፡ InnoDB ብልሽት መልሶ ማግኛ፣ የሁለትዮሽ ምዝግብ ማስታወሻ የማጽዳት ሂደቶች (PURGE BINARY LOGS), እና ጊዜያዊ የጠረጴዛ ቦታ (ibtmp1) አስተዳደር።
• የሊኑክስ ኮርነል ድርጅት (እ.ኤ.አ.)kernel.org): * Ext4 ፋይል ስርዓት አስተዳደር (tune2fs የተጠበቁ ብሎኮች፣ የኢኖድ ጠረጴዛዎች እና /proc/<pid>/fd/ የፋይል ገላጭ መቆራረጥ)*.
• ብሔራዊ ደረጃዎች እና ቴክኖሎጂ ኢንስቲትዩት (እ.ኤ.አ.)NIST) (ዩናይትድ ስቴትስ): *ልዩ ሕትመት 800-123: የአጠቃላይ አገልጋይ ደህንነት እና ተገኝነት አስተዳደር መመሪያ *.