Server Disk 100% Puno (0 Bytes Libre): Pagbawi sa usa ka Nahagsa nga Database Kanus-a rm ug apt Napakyas tungod sa Kakulang sa Inodes/Space¶

Ang pagkadiskobre nga ang usa ka produksiyon sa Linux server naigo 100% paggamit sa disk (0 bytes free) o 100% paggamit sa inode (df -i) samtang nagdagan sa usa ka aktibo nga PostgreSQL, MySQL/InnoDB, MariaDB, o SQLite database mao ang usa sa labing delikado nga paagi sa kapakyasan sa mga sistema sa administrasyon. Sa zero bytes o zero free inodes, ang krisis paspas nga mosaka: ang operating system kernel dili na makahimo og Unix domain sockets sa /tmp o /var/run, bash napakyas sa pagkompleto sa tab tungod kay dili kini makasulat sa temporaryo nga mga tubo sa kabhang, apt o dnf dili makadagan aron limpyohan ang mga pakete tungod kay ang mga manager sa package nanginahanglan temporaryo nga mga file sa kandado, ug ang imong makina sa database nahagsa sa tunga sa usa ka Write-Ahead Log (WAL) checkpoint o nagdumili sa pagsira sa limpyo tungod kay dili kini makagahin ug usa ka 4 kilobyte (0.004 megabyte) block para sa .pid o lock file. Ang mas grabe pa, ang mga natarantar nga mga administrador kanunay nga modagan rm -rf /var/log/*.log sa multi-gigabyte log files ug tan-awa sa kalisang ingon df -h report gihapon 100% Use% (0 Avail), o makamatay sila nga nagtangtang pg_wal (pg_xlog) o ib_logfile0 sa pagpahawa sa wanang, permanente nga makadaot sa database lapas sa pagbawi sa transaksyon. Kung wala ka tuyoa nga natangtang ang mga kritikal nga file sa database sa panahon sa pagsulay sa paglimpyo, hunong dayon ug ibalhin sa aksidenteng rm -rf o Shift-Delete read-only remount ug inode carving; kung ang imong nagpahiping hardware sa pagtipig naghulog sa mga sayup sa I / O o nag-lock sa kaugalingon batok sa mga pagsulat, konsultaha SSD ug NVMe kalit nga read-only mode ug TRIM disable rescue o dunot nga Pulong, Excel, PDF, ug database file recovery. Kung kini nga outage makaapekto sa mga sistema sa kaluwasan sa kinabuhi sa ospital, pagpadala sa emerhensya, o kritikal nga mga gamit sa publiko, tawagan ang imong lokal nga numero sa emerhensya (911 sa Estados Unidos ug Canada, 112 sa tibuok European Union, 999 sa United Kingdom) o konsultaha ang among global nga direktoryo sa emergency nga mga numero.

Buhata kini karon¶

1. AYAW i-delete pg_wal/, pg_xlog/, pg_multixact/, ib_logfile*, undo_*, o -wal / -shm mga file aron maghimog luna: Ang pagtangtang sa Write-Ahead Log o InnoDB redo/undo log files samtang ang database nahagsa o wala ma-checkpoint makaguba sa bugtong rekord sa wala pasalig ug in-flight nga mga panid. Ang usa ka database nga adunay usa ka bug-os nga disk 100 porsyento nga mabawi sa higayon nga mapagawas ang luna; usa ka database kansang WAL nga mga file gitangtang sa mano-mano rm mag-antos sa dili mabalik nga B-tree ug tapok nga korapsyon.
2. ** Pag-diagnose sa 5 segundo kung wala ka sa mga bloke sa disk (df -h), gikan sa filesystem inodes (df -i), o pagkupot sa bukas nga wala masumpay nga mga file (lsof +L1)**:
3. Dagan df -h sa pagsusi block kapasidad ug df -i aron masusi ang kapasidad sa inode. Ang usa ka server nga adunay 50 gigabytes (53.6 bilyon nga bytes) nga libre nga espasyo sa disk molabay gihapon No space left on device (ENOSPC) kon df -i nagpakita IUse% = 100% (kasagaran tungod sa minilyon nga gamay nga session, cache, o mail spool files).
4. Kung df -h nagpakita 100% gigamit (0 Avail) bisan pag nakadagan ka rm sa dako nga log files, run sudo lsof +L1. Bisan unsang file nga natangtang gamit ang rm samtang nginx, rsyslog, docker, postgres, o mysqld sa gihapon naghupot sa usa ka bukas nga file descriptor nagpadayon sa paggamit sa 100 porsyento sa iyang mga bloke sa disk hangtud nga ang proseso magsugod pag-usab o imong putlon ang descriptor direkta.
5. Libre nga gigabytes nga wanang sa 1 segundo nga wala i-restart ang mga daemon pinaagi sa pagputol sa bukas nga mga file sa lugar (: > /path/to/logfile o : > /proc/<pid>/fd/<n>):
6. Imbes nga rm /var/log/syslog (nga nagbilin sa mga bloke nga gi-lock sa running logger), i-zero ang file sa lugar gamit ang shell null redirect: sudo sh -c ': > /var/log/syslog' o sudo truncate -s 0 /var/log/syslog.
7. Kung nidagan ka rm sa usa ka dako nga log file ug df -h wala nahulog, pangitaa ang proseso nga ID (PID) ug file descriptor (FD) sa sudo lsof +L1 ug putla kini diretso pinaagi sa kernel procfs interface: sudo sh -c ': > /proc/<PID>/fd/<FD>'. Ang wanang mobalik sa df -h diha-diha dayon.
8. ** I-unlock dayon ang emergency room sa pagginhawa ext4 / ext3 pinaagi sa pagpaubos sa gireserba nga root block nga porsyento (tune2fs -m 1)**: Pinaagi sa default, ext4 adunay 5 porsyento sa tibuok partisyon (25 gigabytes sa a 500 gigabyte disk) alang lamang sa UID 0 (root), nagpasabut nga dili gamut nga mga serbisyo sama sa postgres (UID 109), mysql, ug www-data naigo No space left on device sa 95 porsyento nga paggamit. Ibalik ang 80 porsyento sa kana nga reserba online sa 1 segundo nga adunay zero downtime pinaagi sa pagdagan sudo tune2fs -m 1 /dev/sda1 (o ang imong root block device gikan sa findmnt /).
9. Hawan systemd-journald binary logs ug daan nga package caches nga luwas: Run sudo journalctl --vacuum-size=50M (nga luwas nga nagtuyok ug naglimpyo sa binary /var/log/journal mga archive hangtod sa 50 megabytes) ug sudo apt-get clean (o sudo dnf clean all), nga nagtangtang sa na-download .deb / .rpm mga archive sa /var/cache/apt/archives/ nga dili kinahanglan nga magsulat sa dpkg database.
10. ** Sa higayon nga libre na ang labing menos 1 gigabyte ngadto sa 5 gigabytes (1.07 bilyon ngadto sa 5.36 bilyong bytes) nga luna, dad-a ang database sa single-user o recovery mode aron makompleto ang WAL checkpoint niini sa dili pa tugotan ang trapiko sa kliyente**: Tugoti ang PostgreSQL, MySQL/InnoDB, o SQLite nga i-replay ang Write-Ahead Log (WAL), i-flush ang hugaw nga mga panid ngadto sa nag-unang mga file sa datos, ug i-recycle ang nabuak nga mga bahin sa WAL nga limpyo sa dili pa ablihan pag-usab ang imong firewall sa aplikasyon o web server.

Desisyon tree: zero-space server ug nahagsa nga database triage¶

Gamita kini nga punoan sa desisyon aron mahibal-an kung ngano nga nagreport ang operating system ENOSPC (No space left on device) ug pilia ang eksakto nga dili makadaot nga agianan sa pagbawi:

flowchart TD
    Start["Server o Database Throwing: Wala’y nahabilin nga wanang sa aparato (ENOSPC)"] --> CheckDF["Dagan: df -h UG df -i"]

    CheckDF --> DiagType{"Unsa ang Gi-report sa df?"}

    DiagType -->|"df -h Nagpakita 100% Paggamit (0 Avail) UG df -i < 95%"| BlockFull["Block Exhaustion: Susihon kung du -shx / Match sa df -h"]
    DiagType -->|"Ang df -h Nagpakita ug Libre nga GB PERO ang df -i Nagpakita sa 100% IUse"| InodeFull["Inode Exhaustion: Minilyon nga Gagmay nga 0-to-4KB nga mga File"]
    DiagType -->|"Parehong df -h ug df -i Ipakita <90% Gigamit"| RamOrQuota["Natago nga Limitasyon: Susiha ang df -h /tmp (puno ang tmpfs RAM), Docker Overlay2, o XFS/ext4 Disk Quotas"]

    BlockFull --> GhostCheck{"Nakadagan na ba ka sa rm sa Daghang mga File nga Wala’y Pag-drop sa df?"}
    GhostCheck -->|"Oo: ang du Mas Gamay Kay sa df"| UnlinkedFD["Run: sudo lsof +L1 -> Truncate Ghost File pinaagi sa : > /proc/PID/fd/FD"]
    GhostCheck -->|"Dili: Ang Tinuod nga mga File Nagpuno sa Disk"| EmergencySpace["Paghimo Diha-diha nga Lugar sa Pagginhawa (1 GB hangtod 5 GB)"]

    EmergencySpace --> Ext4Check{"Ang Filesystem ext4 / ext3 ba?"}
    Ext4Check -->|"Oo"| Tune2fs["Pagdalagan: sudo tune2fs -m 1 /dev/root_dev (Gipagawas dayon ang 4% sa Disk alang sa Non-Root DB User)"]
    Ext4Check -->|"Dili (XFS / Btrfs / ZFS)"| TruncLogs["Pagputol sa mga Log In-Place (: > /var/log/syslog) ug Run journalctl --vacuum-size=50M"]

    InodeFull --> InodeClean["Pangitaa ang Direktoryo nga adunay Minilyon nga mga File Gamit ang find / -xdev -printf '%h\n' | matang | uniq -c | matang -k 1 -r | ulo -20 -> Pagtangtang gamit ang pagpangita -pagtangtang"]

    UnlinkedFD --> DBRecover["Padayon sa Database Engine WAL & B-Tree Recovery"]
    Tune2fs --> DBRecover
    TruncLogs --> DBRecover
    InodeClean --> DBRecover
    RamOrQuota --> DBRecover

    DBRecover --> WhichDB{"Unsang Database Engine ang Na-crash?"}
    WhichDB -->|"PostgreSQL"| PGFlow["Ipadayon ang pg_wal Intact -> Start Postgres to Replay WAL -> Run CHECKPOINT; -> Ihulog ang Stale Replication Slots"]
    WhichDB -->|"MySQL / MariaDB (InnoDB)"| MyFlow["Ipadayon ang ib_logfile* Intact -> Start mysqld -> Purge Binary Logs pinaagi sa PURGE BINARY LOGS -> Optimize Tables"]
    WhichDB -->|"SQLite3"| SqFlow["I-back Up .db + .db-wal + .db-shm -> Run PRAGMA wal_checkpoint(TRUNCATE) o sqlite3 broken.db '.recover'"]

Phase 1: Nganong standard commands (rm, apt, tab-completion) napakyas sa 0 bytes nga libre¶

Kung ang partisyon sa Linux naigo sa 100 porsyento nga block o kakapoy sa inode, ang mga standard remediation commands mapakyas sa wala damha nga mga paagi: - Pagpindot Tab sa bash paglabay cannot create temp file for here-document: No space left on device: Moderno bash-completion Ang mga script naghimo og temporaryo nga mga file sa /tmp. Kung /tmp nagpuyo sa gamut / partisyon imbes nga a tmpfs RAM mount, pagkompleto sa kabhang ug heredocs (<<EOF) mapakyas. Ayuha dayon kini pinaagi sa pagtudlo TMPDIR sa shared memory RAM:

export TMPDIR=/dev/shm

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

Ang 5 ka lahi nga hinungdan sa No space left on device (ENOSPC)¶

Sa dili pa mohikap sa bisan unsang mga file sa database, itandi kining lima ka mga senaryo aron makumpirma kung unsa nga kapanguhaan ang tinuod nga nahurot:

Phase 2: Pagbawi sa disk space nga luwas sa ubos sa 60 segundos¶

Sunda kining eksakto nga mga lakang aron mabawi ang taliwala sa 500 megabytes ug 50 gigabytes (0.53 bilyon hangtod 53.6 bilyon nga byte) sa wanang nga dili makadaot sa mga aktibo nga proseso:

Lakang 1: Pagputol sa bukas nga natangtang ("ghost") nga mga file pinaagi sa /proc/<pid>/fd/¶

Kung ikaw o ang usa ka automated logrotate nga script natangtang na ang dagkong mga file apan wala mabalik ang espasyo sa disk, susiha ang wala masumpay nga open file table sa kernel:

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'

Lakang 2: I-reclaim ext4 gitagana nga mga bloke online uban sa tune2fs¶

Sa bisan unsa ext4 o ext3 filesystem, susiha ang kasamtangang gireserba nga block count:

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

sudo tune2fs -m 1 /dev/nvme0n1p1

Lakang 3: Putol ang aktibo nga mga log sa teksto sa lugar ug i-vacuum journald¶

Pangitaa ang pinakadako nga mga file sa root filesystem (nagpabilin sa parehas nga filesystem nga adunay -xdev aron dili ka mag-usik ug oras sa pag-scan /proc o eksternal nga mga mount):

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

Phase 3: Pagbawi sa PostgreSQL human sa 100% nga disk-full crash (pg_wal bloat)¶

Kung ang usa ka PostgreSQL server nahutdan sa disk space, kini nag-log PANIC: could not write to file "pg_wal/xlogtemp.1234": No space left on device, gi-abort dayon ang mga proseso sa bata sa postmaster, ug nagdumili sa pagsugod.

Ngano pg_wal (pg_xlog sa PostgreSQL 9.6 ug mas tigulang) nagpuno sa tibuok disk¶

Sa normal nga operasyon, gisulat sa PostgreSQL ang matag pagbag-o sa 16 megabyte (16.7 milyon nga byte) nga mga file sa bahin sa sulod. $PGDATA/pg_wal/ ug i-recycle kini human sa matag usa CHECKPOINT sa higayon nga ang milapas max_wal_size. Bisan pa, ang PostgreSQL gidili sa pagtangtang o pag-recycle sa daan pg_wal file ubos sa tulo ka kondisyon: 1. Usa ka ilo o nalangan nga Pisikal/Lohikal nga Replikasyon Slot: Usa ka replica server (standby), Debezium/Kafka connector, o pg_receivewal ang kliyente nadiskonekta mga adlaw na ang milabay, apan ang replication slot niini (pg_replication_slots) mao gihapon active = false sa panguna, nagmando sa PostgreSQL nga ipadayon ang matag bahin sa WAL nga nahimo sukad sa pagkadiskonekta. 2. ** Usa ka kapakyasan archive_command**: archive_mode = on gi-enable sa postgresql.conf, ug ang backup nga script (pgBackRest, WAL-G, Barman, o aws s3 cp) mao ang pagbalik sa usa ka non-zero exit code (pananglitan, usa ka expired nga S3 key o dili maabot nga backup host). Gitago sa PostgreSQL ang matag wala na-archive nga bahin sa WAL pg_wal/ hangtod archive_command mibalik 0. 3. Usa ka bug-os nga disk nga deadlock: pg_wal mitubo hangtod 0 bytes nagpabilin sa /var/lib/postgresql, ug karon ang PostgreSQL dili gani makasugod sa paghulog sa replication slot o pagkompleto sa usa ka checkpoint tungod kay ang startup recovery mismo nagkinahanglan ug pipila ka megabytes nga libre nga disk space aron masulat ang temporaryo nga state files.

Step-by-step nga PostgreSQL zero-space rescue (Zero Data Loss)¶

1. Paghimo 1 gigabyte hangtod 5 gigabytes (1.07 bilyon hangtod 5.36 bilyon nga byte) nga temporaryo nga wanang sa gawas pg_wal/:
2. Unang paggamit sudo tune2fs -m 0 /dev/<partition> ug truncate system/PostgreSQL text logs (sudo truncate -s 0 /var/lib/postgresql/*/main/log/*.log o /var/log/postgresql/*.log).
3. ** Unsa kaha kung ang database adunay kaugalingon nga gipahinungod nga partisyon nga adunay mga zero text log ug XFS (so tune2fs dili magamit)?** Ibalhin ang 10 ngadto sa 20 sa labing karaan .ready o dili aktibo nga mga file gikan sa dili-WAL nga direktoryo, o ibalhin ang pg_wal temporaryo nga direktoryo sa lain nga partisyon nga adunay libre nga wanang gamit ang simbolikong link:

   # 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. ** Kung archive_command napakyas ug gibabagan ang pag-recycle sa WAL, temporaryo nga laktawan kini postgresql.conf**: Kung ang imong S3/backup nga target ubos ug pg_wal/archive_status/ naglangkob sa liboan sa .ready file, edit postgresql.conf (archive_command = '/bin/true') ingon lang usa ka last-resort nga lakang sa emerhensya aron mapahunong ang pagkapatay sa disk, kay nahibal-an nga kinahanglan ka magkuha og bag-o pg_basebackup diha-diha dayon human sa pagkaayo tungod kay ang WAL archive chain adunay gintang.
5. Sugdi ang PostgreSQL ug susiha dayon ang mga slot sa replikasyon: Pagsugod sa PostgreSQL (sudo systemctl start postgresql) ug magkonektar pinaagi sa 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. Ihulog ang bisan unsang patay/dili aktibo nga slot sa replikasyon nga nagtago sa gigabytes sa WAL: Kung makakita ka og dili aktibo nga slot (active = f) nga nagkupot ug 80 gigabytes sa retained_wal:

   SELECT pg_drop_replication_slot('name_of_dead_slot');
   

7. ** Pagpugos dayon CHECKPOINT sa pag-recycle sa nabuak pg_wal mga bahin**:

   CHECKPOINT;
   

   Ang higayon CHECKPOINT; mahuman human ihulog ang patay nga slot, ang PostgreSQL awtomatik nga mag-unlink o mag-recycle sa mga gigabyte sa daan nga 16 megabyte nga mga file nga bahin sa pg_wal/, ibalik ang imong paggamit sa disk sa normal.
8. Pugngi ang umaabot nga replication slot disk death: Set max_slot_wal_keep_size sa postgresql.conf (anaa sa PostgreSQL 13+) sa usa ka luwas nga cap (sama sa max_slot_wal_keep_size = 20GB) mao nga gi-invalidate sa PostgreSQL ang slot sa patay nga kopya kay sa pag-crash sa nag-unang database sa 0 bytes nga libre.

Phase 4: Pagbawi sa MySQL / MariaDB (InnoDB) sa 0 bytes nga libre¶

Kung ang MySQL o MariaDB naigo 100% paggamit sa disk (/var/lib/mysql), Ang InnoDB stalls tanan nagsulat o nag-crash sa [ERROR] [MY-012640] [InnoDB] Error number 28 means 'No space left on device'.

Pag-ila kung unsa ang napuno /var/lib/mysql¶

Dagan sudo du -sh /var/lib/mysql/* | sort -hr | head -n 15 aron makita kung kinsa niining upat ka mga sad-an ang mikonsumo sa disk: 1. ** Walay kinutuban nga Binary Logs (binlog.000001, mysql-bin.000042): Pinaagi sa default sa MySQL 8.0+, ang binary logging gipagana nga adunay 30 ka adlaw nga pagpabilin (binlog_expire_logs_seconds = 2592000), nga daling makamugna og gatusan ka gigabytes sa row nga mga panghitabo atol sa dinaghan nga pag-import. 2. Usa ka runaway nga pangutana nga nagsulat sa higanteng temporaryo nga mga lamesa (#sql* o ibtmp1): Usa ka dako GROUP BY o ORDER BY napuno ang pangutana ibtmp1 o /tmp/#sql_* hangtod ang disk naigo sa 0 bytes. 3. ** Monolithic ibdata1 system tablespace bloat: Kung innodb_file_per_table na-disable o ang dugay nang mga transaksyon nakapugong sa listahan sa kasaysayan sa InnoDB (undo logs inside ibdata1 o undo_001) gikan sa pagpurga. 4. Ang MySQL hinay nga query log o error log (/var/log/mysql/mysql-slow.log).

Step-by-step nga MySQL / MariaDB zero-space rescue¶

1. ** AYAW pag delete ibdata1, ib_logfile0, ib_logfile1, #innodb_redo/*, o undo_001 uban sa rm**: Ang pagtangtang sa bisan hain niini nga mga file makahimo sa matag .ibd table file sa imong database dili mabasa.
2. Libre nga pasiunang luna sa pagsugod (500 megabytes ngadto sa 2 gigabytes):
3. Pagputol /var/log/mysql/error.log ug mysql-slow.log pinaagi sa sudo truncate -s 0 /var/log/mysql/*.log.
4. Sa ext4, dagan sudo tune2fs -m 1 /dev/<partition>.
5. Kung mysqld gihunong karon ug /var/lib/mysql/ibtmp1 (ang non-compressed temporary tablespace tablespace) dako kaayo, ibtmp1 awtomatik nga gimugna pag-usab sa pagsugod, o mahimo nimong ibalhin ang labing karaan nga duha o tulo binary logs (binlog.000001, binlog.000002 - dili ang pinakataas nga numero nga aktibo nga binlog) sa /dev/shm temporaryo nga mysqld maka-boot.
6. ** Sugdi ang MySQL ug limpyohan ang binary log nga luwas gamit ang SQL (PURGE BINARY LOGS)**: Ngano nga kinahanglan nimo gamiton ang SQL imbes nga rm /var/lib/mysql/binlog.*? Tungod kay ang MySQL nagsubay sa matag binary log filename sa binlog.index. Kung imong tangtangon ang binary log nga adunay rm walay update binlog.index, MySQL modumili sa pagsugod o replikasyon maguba. Kausa mysqld magsugod, log in (sudo mysql) ug run:

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

   (O limpyohan ang tanan hangtod sa karon nga aktibo nga log file nga gipakita sa ilawom sa SHOW BINARY LOGS; naggamit PURGE BINARY LOGS TO 'binlog.000085';)
7. Pagbutang ug permanenteng binary log size ug retention cap in /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
   

   Pagtabon ibtmp1 sa max:5G nagsiguro nga ang usa ka rogue dili ma-index JOIN o ORDER BY napakyas ang pangutana sa a table is full sayop kay sa pagpalapad ibtmp1 hangtod ang tibuok server sa Linux mamatay sa 0 bytes nga libre.

Phase 5: Pagbawi sa usa ka dunot nga SQLite3 database (database or disk is full / SQLITE_FULL / malformed)¶

Gi-embed nga mga aplikasyon, mga sudlanan sa Docker (Nextcloud, Vaultwarden, Home Assistant, Plex, Grafana, Gitea), ug ang mga serbisyo sa mobile/desktop nagsalig sa SQLite3. Kung ang usa ka disk naigo sa 0 bytes nga libre samtang ang SQLite naa sa tunga sa usa ka rollback sa journal o usa ka Write-Ahead Log (-wal) checkpoint, makasugat kag usa sa duha ka emerhensya: 1. Daghan .db-wal file bloat (ang .db-wal file mitubo ngadto sa 10 gigabytes samtang ang .db Ang file 200 megabytes lamang, tungod kay ang dugay nang mga magbabasa nagpugong sa usa ka passive WAL checkpoint, ug karon ang disk 100 porsyento nga puno). 2. RuntimeError: database disk image is malformed (SQLITE_CORRUPT) tungod sa guba nga hardware fsync(), usa ka sudlanan nga nakapatay sa tunga-tunga sa rollback sa 0 bytes nga libre, o adunay nagtangtang sa -wal o -journal file pinaagi sa kamot.

Lakang 1: Pagkunhod sa usa ka bloated .db-wal file ug pag-vacuum sa SQLite kung ang espasyo sa disk hapit sa zero¶

1. Hunonga ang sudlanan sa aplikasyon o serbisyo nga nagkupot sa database sa SQLite nga bukas (sudo systemctl stop app o docker stop container_name).
2. Kopyaha app.db, app.db-wal, ug app.db-shm sa partition o external drive nga adunay daghang libre nga wanang (o libre nga 2x ang gidak-on sa app.db sa lokal nga disk una).
3. Ablihi ang database gamit ang sqlite3 CLI ug pugson ang pagputol sa WAL checkpoint, nga mopilo sa tanang nahimo nga mga frame gikan sa app.db-wal ngadto sa app.db ug mokunhod app.db-wal ngadto sa 0 bytes:

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

4. I-verify ang B-tree ug freelist nga integridad sa istruktura:

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

   Kung kini nag-imprinta ok, ang imong database 100 porsyento nga himsog.
5. **Unsaon VACUUM usa ka dako nga database sa SQLite kung ang lokal nga disk wala’y igo nga libre nga wanang **: Estandard VACUUM; nanginahanglan hangtod 2x ang gidak-on sa database sa libre nga espasyo sa disk sa parehas nga partisyon ug /var/tmp. Hinunoa, gamita VACUUM INTO (gipaila sa SQLite 3.27.0) aron magsulat og bag-ong gi-compact, defragmented nga kopya direkta sa usa ka bulag nga gitaod nga disk o bahin sa network:

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

Lakang 2: Pagluwas sa usa ka dunot nga B-tree (database disk image is malformed) uban sa .recover¶

Kung PRAGMA integrity_check; mga taho row 412 missing from index, btreeInitPage() returns error code 11, o database disk image is malformed:

1. Una nga pagsulay sa pagtukod pag-usab sa guba nga mga sekondaryang indeks (REINDEX): Kasagaran ang aktwal nga datos sa lamesa (table B-trees) 100 porsyento nga wala'y labot ug usa lamang ka ikaduha nga indeks nga B-tree ang nadaot sa dihang napuno ang disk. Dagan:

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

   Kung PRAGMA integrity_check; karon mibalik ok, nabawi nimo ang 100 porsyento sa imong database nga adunay zero nawala nga mga laray.
2. ** Kung REINDEX napakyas, padagana ang forensic B-tree scanner (.recover)**: Dili sama sa mas tigulang .dump command (nga mohunong sa pag-eksport sa usa ka lamesa sa higayon nga kini makaigo sa usa ka dunot nga B-tree pointer), .recover (gitukod sa sqlite3 version 3.29.0+) mo-bypass sa dunot nga interior nga B-tree pointer sa hingpit, mo-scan sa matag hilaw nga 4 kilobyte nga dahon nga panid sa file nga sunud-sunod gikan sa byte 0 ngadto sa EOF, magtukod pag-usab sa matag mabasa nga row, ug ibutang ang bisan unsang nailo nga mga rekord ngadto sa usa ka lost_and_found lamesa:

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

3. I-verify ang bag-ong gitukod pag-usab nga database:

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

   Susiha kon a lost_and_found gihimo ang lamesa (sqlite3 /mnt/external_usb/repaired_app.db ".tables") sa pagsusi sa bisan unsang mga ilo nga mga laray nga nakuha gikan sa wala masumpay nga mga panid sa dahon. Para sa mga naka-encrypt nga database sa SQLCipher (sama sa mga backup sa Signal o WhatsApp), tan-awa ang among gipahinungod nga giya sa naka-encrypt nga SQLite, Signal, ug WhatsApp chat backup corruption ug local key extraction.

Phase 6: Emergency "Tripwire Ballast File" ug pagmonitor sa checklist sa paglikay¶

Kung ang imong server ug database nakabalik na sa online, ipatuman dayon kining upat ka mga panalipod aron dili ka na ma-trap sa 0 bytes nga libre pag-usab:

• Paghimo og 1 gigabyte (1,073,741,824 byte) Emergency Ballast File sa matag database partition: Run sudo fallocate -l 1G /var/lib/EMERGENCY_DELETE_ME.ballast. Kung naigo ang server 100% puno ang disk, nagdagan sudo rm /var/lib/EMERGENCY_DELETE_ME.ballast nagpagawas sa 1 gigabyte sa magkadugtong nga mga bloke sa 1 millisecond.
• Kap systemd-journald ug Permanente nga mga log sa sudlanan sa Docker: Itakda SystemMaxUse=200M sa /etc/systemd/journald.conf ug i-configure /etc/docker/daemon.json uban sa "log-opts": {"max-size": "20m", "max-file": "3"}.
• Ilain /var/log, /tmp, ug /var/lib/postgresql ngadto sa bulag nga LVM volume: Pagtipig /var/log ug /tmp Ang bulag sa mga volume sa database nagsiguro nga ang usa ka runaway nga web log dili maka-crash sa database o maka-lock sa mga login sa SSH.
• Alerto sa DUHA df -h (> 80%) UG df -i (> 80%) dugang pg_replication_slots lag: I-configure ang pagmonitor (node_filesystem_avail_bytes ug node_filesystem_files_free) nga alerto sa dili pa molapas sa 85 porsyento ang paggamit.

Mga numero sa emerhensya sa rehiyon ug mga protocol sa ahensya¶

Samtang ang usa ka bug-os nga disk sa server kasagaran usa ka internal nga operasyon sa IT nga emerhensya, usa ka outage nga nakaapekto sa healthcare Electronic Health Record (EHR) databases, emergency nga pagpadala (CAD), municipal water/power telemetry, o statutory personal data availability mahimong magkinahanglan og pormal nga emergency escalation:

• Estados Unidos ug Canada: Dial 911 kung ang pagkahagsa sa server nagpugong sa klinikal nga pagmonitor o pagpadala, ug gi-aktibo ang mga pamaagi sa downtime. I-report ang kritikal nga imprastraktura nga resource-exhaustion o ransomware attacks sa CISA (1-844-Say-CISA / cisa.gov/report) o ang Canadian Center for Cyber Security (1-833-CYBER-88).
• United Kingdom: Dial 999 alang sa mga hulga sa kinabuhi o kritikal nga mga sistema sa NHS. Ubos sa UK GDPR ug NIS Regulations, susiha kung ang permanente nga pagkawala sa pagkaanaa sa database nanginahanglan pagpahibalo sa ICO (0303 123 1113) sulod sa 72 ka oras.
• European Union: Dial 112 sa tanan nga estado nga miyembro sa EU. Kinahanglang ipahibalo sa mga importanteng entidad ubos sa NIS2 Directive ang ilang nasudnong CSIRT sulod sa 24 ka oras sa usa ka mahinungdanong outage, ug ang permanente nga pagkawala sa personal nga data nga walay backup recovery magpahinabog GDPR Article 33 nga pagtaho sulod sa 72 ka oras.
• Australia ug New Zealand: Dial 000 sa Australia o 111 sa New Zealand; kontaka ang ACSC (1300 CYBER1) para sa mga insidente sa imprastraktura.
• India ug Asia-Pacific: Dial 112 alang sa emerhensya nga tubag; i-report ang cyber-induced outages ngadto sa CERT-In (incident@cert-in.org.in) sulod sa mandatory 6-hour window.

Kanunay nga gipangutana nga mga pangutana¶

Ngano ni df -h magpabilin sa 100% (0 Avail) bisan human nako gitangtang ang usa ka 50 GB nga log file nga adunay rm?¶

Sa Linux filesystems, rm mga tawag lang unlink(), pagtangtang sa filename gikan sa direktoryo samtang ang kernel nagpugong sa mga bloke sa disk nga gigahin hangtod nga ang matag proseso nga nagbukas sa file magsira sa file descriptor niini (i_count == 0). Dagan sudo lsof +L1 para pangitaon ang Process ID (PID) ug File Descriptor (FD) sa (gitangtang) file, dayon run sudo sh -c ': > /proc/PID/fd/FD' sa pag-zero sa mga bloke diha-diha dayon nga dili i-restart ang serbisyo.

Unsa kaha kung dili ko ma-SSH sa server tungod kay /tmp o /var/run 100% puno ug sshd nagdumili sa paggahin ug sesyon?¶

Sulayi una ang pagpatuman sa usa ka dili-PTY nga direkta nga mando sa SSH nga wala mag-alokar sa usa ka interactive nga pseudo-terminal: ssh -T gamut @ server "sh -c ': > /var/log/syslog'". Kung gamut gi-disable ang pag-login, gamita ang out-of-band serial console sa imong cloud provider (AWS EC2 Serial Console, DigitalOcean Console, Linode Lish, o Proxmox/VMware VNC) aron maka-log in direkta sa ttyS0 o boot ngadto sa single-user recovery mode.

Adunay usa nga nagtangtang sa mga file sa sulod sa PostgreSQL's pg_wal direktoryo sa wala pa basahon kini nga giya, ug karon PostgreSQL nagdumili sa pagsugod sa PANIC: could not locate a valid checkpoint record. Nawala ba ang tanan nga datos?¶

Dili, kadaghanan sa mga laray sa lamesa anaa gihapon sa sulod $PGDATA/base/, bisan tuod ang mga transaksyon sa in-flight sulod sa mga natangtang nga WAL files nawala ug ang pipila ka mga panid mahimong magisi. Paghimo una og kompletong kopya sa tibuok $PGDATA direktoryo (cp -a /var/lib/postgresql/16/main /mnt/backup/pgdata_raw). Unya dagan sudo -u postgres /usr/lib/postgresql/16/bin/pg_resetwal -f /var/lib/postgresql/16/main, sugdi ang PostgreSQL sa single-user mode, ug pagdagan dayon pg_dumpall ngadto sa bag-ong gisugdan (initdb) cluster; ayaw ipadayon ang pagpadagan sa trapiko sa produksiyon sa usa ka cluster pagkahuman pg_resetwal.

Unsaon nako pagtangtang ang minilyon nga gagmay nga mga file kung rm -rf nagbitay o napakyas sa usa ka inode-ubos (df -i 100%) server?¶

Kung ang usa ka direktoryo adunay minilyon nga gagmay nga sesyon o mga file sa cache, ang indeks sa direktoryo niini (htree) motubo nga dako, hinungdan ls ug rm -rf aron mahunong ang pag-sort sa mga filename sa RAM. Hinuon, dagan sudo pagpangita /path/to/million_files -mindepth 1 -delete, o paghimo og walay sulod nga direktoryo sa RAM (mkdir /dev/shm/walay sulod) ug dagan sudo rsync -a --delete /dev/shm/empty/ /path/to/million_files/ aron ma-unlink dayon ang mga inode.

Ngano nga gipuno ni Docker ang akong tibuuk nga disk sa server kung gamay ra ang akong mga sudlanan, ug giunsa nako paglimpyo /var/lib/docker luwas?¶

Ang Docker nagtigum sa wanang sa disk sa wala gipunting nga JSON stdout logs (/var/lib/docker/containers/*/*-json.log), nagbitay sapaw2 mga layer sa imahe, ug buildkit cache. Dili man sa manual rm -rf mga folder sa sulod /var/lib/docker/overlay2/. Una putlon ang mga log sa JSON (sudo truncate -s 0 /var/lib/docker/containers/*/*-json.log) mao nga ang daemon adunay lawak sa pagginhawa, unya dagan sudo docker system prune -a -f (wala --mga tomo busa ang mga volume sa database nagpabilin nga wala matandog).

Mahimo ba nako nga mapalapad ang usa ka panganod nga EBS / padayon nga gidaghanon sa disk nga live samtang ang server naa sa 100% nga paggamit sa disk?¶

Oo, ang pagpalapad sa volume sa online molihok nga wala mag-reboot, nga adunay usa ka kuha: ang script sa katabang growpart /dev/nvme0n1 1 naningkamot sa paghimo sa usa ka temporaryo nga file sa /tmp naggamit mktemp ug napakyas sa 0 bytes nga libre. Likayi kana nga kapakyasan pinaagi sa pagdagan sudo TMPDIR=/dev/shm growpart/dev/nvme0n1 1 (gamit ang gipaluyohan sa RAM /dev/shm bukid) gisundan sa sudo resize2fs /dev/nvme0n1p1 (ext4) o sudo xfs_growfs / (XFS).

May kalabotan nga mga giya¶

• Aksidente nga rm -rf o Shift+Delete sa Linux, macOS, o Windows: diha-diha nga read-only remount
• Naka-encrypt nga SQLite, Signal, ug WhatsApp chat backup corruption ug local key extraction
• Nadaot nga Pulong, Excel, PDF, ug database file ug wala maluwas nga dokumento pagbawi
• SSD ug NVMe kalit nga read-only mode, 0% ekstrang blocks, ug TRIM disable rescue
• Ang krisis sa pag-host sa web, paglalin, ug pagpahiuli sa backup
• Mga numero sa emerhensya sa nasud

Mga tinubdan ug opisyal nga giya¶

• PostgreSQL Global Development Group: PostgreSQL 16 Opisyal nga Dokumentasyon - Kapitulo 30: Kasaligan ug ang Write-Ahead Log (WAL Configuration, Replication Slots, ug Recovery From Disk Full Failures).
• SQLite Consortium (sqlite.org): Unsaon Pagdaot sa SQLite Database File (File Locking, Unlinked Journal/WAL Files, ug ang .recover CLI Extension).
• Oracle Corporation / MySQL Documentation & MariaDB Foundation: InnoDB Crash Recovery, Binary Log Purge Procedures (PURGE BINARY LOGS), ug Temporary Tablespace (ibtmp1) Pagdumala.
• Ang Linux Kernel Organization (kernel.org): Ext4 Filesystem Administration (tune2fs Gireserba nga mga Block, Inode Tables, ug /proc/<pid>/fd/ File Descriptor Truncation).
• National Institute of Standards and Technology (NIST) (Estados Unidos): Espesyal nga Publikasyon 800-123: Giya sa General Server Security ug Availability Management.