VPN सर्भरको डिस्क वृद्धि कहाँबाट आउँछ र यसलाई कसरी सीमित गर्ने

टनेलले जडान स्वीकार गर्न छोड्छ, सेवा दुई पटक पुनः सुरु हुन्छ, र त्यसपछि उसको लगमा केही देखिँदैन। त्यही मौनता सङ्केत हो, किनकि डिस्क भर्ने लग नै हो र तपाईं पर्खिरहनुभएको त्रुटि लेख्न डेमनसँग ठाउँ छैन। जुनसुकै लामो समय चल्ने सेवा त्यो अवस्थामा पुग्न सक्छ, र logs नामको डाइरेक्टरी हटाउँदा त्यो विरलै सुध्रन्छ। टिकाउ समाधान भनेको कुन भण्डार बढ्यो, त्यसको संरक्षण नीतिको मालिक को हो, र लेखकले साँच्चै ठाउँ छोड्यो कि भनेर जान्नु हो।

बढेको भण्डार र त्यो बढेको दर पत्ता लगाउनुहोस्

बिर्सन सजिलो दुई सङ्ख्याबाट सुरु गर्नुहोस्: खाली ब्लक र खाली inode। फाइलसिस्टमले प्रशस्त ठाउँ रिपोर्ट गर्न सक्छ र तैपनि लेख्न अस्वीकार गर्न सक्छ, किनकि inode बाँकी छैन, र यो तब हुन्छ जब सेवाले प्रत्येक सत्रका लागि एउटा फाइल बनाउँछ। दुवै रिडिङ एउटै भोल्युममा माग्नुहोस्, किनकि जवाफहरू त्यही दिउँसो फरक पर्न सक्छन्। होस्ट स्वस्थ हुँदा यो गर्नुहोस्, ताकि सङ्ख्याहरूले सामान्य सञ्चालन वर्णन गरून्, अवरोध होइन।

df -h /var
df -i /var

त्यसपछि वृद्धिलाई मालिकसँग जोड्नुहोस्। journalको आफ्नै उपयोग सङ्ख्याले journal मात्र समेट्छ, र यसले आफ्नो कन्फिगरेसन फाइलको कुनै मार्गमा लेख्ने डेमनलाई कहिल्यै देख्ने छैन।

journalctl --disk-usage

समयसँगै हुने वृद्धिले कुनै एकल रिडिङभन्दा बढी बताउँछ। खुला छोडिएको डिबग स्तर, प्रत्येक प्रयास लग गर्ने पुनःप्रयास लूप, वा कसैले नरोकेको क्याप्चर फाइल: यीमध्ये प्रत्येक एक क्षणमा सामान्य र एक घण्टापछि चिन्ताजनक देखिन सक्छ। एउटा रिडिङ लिनुहोस्, व्यस्त अवधि पर्खनुहोस्, अर्को लिनुहोस्, र अन्तरालले भाग गर्नुहोस्। तपाईंले भन्न सक्ने दरले क्षमतालाई आगो होइन, निर्णय बनाउँछ।

रोटेसनले खुला फाइलमा के गर्छ

लग फाइल inodeतर्फ सङ्केत गर्ने नाम हो, र ठाउँ अन्तिम खुला ह्यान्डल बन्द भएपछि मात्र फर्कन्छ। फाइलको नाम परिवर्तन गर्नुहोस्, लेखक त्यही inode भर्न जारी राख्छ; हटाउनुहोस्, लेखक पूर्ण रूपमा नाम नभएको inode भर्न जारी राख्छ। यही अवस्थाका कारण 'मैले फाइल हटाएँ तर डिस्क भरिएको नै रह्यो' भन्ने वाक्यले बिग्रिएको फाइलसिस्टम होइन, फाइल डिस्क्रिप्टरको वर्णन गर्छ। लेखक पुनः सुरु गर्नु, वा फाइल पुनः खोल्ने रोटेसन विधि छान्नु नै ब्लक साँच्चै फर्काउने कुरा हो।

lsof +L1 | head

नीति फाइल लेख्ने घटकको हो। journalले आफ्नो कन्फिगरेसन फाइलबाट आफ्नै भण्डारण सीमा लागू गर्छ, जबकि फाइल-आधारित सेवा सामान्यतया logrotateमा भर पर्छ, या त बनाउने नियम र पुनः खोल्ने सङ्केतसँग, वा लेखक पुनः खोल्न नसक्दा ठाउँमै काट्ने विधिसँग। पहिले केही नबदली निर्णय पुष्टि गर्नुहोस्:

logrotate -d /etc/logrotate.conf

सीमा कहाँ हुनुपर्छ र कति ठूलो हुनुपर्छ

सीमा त्यहीँ राख्नुहोस् जहाँ लेखक कन्फिगर गरिएको छ, माउन्ट पोइन्टमा होइन। पूरै भोल्युममा कोटाले होस्ट जोगाउँछ तर कुन सेवा पहिले असफल हुन्छ भन्ने बताउँदैन, र विश्वव्यापी सफाइ स्क्रिप्टले अर्को घटनालाई चाहिने प्रमाण हटाउने प्रवृत्ति राख्छ। journal सीमा, अधिकतम आकारसहित रोटेसन सङ्ख्या, र अनुप्रयोग स्तरको संरक्षणले प्रत्येकले एक उत्पादकलाई सीमित गर्छ। सँगै तिनले कुल सीमित गर्छन्; एक्लैमा प्रत्येक अनुमान हो।

त्यो सीमा तपाईंले तर्क गर्न सक्ने संरक्षण अवधिबाट निर्धारण गर्नुहोस्, उपलब्ध खाली ठाउँबाट होइन। यदि समीक्षालाई एक हप्ताका जडान प्रयास चाहिन्छ भने, journalले सबैभन्दा व्यस्त अपेक्षित दरमा एक हप्ता राख्नुपर्छ, र त्यो दर अघि नापिएको सङ्ख्या हो।

डिबग लगिङ सुरु हुने समय अभिलेख गरिएको अस्थायी विधि हो, भण्डारण योजना होइन। गोपनीयताको प्रश्न त्यही निर्णयभित्र राख्नुहोस्, किनकि जडान लगले ठेगाना र पहिचानकर्ता बोक्छ। लामो संरक्षण पनि डेटा व्यवस्थापनको छनोट हो, र यो दुवै सीमा जान्ने व्यक्तिले गर्नुपर्छ।

रिस्टार्टपछि सीमा जाँच्नुहोस्

अर्को रिबुटसम्म टिक्ने संरक्षण परिवर्तन परिवर्तन होइन। लेखक पुनः सुरु गर्नुहोस्, नयाँ सीमा लागू हुन्छ भनी पुष्टि गर्नुहोस्, र त्यसपछि पनि रोटेसन चल्छ कि जाँच्नुहोस्। journalका लागि, एउटा रिस्टार्ट र एउटा उपयोग रिडिङले दुवै प्रश्नको जवाफ दिन्छ:

systemctl restart systemd-journald
journalctl --disk-usage

फाइल-आधारित सेवाका लागि, रोटेसनको काम एक पटक हातले चलाउनुहोस् र फाइल प्रतिस्थापित भयो तथा डिस्क्रिप्टर पुनः खुल्यो भनी पुष्टि गर्नुहोस्। पुरानो ह्यान्डल राख्ने लेखक सतही जाँचमा उत्तीर्ण हुन्छ र अर्को पटक भोल्युम भरिँदा असफल हुन्छ। परीक्षणका क्रममा खाली ठाउँ हेर्नुहोस्, किनकि फाइल सानो भयो तर ठाउँ फर्किएन भने पुरानो inode अझै समातिएको छ।

अर्को रिडिङलाई यससँग तुलना गर्नुहोस्

एक हप्तापछि फर्केर आउनुहोस् र वृद्धि दरलाई अभिलेख गरिएको दरसँग तुलना गर्नुहोस्। मिल्ने दर भनेको सीमा टिक्छ र भार स्थिर छ; दोब्बर दर भनेको केही परिवर्तन भयो, र उपयोगी प्रश्न के हो भन्ने हो। पहिले बारम्बार हुने असफलताका लागि लगको सामग्री पढ्नुहोस्, किनकि पुनःप्रयास लूप एकै साथ लक्षण र परिमाणको कारण हो। त्यसपछि नयाँ सक्षम गरिएका सबै कुरा जाँच्नुहोस्, घटनाका क्रममा खोलिएका र कहिल्यै बन्द नगरिएका डिबग स्तरसमेत।

ब्याकअप त्यही भोल्युमबाहिर राख्नुहोस्, वा एउटा भरिएको डिस्कले ब्याकअप पनि लग्छ भनी स्वीकार गर्नुहोस्। जुन होस्टको यसले संरक्षण गर्छ त्यसैमा लेखिएको प्रतिलिपि पुनःप्राप्ति योजना होइन, र त्यसको संरक्षणलाई आफ्नै जवाफ चाहिन्छ।

के, कहाँ, कति समय राखिन्छ र कसले हटाउँछ लेख्नुहोस्। त्यही वाक्य नतिजा हो, र यो यस कामको अर्को रिस्टार्टसम्म टिक्ने एक मात्र भाग हो।