네트워크 관리자 빵수의 이야기

넥스지 VPN 센터, 지점 구분 방법

by빵수 — Thu, 18 Sep 2025 14:38:51 +0900

넥스지 VPN 센터, 지점 구분 방법에 대해서 알아보자

[센터 조건]

1. EIX interface 설정에 destinatio any로 설정
2. crypto tunnel eix의 destination any로 설정
- network-list가 설정되어 있을 경우 ACL 개념으로 동작
- network-list ip list가 80개 이상 초과할 경우 버그성 장애 발생 가능성이 높음

[지점 조건]

1. EIX interface 설정에 destination host 지정
2. crypto tunnel eix의 destination host 지정

시스템 백업 RTO, RPO란?

by빵수 — Fri, 15 Aug 2025 11:59:41 +0900

시스템 백업 RTO, RPO에 대해서 알아보자

복구 시간 목표(RTO)의 정의

앞서 언급한 대로, 장애 및 다운타임이 비즈니스에 큰 타격을 줄 수 있습니다. 게다가 이러한 문제가 발생하면 IT 시스템과 인프라스트럭처가 다시 가동하고 최적의 상태로 운영될 때까지 시간이 걸립니다. 물론 실패할 때도 있습니다. 그러면 재작동하기 위한 개입이 필요합니다.

이러한 점을 알고 있어야 사고의 영향을 최소화할 수 있습니다. 운영에 차질을 빚기 전에 시스템을 다시 가동하고 실행하는 데 사용할 수 있는 시간을 알아야 합니다. 여기에 RTO의 역할이 있습니다.

RTO는 다운타임이 발생한 후 비즈니스 운영에 대한 차질을 최소화하면서 시스템 또는 애플리케이션을 복원하는 데 걸리는 시간을 계산하는 데 도움이 되는 필수 메트릭입니다. 즉, 해당 기업이 감당할 수 있는 다운타임의 양입니다.

서로 다른 시스템은 운영에 영향을 미치는 역할도 다르기 때문에 각각 고유한 RTO가 필요합니다. 각 시스템에 대해 RTO를 정의한 다음 신속한 시스템 복원을 위한 복구 전략을 개발할 수 있습니다.

따라서 RTO가 1시간이라면, 담당자는 이 기간 내에 시스템을 정상화해야 합니다.

RTO는 비즈니스 니즈에 부합하도록 설정해야 합니다. 이를테면 온라인 결제 시스템의 RTO는 컨텐트 관리 웹사이트의 RTO보다 짧아야 합니다. 이러한 방식으로 해당 기업이 직면한 리스크에 따라 복구 전략을 수립할 수 있습니다.

한편 수동으로 인보이스를 발행하면서 버틸 수 있는 회사라면 RTO를 1-2일 또는 그 이상으로 설정해도 좋습니다.

원칙적으로는 설정된 RTO 내에서 시스템을 다시 가동하고 실행하려고 합니다. 하지만 그러지 못할 때도 있습니다.

서비스 제공업체의 시스템이 자동을 멈추거나 자연 재해가 발생한 것처럼 극단적인 상황에서는 특히 그렇습니다.

그럴 때는 무작정 기다리다가 다운타임 비용으로 비즈니스가 심각한 상황에 처하게 두지 않고 중요 IT 기능을 아웃소싱하는 것이 좋습니다. 이러한 노력으로 RTO를 계속 점검하면서 다운타임을 최소화하고 궁극적으로는 잠재적 손실로부터 회사를 구할 수 있습니다.

복구 시점 목표란?

복구 시점 목표(RPO)는 RTO와 유사한 메트릭입니다. RPO는 어떤 사고나 장애가 발생한 이후에 해당 회사가 감당할 수 있는 최대 데이터 손실량을 측정합니다.

RTO가 시스템 복구 시간에 초점을 맞춘다면, RPO는 데이터 보호 및 복구 목표에 중점을 둡니다. RPO는 비즈니스 운영에 차질이 생기기 전까지 감당할 수 있는 데이터 에 손실량을 측정합니다.

RTO와 RPO의 차이점

RTO와 RPO는 백업 및 재해 복구 계획에 사용되는 두 가지 메트릭입니다. 측정 대상은 서로 다르지만, 해당 기업의 니즈에 따라 심사숙고하여 설정해야 합니다.

RTO와 RPO의 유사점

둘 다 사고나 장애 이후에 해당 기업이 복구하는 데 걸리는 시간을 측정하는 데 사용됩니다. 이러한 메트릭을 설정할 때 기업의 니즈, 리스크 프로필, 예산 및 기타 요소를 고려합니다.

RTO와 RPO의 차이점

RTO는 시스템을 다시 가동하고 실행하는 데 걸리는 시간에 초점을 맞추는 반면, RPO는 운영에 차질을 빚기 전까지 해당 기업이 감당할 수 있는 데이터 손실량을 측정한다는 점에서 다릅니다.

RTO가 중요한 이유

오늘날 기업의 주요 차별화 요소 중 하나가 프로세스를 뒷받침하는 기술입니다. 디지털화는 의심할 여지 없이 효율성을 높였고 고객 경험을 향상하며 비즈니스 운영을 혁신했습니다.

하지만 기업의 기술에 대한 의존도가 매우 높아졌는데, 만약 시스템이 멈추면 이는 심각한 문제가 됩니다. 다운타임에 막대한 비용이 들기 때문입니다. 따라서 적절한 RTO를 설정하는 것이 중요합니다.

다운타임은 직접적인 수익 손실은 물론 문제를 해결을 위한 추가 작업 시간, 그리고 IT 시스템을 교체하는 비용의 부담도 유발합니다. IT 시스템을 교체해야 하는 경우 총 비용이 1백만 달러를 넘어설 수도 있습니다. 따라서 다운타임 및 복구에 대비하는 것이 중요합니다.

바로 RTO가 그러한 활동을 뒷받침할 수 있습니다. 기업이 복구 프로세스를 철저히 파악하면서 장애로 인한 지연을 줄이는 데 도움이 됩니다. 또한 예기치 않은 다운타임이 일어날 때에 대비한 계획으로 신속히 정상화하고 재가동하면서 손실을 최소화하게 합니다.

RTO 계산

RTO 계산은 복잡할 수 있습니다. 다운타임 비용, 재해 복구 및 백업 솔루션에 대한 투자, 시스템을 다시 온라인 상태로 복원하는 데 드는 인건비, 규제 요건 등 여러 요인이 작용합니다.

RTO를 결정하려면, 이러한 모든 구성 요소를 고려하고 해당 기업의 리스크 프로필 및 예산을 토대로 타임라인을 설정하는 것이 중요합니다. 다음 사항도 고려하십시오.

장애 빈도 - 특정 유형의 장애가 얼마나 자주 발생하는가?
장애 심각도 - 장애의 결과가 얼마나 심각한가?
장애 비용 - 장애로 인해 얼마나 많은 비용을 부담해야 하는가?
장애 기간 - 장애가 얼마나 지속되는가?
장애의 영향 - 다운타임이 해당 기업에 비치는 경제적 및 사회적 영향

이러한 요소를 염두에 두고 이제 RTO 계산을 진행할 수 있습니다. 다음 단계를 따라야 합니다.

필수 프로세스별 최대 허용 다운타임 계산
주요 프로세스에 필요한 리소스 파악
모든 중요 절차에 필요한 툴을 확보하거나 개발하는 데 드는 시간 계산
RTO를 결정하기 위해 최대 허용 다운타임과 리소스 확보/개발에 필요한 시간 합산

RTO 달성 여부에는 여러 가지 요인이 작용할 수 있습니다. 따라서 올바른 백업 및 재해 복구 계획을 수립하는 것이 중요합니다.

백업 및 재해 복구 계획이 RTO 달성에 도움이 되는 이유

백업 솔루션 및 재해 복구 계획은 RTO를 달성하는 데 꼭 필요합니다. 이러한 솔루션을 통해 다운타임, 데이터 유출, 기타 위기로부터 신속하게 복구할 수 있습니다.

백업 계획에는 제공업체와 체결한 서비스 수준 계약(SLA)상의 보장된 RTO가 있어야 합니다. 또한 다음과 같은 기능을 제공해야 합니다.

해당 기업의 RTO는 다양한 기능과 함께 제공되는 백업 및 재해 복구 솔루션을 통해 달성할 수 있습니다. 그러한 솔루션을 활용하여 제로에 가까운 RTO 결과를 얻으려면, 다음과 같은 중요 기능에 관심을 기울이는 것이 좋습니다.

1. 즉각적인 복구 기능

제로에 가까운 RTO 목표를 달성하려면 즉각적인 결과를 제공하는 복구 옵션이 있어야 합니다. 이는 재해 복구 전략의 일부로 즉각적인 복원 기능을 갖추어야 하는 이유이기도 합니다. 그러면 저장된 시스템을 백업 스토리지에서 곧바로 부팅하고, 클라우드 스토리지와 같이 바로 사용 가능한 가상 모드에서 작동할 수 있습니다.

뜻하지 않은 다운타임 상황에서도 중단 없이 운영해야 하는 기업에는 없어서는 안 될 기능입니다. 그리고 의료 분야와 같이 특정 데이터를 신속하게 복원해야 하는 기업에도 도움이 됩니다.

2. 탄력적 스케줄링 정책

탄력적이고 조정 가능한 RPO 정책이 있어야 RTO를 성공적으로 달성할 수 있습니다. 기업의 현재 니즈에 따라 RPO를 조정할 수 있습니다.

예를 들어 RTO 요구 사항이 바뀌면 그에 따라 RPO 정책을 조정할 수 있습니다. 게다가 일반적으로 RPO는 특정 프로세스 또는 애플리케이션에 대해 설정되므로, 각각에 맞게 조정하는 것이 더 쉽고 효율적입니다.

i) CDP(Continuous Data Protection)

RTO 목표를 설정하려면 지속적인 데이터 보호(CDP)가 필요합니다. 그러면 변경 주기에 상관없이 모든 데이터가 백업되고 보호됩니다. CDP를 사용하면 사라졌거나 손상된 데이터를 신속하게 복원할 수도 있습니다.

CDP는 중요 워크로드에 사용할 수 있으나, 리소스 사용량이 많아 성능 및 안정성 문제가 발생할 수 있습니다. 따라서 대개 CDP는 파일 수준 백업으로 구현됩니다.

ii) NCDP(Near Continuous Data Protection)

NCDP는 실시간에 가까운 백업 및 복원을 보장하는 RPO 정책입니다. 또한 성능에 미치는 영향을 최소화하면서 몇 분 단위의 제한적 RTO도 제공합니다. 그러면 데이터가 사라지더라도 즉시 손쉽게 복원할 수 있습니다.

NCDP 솔루션은 제로에 가깝게 RTO 목표를 유지해야 하는 곳에 적합합니다. 그러나 CDP와 마찬가지로 NCDP도 리소스 사용량 때문에 성능 및 안정성에 부정적인 영향을 미칠 수 있습니다.

개별 단위 복구

개별 단위 복구 기능이 있으면 데이터 세트 전체를 복원하지 않고 개별 파일을 백업에서 복구할 수 있습니다. 이는 RTO 시나리오에서 대단히 유용합니다. 데이터 센트 전체가 복원될 때까지 기다리지 않고 개별 파일이나 객체를 신속하게 복원할 수 있기 때문입니다.

개별 단위 복구는 특정 프로세스의 구체적인 결과에 따라 RTO 정책에도 도움이 됩니다. 이러한 절차의 영향을 받는 구성 요소만 복원하면 됩니다. 다른 구성 요소는 복원할 필요 없습니다.

4. 재해 복구를 위한 오프사이트 카피본

RTO 목표를 이루려면 데이터의 오프사이트 카피본이 꼭 필요합니다. 이는 보조 데이터 리포지토리를 사용하면 기본 스토리지 위치에 재해나 장애가 발생하더라도 신속하게 복구할 수 있기 때문입니다.

5. 페일오버를 통한 실시간 복제

페일오버 기능을 활용하는 실시간 복제도 고려해야 할 RTO 관련 기능입니다. 이를 통해 데이터를 실시간으로 사용 가능한 상태로 유지할 수 있으며, 사라진 데이터를 복원할 때 수작업이 필요하지 않습니다.

아울러 기본 사이트와 보조 사이트 중 한쪽에 오류나 장애가 발생하더라도 다른 한쪽으로 신속하게 전환할 수 있습니다. 페일오버 기반 실시간 복제는 장애 및 다운타임을 최소화하면서 RTO 목표를 계속 달성하는 데 도움이 됩니다.

재해 복구 계획을 위한 팁

RTO 전략은 장애 상황에도 중단 없는 운영을 보장해야 하는 기업에 꼭 필요합니다. RTO 전략을 수립할 때 도움이 될 몇 가지 팁을 소개합니다.

1. 비즈니스와 IT의 연계 확인

재해 복구 계획 수립은 까다로운 과제입니다. 관계자들에게 이에 관한 베스트 프랙티스를 전달할 수 있으나, 예산 문제가 우선시되곤 합니다. 이러한 계획을 세울 때는 업계 표준 베스트 프랙티스 준수를 최우선에 두고 비용은 그 다음에 고려해야 합니다.

그리고 무엇보다도 역량과 기대치가 부합하는 것이 중요합니다.

2. 통합 재해 복구 계획 수립

RTO 전략에는 통합 재해 복구 계획이 포함되어야 합니다. 직원이 각종 장애로부터 복구하기 위해 수행해야 할 단계를 제시하고 각기 다른 팀의 역할과 책임을 정리해야 합니다.

재해 복구 계획에는 RPO, RTO, 데이터 백업, 복제 일정, 재해 복구 계획 테스트 프로세스에 관한 정보도 포함해야 합니다.

3. 재해 복구 계획 테스트

기업이 적시에 원활하게 운영 환경을 복구하려면 정기적으로 재해 복구 계획을 테스트해야 합니다. 이는 많은 IT 부서에서 까다로운 프로세스가 될 수 있으나, 애플리케이션 레벨까지 복구 테스트가 필요합니다. 그렇지 않으면 문제가 발생하기 마련입니다. 성공적으로 재해에 대비하려면 잠재적인 문제가 일어나기 전에 철저히 파악할 수 있어야 합니다.

재해 복구 테스트를 가볍게 여겨서는 안 됩니다. 프로덕션 레벨까지 포괄하는 종합적인 엔드투엔드 테스트 절차가 되어야 합니다. 이제 재해 복구의 초점이 서버에서 애플리케이션으로 이동해야 합니다. 다계층 클라이언트 서버 및 웹 기반 구조, 그리고 이들 간의 상호 종속성과 같은 복잡한 속성 때문입니다.

준비가 소홀하면 문제가 발생할 가능성이 높아집니다. 따라서 이러한 테스트는 해당 기업이 만일의 재해를 견딜 수 있는지 알아보는 차원에서 애플리케이션 레벨까지 무사히 수행해야 합니다!

새로운 위협이 등장하고 기존 위협도 진화를 거듭하는 만큼 재해 복구 계획에도 변화가 필요합니다. 현재의 트렌드와 위협 요소를 제대로 다루도록 정기적으로 테스트하고 업데이트해야 합니다.

4. 재해 복구의 책임 정의

복구 시간 목표를 정의하는 것은 모든 RTO 계획에서 성공을 좌우하는 중요한 요소입니다. 특정 부서 또는 팀에 책임을 부여하고 각자의 구체적인 역할을 이해하게 하는 것이 필요합니다.

재해 발생 시 신속하게 조치할 수 있도록 모든 관계자에게 RTO 계획의 변동이나 업데이트를 알리는 것도 중요합니다. 특히 장애나 데이터 유출 사고 상황에서 구체적인 임무를 완수해야 하는 담당자를 결정하고 임명할 때에도 이 점에 유의해야 합니다.

5. 정기적으로 RTO 계획 업데이트

또 다른 핵심 단계는 정기적으로 계획을 업데이트하는 것입니다. 여기에는 새로운 RPO, RTO, 데이터 백업 정보로 업데이트하고 더는 의미 없는 기존 프로세스 또는 절차를 변경하는 것이 포함됩니다. 그리고 최근에 애플리케이션이나 시스템을 업그레이드한 경우 이러한 변경 내용도 RTO 계획에 반영해야 합니다.

6. 현실적인 목표 설정

RTO 계획을 세울 때는 현실적인 목표를 갖는 것이 중요합니다. 여기에는 장단기 목표가 모두 이러한 포함되어야 합니다. 지정된 시간 내에 주요 운영 환경을 복원하거나, 특정 기간 내에 시스템을 완전 정상 작동 상태로 복구하는 것 등이 해당합니다.

현실적이고 달성 가능한 RTO 목표를 세우려면 현재 기술 상황, 가용 리소스, 그리고 장애나 데이터 유출 사고 상황에서 발생할 만한 잠재적 위협이나 리스크를 고려해야 합니다. 복구 시간 목표를 세웠다면 정기적으로 테스트하여 아직도 달성 가능한지 확인하십시오.

7. 안전한 백업 유지

RTO와 관련해서는 믿을 수 있는 최신 버전의 백업이 꼭 필요합니다. 한층 더 강력한 보안을 위해 정기적으로, 가급적 여러 플랫폼에 데이터를 백업해야 합니다. 또한 데이터를 백업할 때 데이터 손실을 줄이는 차원에서 최신 버전의 데이터를 저장해야 합니다.

백업은 RTO 또는 RPO를 달성하지 못한 상황에서 더 빠르게 복구하는 데 도움이 될 수 있습니다. 안전한 백업이 있으면 다운타임과 장애를 최소화하면서 데이터와 시스템을 복원하는 일이 더 수월해집니다.

베리타스의 해결 방법

믿을 만한 RTO 솔루션을 찾는 기업이라면 베리타스를 고려해야 합니다. 베리타스 솔루션은 RTO 또는 RPO 위반 상황에서 빠르고 효과적으로 운영 환경을 복원하도록 지원합니다. 다양한 자동화 툴, 분석, 엔드투엔드 통합 RTO 기능으로 해당 기업이 위협에 미리 대비하고 대응할 수 있게 합니다.

베리타스와 함께할 경우 다음과 같은 이점을 누릴 수 있습니다.

자동화된 RTO 및 RPO 계획 - 베리타스 솔루션은 계획 프로세스를 자동화하여 RTO 또는 RPO와 관련된 각종 위협이나 위반에 대비할 수 있게 합니다. 그러면 기업은 잠재적인 위협을 방지하고 보안 위반이 발생하더라도 가동 중단을 최소화할 수 있습니다.
엔드투엔드 통합 RTO 기능 - 베리타스의 엔드투엔드 통합 기능에는 데이터 백업, 복구 테스트, RPO 및 RTO 계획 등이 포함되어 있어 통합 복구 시간 목표 계획을 수립할 수 있습니다.
분석 및 리포트 - RTO 추이를 모니터링하고 잠재적 RTO 위협을 파악하는 데 도움이 될 분석 및 리포트를 제공합니다. 이를 활용하여 각종 보안 위반에 대비하고 실제 상황에서도 가동 중단을 최소화할 수 있습니다.
첨단 분석- 베리타스 RTO 솔루션은 첨단 분석 기능도 제공하면서 기업의 RTO 및 RPO 추이를 분석하면서 각자의 전략에 관한 더 나은 인사이트를 확보할 수 있게 합니다.

RTO 계획은 RTO 또는 RPO 위반에 따른 다운타임과 혼란을 줄이려는 기업에 필수 조건입니다. 현실적이고 달성 가능한 목표 수립은 안전한 백업 및 엔드투엔드 통합 RTO 기능을 갖추는 것만큼이나 중요합니다.

베리타스 RTO 솔루션은 기업에서 RTO 관련 위협에 대비하고 실제 상황에서 혼란을 최소화하도록 지원합니다. 베리타스 솔루션으로 RTO 및 RPO에 미리 대비하는 것은 물론 분석을 활용하여 추이를 통해 파악하고 잠재적 위협을 식별할 수 있습니다.

그러므로 바로 지금 베리타스에 문의하여 베리타스 솔루션, 그리고 베리타스와 함께 통합 전략을 수립할 방법도 알아보십시오.

출처

https://www.veritas.com/ko/kr/information-center/rto

Putty Key gen 등록 방법

by빵수 — Tue, 17 Jun 2025 09:48:38 +0900

https://kamang-it.tistory.com/entry/PuTTYprivate-keyppkpem%EB%A5%BC-%EC%9D%B4%EC%9A%A9%ED%95%98%EC%97%AC-ssh%EC%A0%91%EA%B7%BC%ED%95%98%EA%B8%B0

[PuTTY]private key(ppk,pem)를 이용하여 ssh접근하기

윈도우에서는 보통 PuTTY를 사용하여 ssh원격접속을한다.그런데 ec2같은 인스턴스를 사용할경우 일반적으로는 ppk를 사용한다.이걸 잘 못하는 사람이 있어서 쉽게 하는방법을 포스팅 하려고한다.

kamang-it.tistory.com

AWS Cloudwatch를 사용한 EC2 memory 확인 방법

by빵수 — Sat, 1 Mar 2025 17:10:39 +0900

https://dev.classmethod.jp/articles/try-installing-cloudwatch-agent-on-ec2-instances/

EC2 인스턴스에 CloudWatch Agent를 설치해서 메모리 사용량 확인해 보기 | DevelopersIO

EC2 인스턴스에 CloudWatch Agent를 설치해서 EC2 인스턴스 메모리 사용량을 확인하는 과정을 정리해 봤습니다.

dev.classmethod.jp

CPU 확인 방법

https://docs.aws.amazon.com/ko_kr/AWSEC2/latest/UserGuide/US_SingleMetricPerInstance.html

특정 인스턴스에 대한 통계 가져오기 - Amazon Elastic Compute Cloud

이 페이지에 작업이 필요하다는 점을 알려 주셔서 감사합니다. 실망시켜 드려 죄송합니다. 잠깐 시간을 내어 설명서를 향상시킬 수 있는 방법에 대해 말씀해 주십시오.

docs.aws.amazon.com

Cisco switch interface counters errors

by빵수 — Fri, 31 Jan 2025 13:54:58 +0900

interface counters errors 관련하여 내용 확인하기

[show interface counters errors]
- Xmit-Err : 인터페이스에서 송신 중 발생한 오류의 수
- OutDiscards : 인터페이스의 송신 queue에서 전송할 수 없는 패킷을 drop한 수.

[위의 errors 발생 원인]
1. 급등하는 Burst 트래픽으로 인터페이스에 과부하 발생 시, Buffers와 queue의 한도 초과로 패킷 처리가 불가능 할 때.
2. Burst 트래픽 발생시 연결된 장비의 인터페이스 과부하로 패킷 Drop.
3. 연결된 장비와 Speed & Duplex 불일치.
4. 물리적 문제 (케이블 손상 및 장비 성능 등)

[show interface Gi 1/0/8]

- Total Output Drops : output queue가 부족해 drop된 패킷의 수.

아래의 show 결과값을 확인하면 interface의
- Xmit-Err & OutDiscards 와 Total output drops이 동일.
- input errors와 Rcv-Err는 0 으로 확인.
- 주요 오류 유형 0으로 확인.

위의 결과로 보았을 때, interface counters errors가 증가하는 원인은
Brust 트래픽 발생시 Buffers와 queue의 한도 초과로 인한 패킷 Drop입니다.

#show interface counters errors

#show interface 의 Total output drops

#show interface Gi 1/0/8

Linux 특정 파일 경로를 찾는 방법

by빵수 — Fri, 24 Jan 2025 11:04:55 +0900

Linux 특정 파일 경로를 찾는 방법 대해서 알아보자

1. find 명령어 (디렉토리 전체에서 파일 검색)

특정 파일을 전체 디렉토리에서 찾을 때 사용

bash

복사편집

find / -name "파일명" 2>/dev/null

설명:

/ → 루트 디렉토리에서 검색 (전체 시스템 검색)
-name → 파일명을 정확히 일치하는 것만 찾음
2>/dev/null → 접근 권한이 없는 디렉토리에서 발생하는 오류 메시지를 숨김

예제: test.txt 파일 찾기

bash

복사편집

find / -name "test.txt" 2>/dev/null

대소문자 구분 없이 검색 (-iname)

bash

복사편집

find / -iname "test.txt" 2>/dev/null

파일 크기, 수정 시간 기준으로 찾기

최근 3일 이내에 수정된 파일 찾기:

bash

복사편집

find /home -name "*.log" -mtime -3
100MB 이상의 파일 찾기:

bash

복사편집

find /var/log -size +100M

2. locate 명령어 (빠른 검색)

시스템에 색인된 파일을 빠르게 검색할 때 사용

bash

복사편집

locate test.txt

설명:

locate는 미리 생성된 데이터베이스를 기반으로 검색하여 속도가 빠름.
하지만, 최신 변경 사항이 반영되지 않을 수도 있음.
최신 상태로 업데이트하려면 먼저 아래 명령어 실행:

bash

복사편집

sudo updatedb

3. which 명령어 (실행 파일 위치 찾기)

실행 가능한 바이너리(명령어)의 경로를 찾을 때 사용

bash

복사편집

which python

출력 예시:

bash

복사편집

/usr/bin/python

➡ python 실행 파일이 /usr/bin/에 위치함을 의미.

4. whereis 명령어 (실행 파일 + 관련 파일 검색)

실행 가능한 파일과 매뉴얼(man page)까지 포함하여 검색

bash

복사편집

whereis python

출력 예시:

bash

복사편집

python: /usr/bin/python /usr/lib/python3.8 /usr/share/man/man1/python.1.gz

➡ python 실행 파일뿐만 아니라 관련 라이브러리 경로도 함께 출력됨.

5. type 명령어 (명령어의 실제 경로 확인)

셸이 특정 명령어를 어떻게 해석하는지 확인

bash

복사편집

type -a ls

출력 예시:

bash

복사편집

ls is aliased to `ls --color=auto` ls is /bin/ls

➡ ls 명령어는 /bin/ls에서 실행되며, --color=auto 옵션이 적용된 별칭(alias)도 존재함.

6. grep을 활용한 검색 (ls, ps 조합)

특정 경로 내에서 파일명 검색 (단순한 경우)

bash

복사편집

ls -l /var/log | grep "syslog"

실행 중인 프로세스에서 특정 파일 검색

bash

복사편집

ps aux | grep "nginx"

7. 전체 시스템에서 grep을 활용한 검색 (find + grep)

특정 파일 내용을 검색하며 파일 경로까지 찾기

bash

복사편집

find / -type f -exec grep -l "search_text" {} + 2>/dev/null

➡ 파일 내용 중 search_text를 포함하는 모든 파일을 찾음.

8. fd (고성능 파일 검색 도구)

find보다 빠른 검색이 가능하며, 설치가 필요함.

bash

복사편집

sudo apt install fd-find # Ubuntu/Debian sudo yum install fd-find # RHEL/CentOS

설치 후 실행:

bash

복사편집

fd "test.txt"

9. du 명령어를 사용한 특정 파일 검색 (디스크 사용량 확인)

파일 크기와 함께 검색하려면 du 사용

bash

복사편집

du -ah / | grep "test.txt"

➡ test.txt 파일과 해당 파일의 크기 출력.

정리

명령어용도

find / -name "파일명"	전체 시스템에서 파일 검색
locate 파일명	빠르게 파일 경로 검색 (updatedb 필요)
which 명령어	실행 가능한 파일 위치 검색
whereis 명령어	실행 파일 + 관련 파일 검색
type 명령어	명령어의 실제 위치 확인
grep -r "텍스트" /경로	특정 텍스트가 포함된 파일 검색
fd 파일명	find보다 빠른 검색 (설치 필요)

원격관리툴 mRemoteNG - SSH Key 접속 이슈 해결 방법

by빵수 — Thu, 5 Dec 2024 10:46:25 +0900

원격관리툴 mRemoteNG을 사용하면서 SSH Key 접속이 안되는 이슈에 대해서 알아보자.

Step1.

mRemoteNG - Putty Connect Version check

Step2.

Putty Release Version Update

설치 버전 0.81

최신 버전 0.82

Step3.

Release Version Putty to mRemoteNG Path Connect

Cisco Router, Switch Debug

by빵수 — Thu, 17 Oct 2024 17:29:10 +0900

https://kyundev.tistory.com/26

[Network] Cisco Router Debug

Router Debug 란? 디버그는 show 명령어와 유사한 명령어입니다. show 명령어가 단편의 일부를 보여 주는 것이라면 debug는 실시간으로 동작 상황을 보여줍니다. 하지만 debug 명령어를 사용할 시 신중하

kyundev.tistory.com

Windows RDP Port 변경

by빵수 — Wed, 25 Sep 2024 11:40:14 +0900

Windows RDP Port 변경에 대해서 알아보자

원격 데스크톱 기본 접속 포트는 3389이며 보안 강화를 위해 변경하시길 권장한다.

포트를 변경하기 이전에 기존에 설정되어 있는 방화벽 설정에 변경할 포트를 미리 허용하셔야 추후에 다시 접근이 가능하다 변경 전 OS 방화벽설정 및 카페 24 방화벽 설정 값을 체크 후 변경 바랍니다.

원격 데스크톱 포트 설정하기
가상서버에 접속하여 실행(윈도우키 + R) - regedit 입력 후에 아래 경로를 참고하여 원하시는 포트로 변경합니다.
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlTerminal ServerwdsrdpwdTdstcp
-> PortNumber 기본값 3389 (10진수)에서 -> 변경하고 싶은 포트로 변경 합니다.

HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlTerminal ServerWinStationsRDP-Tcp
-> PortNumber 기본값 3389 (10진수) -> 변경될 포트로 변경한다.
서비스를 재시작한다.
실행(윈도키+R) services.msc 입력 -> Remote Desktop Services 항목 재시작
변경된 포트로 원격데스크톱 접속 여부를 확인합니다.

출처

https://cafe24.zendesk.com/hc/ko/articles/9504340705433-%EC%9C%88%EB%8F%84%EC%9A%B0-%EA%B0%80%EC%83%81%EC%84%9C%EB%B2%84-%EC%9B%90%EA%B2%A9%EB%8D%B0%EC%8A%A4%ED%81%AC%ED%83%91-RDP-%ED%8F%AC%ED%8A%B8-%EB%B3%80%EA%B2%BD-%EB%B0%A9%EB%B2%95%EC%9D%84-%EC%95%88%EB%82%B4%ED%95%A9%EB%8B%88%EB%8B%A4

Cisco Switch interface error 설명

by빵수 — Mon, 9 Sep 2024 14:23:52 +0900

Cisco Switch interface error에 대해서 알아보자

Cisco Switch에서는 인터페이스에 대한 에러 카운트를 보기 위해서는 아래와 같이 명령어를 사용한다.

명령어 : show interfaces counters error

Port / Align-Err / FCS-Err / Xmit-Err / Rcv-Err / UnderSize / OutDiscards

Te2/1 0 0 0 0 0 0

Te2/2 0 0 0 0 0 0

Te2/3 0 0 0 0 0 0

Te2/4 0 0 0 25 0 0

Te3/1 0 0 0 0 0 0

Te3/2 0 0 0 0 0 0

Te3/3 0 0 0 0 0 0

Te3/4 0 0 0 656 0 0

위에서 보면 Te3/4에서 Rcv-Err가 많이 올라옴을 알 수 있다.
명령어를 통해 해당 인터페이스에 대한 상세 에러를 다시 보면 아래와 같다.

명령어 : sh interfaces te3/4 counters errors

Port / Align-Err / FCS-Err / Xmit-Err / Rcv-Err / UnderSize / OutDiscards

Te3/4 0 0 0 944 0 0

Port / Single-Col / Multi-Col / Late-Col / Excess-Col / Carri-Sen / Runts

Te3/4 0 0 0 0 0 0 0

에러의 종류와 원인

Align-Err, FCS-Err, Xmit-Err, Rcv-Err... 등 많은 에러 정보들이 있다.
각각의 의미는 아래와 같다.

[Align-Err]
Description(서술): 이 에러는 받은 패킷들이 헤더에 명료 된 사이즈보다 길 때 또는 CRC 체크가 실패할 때 나타납니다.
Common Causes(원인): 이 증상은 듀플렉스가 맞지 않을 때 또는 캐이블, 랜카드 그리고 접속된 포트가 이상 시 발생합니다. 스위치 디바이스에 랜포트를 연결 시 나타날 수 있으며 또 다른 가능성으로 허브에 연결 시 충돌이 발생하는데 그 이유로 발생할 수 있습니다.

[babbles]
Description(서술): Cisco IOS sh interfaces counter.
이 에러는 1518 octets보다 긴 패킷을 보낼 때 전송 실패 시 나타납니다. 증상이유는 alignment 에러로 발생할 수 있으며 FCS 에러로도 발생할 수 있습니다.

[Carri-Sen]
Description(서술): CatOS sh port and Cisco IOS sh interfaces counters errors.
CSMA/CD의 개념이 이곳에 적용됩니다. 이 counter의 증가는 매번 하프 듀플렉스 연결을 통해 데이터를 보낼 때 발생합니다.

[collisions]
Descriptions(서술): Cisco IOS sh interfaces counter. 프레임을 전송하기 전에 충돌이 발생한 수를 나타냅니다.
Common Causes(원인) : 일반적으로 half 듀플렉스 모드에서 발생하며 풀 듀플렉스 모드에서는 볼 수가 없다네요. 만약 충돌 횟수가 눈부시게 증가할 경우에는 접속된 링크가 열라 바쁘거나 아님 듀플렉스 모드에 이상이 있을 수 있다. 참고로 하프 듀플렉스는 원 웨이를 말하며 풀 듀플렉스는 2차선 도로를 말합니다.

[CRC]
Description(서술): Cisco IOS sh interfaces counter. 1층에서 점검 시, 랜 전송 구간에서 발생하며 또는 받는 쪽 장비에서 해석하지 못할 시에도 발생합니다.
Common Causes(원인): 이 증상은 일반적으로 1층 구간의 노이즈나 전송구간에서 발생합니다. CRC의 증가는 충돌이 발생해서 생길 수 있으며 물리적인 문제로 발생될 수 있습니다. 이를 해결하는 방법은 구간 구간마다 루프 테스트를 통해 확인합니다.

[deferred]
Description(서술): Cisco IOS sh interfaces counter. 이 필드는 하프 듀플렉스 모드에서 발생하며 프레임이 전송되긴 하나 늦게 보낸 수를 나타냅니다. 이유는 라인이 바빠서 생깁니다.

[input packets with dribble condition]
Description(서술) : Cisco IOS sh interfaces counter. 이 드리블 에러는 프레임이 얇고 길어서 발생한다고 합니다.
Common Causes(원인): 이 프레임 에러는 스위치가 프레임을 받은 수를 나타냅니다. (에러로 표현하기엔 조금 이상하네요)

[Excess-Col]
Description(원인): CatOS sh port and Cisco IOS sh interfaces counters errors.
이 프레임의 수는 최초 충돌 발생 후 재 시도 횟수가 16번 이상이 되면 패킷을 버리게 되는데 그 수를 나타냅니다.
Common Causes(서술): 이 에러는 전형적으로 하프 듀플렉스 모드 사용 시 라인이 바쁘기 때문인데 해서 세그먼트를 쪼개는 필요함을 나타내고 또는 듀플렉스가 맞지 않을 때도 발생합니다. 풀 듀플렉스에서는 볼 수가 없습니다.

[FCS-Err]
Description(서술): 이 에러는 프레임을 받은 후 프레임을 FCS와 같이 맞추어 볼 때 발생합니다. 해서 발생지에서는 발생하지 않습니다.
Common Causes(원인): 이 에러는 물리적인 구간에서 발생하거나 듀플렉스가 맞지 않을 때 발생합니다.

[frame]
Description(원인): Cisco IOS sh interfaces counter. 이 패킷의 수는 CRC에러와 Alignment 에러와 같이하며 옳지 못한 패킷을 받았을 때 발생합니다.
Common Causes(서술): 이 에러는 물리적인 구간에서 발생하거나 듀플렉스가 맞지 않을 때 발생합니다.

[Giants]
Description(서술): CatOS sh port and Cisco IOS sh interfaces and sh interfaces counters errors.
이더넷 상황에서 IEEE802.3 프레임 사이즈는 최소 64바이트에서 1518 바이트를 사용할 수 있는데 이 프레임이 과잉되고 FCS의 처리가 불가할 때 나타납니다.
Common Causes(원인): 이 증상은 많은 부분에서 NIC의 문제이며 짜증나게 하는 이 장비를 네트워크에서 찾고 버립니다.
Platform Exceptions - Catalyst Cat4000 Series running Cisco IOS
12.9 버전에서는 giants의 수가 1518 바이트보다 클 경우 발생했으나, 12.1 이후부터는 바이트보다 클 경우, 그리고 FCS를 처리할 수 없을 경우 함께하여 나타냅니다.

[ignored]
Description(서술): Cisco IOS sh interfaces counter.
물리적인 인터페이스가 가진 버퍼가 수용할 수 있는 패킷 수를 넘을 시 버려지게 됩니다.
Common Causes(원인): 이유는 브로드케스트 스톰과 라인 노이즈로 인해 버려지는 수가 증가할 수 있습니다.

[Input errors]
Description(서술): Cisco IOS sh interfaces counter.

Common Causes(원인): 이 에러는 runts, giants, no buffer, CRC, Frame overrun 과 여러 다른 이유로 발생된 에러들을 총괄하여 나타냅니다. 하지만 상위 레이어에서 발생되는 에러들은 카운트에서 제외됩니다.

[Late-Col]
Description(서술): CatOS sh port and Cisco IOS sh interfaces and sh interfaces counters errors.
충돌이 발생한 인터페이스에는 이 값이 나타납니다. 10Mbit/s 구간에서 패킷 전송을 하는 과정 중 필요시간이 512 bit-times(51.2 microseconds) 초과된 패킷 수를 나타냅니다.
Common Causes(원인): 이 에러는 듀플렉스가 맞지 않을 경우 발생될 수 있습니다. 역시 하프 듀플렉스 모드에서 발생되며 케이블과 세그먼트가 너무 긴 경우 발생됩니다. 풀 듀플렉스 모드에서는 볼 수 없습니다.

[lost carrier]
Description(서술): Cisco IOS sh interfaces counter. 전송 중 패킷이 없어졌을 때 발생합니다.
Common Causes(원인): 캐이블 점검 및 장비의 인터페이스를 양쪽에서 점검.

[Multi-Col]
Description(서술): CatOS sh port and Cisco IOS sh interfaces counters errors. 이 에러는 프레임 전송 중 다수의 충돌이 발생된 것을 나타냅니다.
Common Causes(원인): 약간의 충돌은 정상적이다. 그러나 충돌 발생 비율이 4~5%씩 증가하면 장비의 장애 유무를 확인하거나, 새로운 세그먼트를 만들어 사용자를 나누는 것이 필요.

[no buffer]
Description(서술): 패킷이 버려진 것을 나타내며 이유는 장비내의 버퍼 공간이 없기 때문입니다.
Common Causes(원인): Ignored 숫자와 비교해 보세요. 가끔 브로드케스트 스톰이 이 증상의 이유가 됩니다.

[no carrier]
Description(서술): Cisco IOS sh interfaces counter. 전송되는 동안 carrier가 제공되지 안된 수를 나타냅니다.
Common Causes(원인) 케이블 점검 및 장비의 인터페이스를 양쪽에서 점검.

[Out-Discard]

Description(서술):에러가 발생되지 않았으나 패킷 전송에 필요한 버퍼가 모자랄 경우 발생됩니다.

[output buffer failures output buffers swapped out]
Description(서술): Cisco IOS sh interfaces counter.
Common Causes(원인) : 1기가 멀티캐스트 스티림을 100 Mbps로 이루이진 24 포트 장비를 통해 다수의 클라이언트에게 전송 시 일반적으로 나타나며 숫자들은 이것을 나타냅니다.

[overrun]
Description(서술): 이 에러는 들어온 패킷을 receiver가 처리할 수 없을 시 나타납니다.
Common Cause(의미): 트래픽이 receiver의 처리용량을 초과 할 경우 발생

[packets input/output]
Description(서술): 정상적인 패킷이 전송되고 받은 수를 나타냅니다. 이 숫자를 모니터링함으로써 트래픽이 인터페이스를 통해 적절히 흐르는 지를 볼 때 유용한 하다고 하네요.

[Rcv-Err]
Description(서술): CatOS show port or show port counters and Cisco IOS (for the Catalyst 6000 Series only) sh interfaces counters error
Common Causes(의미): See Platform Exceptions below.
Platform Exceptions: Catalyst 5000 Series

버퍼 실패가 나타나는 이유는 과잉된 트래픽의 결과로 증가할 수 있으며 Runt와 Giant 그리고 FCS-err과는 관계되지 않습니다.

On Catalyst 4000 Series 카탈리스트 5000과 비교하면 이 애러는 Runt, Giant 그리고 FCS-Err을 포함합니다.

[Runts]
Description(서술): CatOS sh port and Cisco IOS sh interfaces and sh interfaces counters errors
이 에러는 받은 프레임의 CRC가 좋지 않고 또한 IEEE 802.3프레임 사이즈 보다 작을 경우 발생합니다.
Common Causes(의미): 듀플렉스가 맞지 않거나 물리적인 문제입니다. 이를테면 케이블 불량 및 포트 또는 인터페이스카드의 불량에서 나타납니다.

Platform Exceptions: Catalyst 4000 Series running Cisco IOS
12.1 버전에서 런츠는 언더사이즈였으며 이것은 64 바이트보다 작을 때 나타냅니다. 그 후의 버전 12.1에서는 런츠는 Fragment입니다. Fragment가 64byte보다 작고 나쁜 CRC값을 가졌음을

[Single-Col]
Description(서술): CatOS sh port and Cisco IOS sh interfaces counters errors.
이 에러는 프레임이 인터페이스를 통해 전송되기 전 발생된 충돌을 나타냅니다.
Common Causes(의미): 일반적으로 half 듀플렉스 모드에서 발생하며 풀 듀플렉스 모드에서는 볼 수가 없습니다. 만약 충돌 횟수가 눈에 확 띄게 증가할 경우에는 접속된 링크가 몹시 바쁘거나 아님 듀플렉스 모드에 이상이 있을 수 있습니다.

[underruns]
Description(서술) : 송신장치가, 스위치가 감당하지 못할 만큼 빠르게 동작할 경우 발생합니다.
Common Causes(의미) : 이 증상은 높은 전송률을 나타내는 구간에서, 한 순간 하나의 인터페이스에 다수의 다른 인터페이스가 몰릴 경우 발생합니다. 언더런은 인터페이스 리셋을 가져옵니다.

[Undersize]
Description(서술): CatOS sh port and Cisco IOS sh interfaces counters errors
우리가 잘 알고 있는 것과는 달리 받은 프레임이 IEEE 802.3말하는 최소 64 바이트 보다 작을 때 발생(Framing bit는 포함되지 않고 FCS 옥택은 포함)
Common Causes(의미): 이 프레임이 보내진 장비 점검.

[Xmit-Err]
Description(서술): CatOS sh port and Cisco IOS sh interfaces counters errors
버퍼가 가득 찼을 때 발생됨.
Common Causes(의미): 일반적으로 Xmit-Err은 높은 값을 갖는 밴드위드에서 작은 값을 갖는 밴드위드로 나갈 때 또는 하나의 출구에 다수의 트래픽이 몰릴 경우 발생합니다. 예를 들면, 만약 1기가 밴드위드로부터 다량의 데이터가 100 Mbps의 포트로 몰린다면 이것은 Xmit-Err의 수를 증가시킵니다. 들어오는 입구와 출구의 밴드위드가 다를 경우 많은 양의 데이터가 Output 버퍼를 압도할 경우가 이에 해당합니다.
참조링크

https://www.netbuysell.co.kr/global_asp/board/board_view.asp?K_no=3913&page=&Hit_Plus=9&Codeno=2&Pgtype=A&Html_change=

원인분석
관리되고 있는 장비는 C6500이다. C6500의 rcv-err 관련 내용은 아래 글을 읽어보자

https://supportforums.cisco.com/thread/186074

아래 링크는 시스코 인터페이스 관리에 대한 문서이다.
http://www.cisco.com/en/US/products/hw/switches/ps708/products_tech_note09186a00800a7af0.shtml

Rcv-Err 에러에 대한 원인은 아래와 같이 나와 있다.

This is an indication of excessive output rates of traffic. This is also an indication that the receive buffer is full. This counter must be zero unless there is excessive traffic through the switch. In some switches, the Out-Lost counter has a direct correlation to the Rcv-Err.

해석해 보면 수신버퍼의 가득 차서 생긴 에러라고 나온다.
시스코 버퍼관련 문서를 아래 링크를 참조 바란다.

http://www.cisco.com/en/US/products/hw/routers/ps133/products_tech_note09186a00800a7b80.shtml

버퍼확인

우리는 실제 시스코 장비를 최적화(튜닝)가 필요한지는 결정하기 위해 show interfaces와 show buffers 명령어로 이를 확인할 수 있다.

#sh buffers
Buffer elements:
499 in free list (500 max allowed)
1193565061 hits, 0 misses, 0 created

Public buffer pools:
Small buffers, 104 bytes (total 1024, permanent 1024):
1018 in free list (128 min, 2048 max allowed)
719162597 hits, 0 misses, 0 trims, 0 created
0 failures (0 no memory)
Medium buffers, 256 bytes (total 3000, permanent 3000):
2970 in free list (64 min, 3000 max allowed)
15620707 hits, 0 misses, 0 trims, 0 created
0 failures (0 no memory)
Middle buffers, 600 bytes (total 512, permanent 512):
508 in free list (64 min, 1024 max allowed)
22609311 hits, 0 misses, 0 trims, 0 created
0 failures (0 no memory)

출처

https://blog.naver.com/seomanjae/221758779605

네트워크 관리자 빵수의 이야기

넥스지 VPN 센터, 지점 구분 방법

시스템 백업 RTO, RPO란?

시스템 백업 RTO, RPO에 대해서 알아보자

복구 시간 목표(RTO)의 정의

복구 시점 목표란?

RTO와 RPO의 차이점

RTO와 RPO의 유사점

RTO와 RPO의 차이점

RTO가 중요한 이유

RTO 계산

백업 및 재해 복구 계획이 RTO 달성에 도움이 되는 이유

1. 즉각적인 복구 기능

2. 탄력적 스케줄링 정책

i) CDP(Continuous Data Protection)

ii) NCDP(Near Continuous Data Protection)

개별 단위 복구

4. 재해 복구를 위한 오프사이트 카피본

5. 페일오버를 통한 실시간 복제

재해 복구 계획을 위한 팁

1. 비즈니스와 IT의 연계 확인

2. 통합 재해 복구 계획 수립

3. 재해 복구 계획 테스트

4. 재해 복구의 책임 정의

5. 정기적으로 RTO 계획 업데이트

6. 현실적인 목표 설정

7. 안전한 백업 유지

베리타스의 해결 방법

Putty Key gen 등록 방법

AWS Cloudwatch를 사용한 EC2 memory 확인 방법

Cisco switch interface counters errors

Linux 특정 파일 경로를 찾는 방법

Linux 특정 파일 경로를 찾는 방법 대해서 알아보자

1. find 명령어 (디렉토리 전체에서 파일 검색)

2. locate 명령어 (빠른 검색)

3. which 명령어 (실행 파일 위치 찾기)

4. whereis 명령어 (실행 파일 + 관련 파일 검색)

5. type 명령어 (명령어의 실제 경로 확인)

6. grep을 활용한 검색 (ls, ps 조합)

7. 전체 시스템에서 grep을 활용한 검색 (find + grep)

8. fd (고성능 파일 검색 도구)

9. du 명령어를 사용한 특정 파일 검색 (디스크 사용량 확인)

정리

원격관리툴 mRemoteNG - SSH Key 접속 이슈 해결 방법

Cisco Router, Switch Debug

Windows RDP Port 변경

Cisco Switch interface error 설명

Cisco Switch interface error에 대해서 알아보자

Port / Align-Err / FCS-Err / Xmit-Err / Rcv-Err / UnderSize / OutDiscards Te3/4 0 0 0 944 0 0 Port / Single-Col / Multi-Col / Late-Col / Excess-Col / Carri-Sen / RuntsTe3/4 0 0 0 0 0 0 0 ​ 에러의 종류와 원인

Port / Align-Err / FCS-Err / Xmit-Err / Rcv-Err / UnderSize / OutDiscards

Te3/4 0 0 0 944 0 0

Port / Single-Col / Multi-Col / Late-Col / Excess-Col / Carri-Sen / Runts

Te3/4 0 0 0 0 0 0 0

에러의 종류와 원인