Alphavps 장애 기록

1. 2026년 7월 30일 오후 12:50 UTCidentified

   우리는 다음과 같은 노드에 대한 preemptive 하드웨어 유지 보수를 시작했다 : 다운로드 다운로드 다운로드 영향을받는 노드에서 호스팅되는 VPS 인스턴스는 임시 중단을 경험할 수 있습니다. 예상 가동 시간은 VPS 당 약 15 ~ 30 분입니다. 우리의 팀은 정비를 밀접하게 감시하고 일 진도로 더 새롭게 제공할 것입니다.

2. 2026년 7월 30일 오후 1:13 UTCidentified

   우리는 SOFSTORAGE07에 처음 일하고 있습니다. VMs는 우아한 폐쇄이고 곧 부팅될 것입니다.

3. 2026년 7월 30일 오후 1:25 UTCidentified

   우리는 SOFSTORAGE07와 가상 머신에서 작업을 완료했습니다. SOFSTORAGE01, 가상 머신은 폐쇄 및 유지 보수가 시작됩니다.

4. 2026년 7월 30일 오후 2:00 UTCidentified

   우리는 SOFSTORAGE01 및 가상 머신에서 작업을 완료했습니다. SOFSTORAGE06, 가상 머신은 폐쇄 및 유지 보수가 시작됩니다.

5. 2026년 7월 31일 오전 10:55 UTCidentified

   SOFSTORAGE06 유지 보수가 수행되고 모든 VM은 부팅됩니다.

6. 2026년 8월 21일 오전 11:11 UTCresolved

   이 사건은 해결되었습니다.

공식 인시던트 업데이트를 자동 번역했습니다.

1. 2026년 6월 29일 오후 6:42 UTCidentified

   우리는 현재 우리의 네트워크 인프라의 일부를 대상으로 대규모 DDoS 공격을 경험하고 있습니다. 이 공격은 간헐적인 연결 문제와 약간 고객을 위한 증가한 지연을 일으키는 원인이 됩니다. 우리의 네트워크 엔지니어링 팀은 이 공격을 완전히 해결하기 위해 추가 영구적 인 완화 조치를 배포하고 인프라의 탄력을 강화하는 데 적극적으로 노력하고 있습니다. 임시 완화는 이미 장소에 있으며 공격이 진화함에 따라 방어를 모니터링하고 적응시키기 위해 계속합니다. 우리는 진심으로 모든 혼란에 대해 사과합니다. 이것은 우리가 완전하고 영구적 인 해결책을 향해 일하면서 당신의 인내력을 일으킬 수 있습니다. 더 많은 업데이트는 진행 중입니다.

2. 2026년 6월 29일 오후 7:39 UTCidentified

   이 문제를 해결하기 위해 계속 노력하고 있습니다.

3. 2026년 6월 29일 오후 8:01 UTCidentified

   Nuremberg에 대한 소송을 적용했습니다. 소피아는 짧게 적용되어야한다. 우리는 extortion/ransom DDoS 공격을 처리하고 있으므로, 우리는 더 많은 정보를 공개적으로 공유 할 수 없습니다.

4. 2026년 6월 29일 오후 9:22 UTCidentified

   악의적 인 공격자는 지속적으로 공격 패턴을 변경하는 동안, 우리는 완화를 적용하고 우리의 고객의 대다수는 온라인으로 돌아갑니다. 우리는 상황의 지역 법 집행뿐만 아니라. 자주 묻는 질문.

5. 2026년 6월 30일 오전 12:52 UTCmonitoring

   우리는 우리의 위치 및 교통의 모든 맞은편에 대한 완화를 구현했습니다. ICMP에 차이가 있을 수 있지만, 문제가 해결되는 것을 신뢰합니다.

6. 2026년 6월 30일 오전 7:30 UTCmonitoring

   우리는 상황을 모니터링하고 완화 조정을 적용합니다. 모든 위치의 모든 서비스는 온라인이며 현재 안정된 것으로 간주됩니다.

7. 2026년 6월 30일 오전 7:36 UTCmonitoring

   우리는 더 많은 문제를 모니터링하고 있습니다.

8. 2026년 6월 30일 오후 4:38 UTCmonitoring

   우리는 최소한의 중단을 가진 완화 기구의 이음새가 없는 일을 지키는 위치의 맞은편에 상황과 튜닝 완화 단면도를 감시하고 있습니다.

9. 2026년 7월 9일 오전 3:44 UTCresolved

   이 사건은 해결되었습니다.

공식 인시던트 업데이트를 자동 번역했습니다.

1. 2026년 5월 27일 오후 12:56 UTCidentified

   우리는 우리의 뉴욕 위치에 긴급한 네트워크 정비를 시작했습니다 우리의 현재 공급자의 예상치 못한 출구 뒤에 새로운 상류 연결을 배치하기 위하여. 자세한 내용은 모든 영향을받는 가상 머신 클라이언트에게 이메일을 통해 보내집니다. 이 유지 보수 중 일부 고객은 네트워크 마이그레이션 활동이 수행되는 동안 간헐적인 연결 중단 또는 임시 중단 시간을 경험할 수 있습니다. 유지 보수 창은 8 시간까지 지속될 것으로 예상되지만 실제 중단이 크게 단축될 것이라고 믿는다. 우리는 진심으로 짧은 통지와 어떤 불편을 위해 사과합니다. 이 업그레이드는 뉴욕 서비스의 장기적 안정성과 품질을 개선하는 데 중요한 단계입니다. 더 많은 업데이트가 계속 진행될 예정입니다.

2. 2026년 5월 27일 오후 3:28 UTCmonitoring

   우리는 네트워크 업그레이드로 완료하고 1 시간 - 모든 네트워크는 안정적입니다. 우리는 우리가 케이스를 닫을 때까지 몇 시간 동안 감시를 계속할 것입니다.

3. 2026년 6월 30일 오전 12:51 UTCresolved

   이 사건은 해결되었습니다.

공식 인시던트 업데이트를 자동 번역했습니다.

1. 2026년 4월 7일 오전 9:31 UTCidentified

   중요한 RAID 어레이 실패는 오늘 dalstorage01에 발생했습니다. RAID 컨트롤러는 불안정한 상태를 입력하고 여러 KVM 디스크 이미지의 손상을 초래하는 지속적인 쓰기 작업을 입력했습니다. 노드는 더 많은 영향을 방지하기 위해 즉시 오프라인으로 촬영되었습니다. RAID 컨트롤러는 교체 및 복구 절차가 현재 진행 중입니다. 배열 크기 때문에, 회복은 시간 집중되고 자료 견실함은 보장될 수 없습니다. 이 시간에, Dallas에서 유효한 수용량은 제한됩니다. 추가 하드웨어를 배포하는 데 적극적으로 노력하고 있지만 정확한 ETA는 아직 확인되지 않았습니다. 고객에게는 대체 위치에 있는 보충 서비스로 제공됩니다. 구조 접근은 제일 노력 자료 회복을 위한 요구에 활성화될 수 있습니다. 더 많은 업데이트는 계속 진행될 것입니다. VPS가이에 영향을 미치는 경우, 당신은 이미 더 단계로 이메일을 보냈습니다. 이메일이 전송되지 않은 경우 - 즉시 티켓을 엽니 다.

2. 2026년 6월 30일 오전 12:52 UTCresolved

   이 사건은 해결되었습니다.

공식 인시던트 업데이트를 자동 번역했습니다.

1. 2025년 9월 22일 오후 10:05 UTCinvestigating

   We've been alerted of an issue with our sofstorage22 node. We've dispatched DC engineers to check the status of the server and attempt recovery.

2. 2025년 9월 24일 오후 5:35 UTCidentified

   We continue working on the sofstorage22 host node. Unfortunately, at the moment we're unable to restore the RAID array. We're continuing with data recovery and further updates will be posted within 24 hours.

3. 2026년 1월 29일 오후 8:02 UTCresolved

   This incident has been resolved.

1. 2025년 9월 4일 오전 5:13 UTCinvestigating

   We've been alerted of a problem with our nuestorage03 KVM storage Node. Upon checking, we've discovered the node is completely unreachable by IPMI. We've dispatched on-site techs to check the condition of the node. Further updates to follow.

2. 2025년 9월 4일 오전 5:26 UTCresolved

   This incident has been resolved.

1. 2025년 9월 3일 오전 5:09 UTCidentified

   We've been alerted by our system that our nueryzenkvm01 host node is currently down. As we're unable to open an IPMI connection, we have engaged Datacenter technicians on-site. Updates to follow.

2. 2025년 9월 3일 오전 5:27 UTCidentified

   We're currently experiencing a hardware failure and we'll be replacing some parts of the chassis with on-site spares. ETA of resolution: 2-3 hours.

3. 2025년 9월 3일 오전 7:33 UTCresolved

   This incident has been resolved.

1. 2025년 7월 5일 오전 8:58 UTCidentified

   On July 4th, 2025, we detected a catastrophic RAID10 SSD array failure on node nueovz04. Fortunately, this node was in the process of being decommissioned and actively migrated to new infrastructure, so the impact is limited to a small number of customers. Since discovery, we have attempted multiple recovery approaches, including replacing RAID controllers and utilizing advanced data recovery techniques. We are currently preparing an identical server chassis to import the array and attempt further recovery efforts. At this time, we cannot guarantee recovery success or provide a precise ETA, but we are targeting the first half of the upcoming week for the next update or resolution. We sincerely apologize for the inconvenience and thank you for your patience while we work through this. — The AlphaVPS Team

2. 2025년 7월 9일 오전 8:33 UTCresolved

   Status: Recovery Unsuccessful – Services Being Recreated Following extensive recovery efforts on node nueovz04, we regret to inform you that we have not been able to restore the RAID10 SSD array. Our team has attempted: - Replacing the RAID controller cache - Replacing the entire RAID controller with multiple known working controllers - Transplanting the drives into an identically configured chassis, with fully matching firmware and hardware Despite all recovery attempts, the RAID array remains inaccessible. At this stage, we must consider the data on this node to be lost. We are now moving forward with recreating affected services on a new node. Our team will be reaching out individually to each impacted customer to coordinate this process. If you were hosted on nueovz04 and have not received an email from us, we urge you to contact our support team as soon as possible. We deeply regret this outcome and sincerely apologize for the disruption. Thank you for your patience and understanding during this time. — The AlphaVPS Team

1. 2025년 6월 25일 오후 4:40 UTCidentified

   We've detected an issue with our sofovz06 node. We're working on resolving it. Please stand by for updates.

2. 2025년 6월 26일 오전 7:44 UTCresolved

   We've resolved the issue as of 14 hours ago. We've monitored the situation throughout the time and believe that system is now stable.

1. 2025년 5월 31일 오전 3:59 UTCidentified

   We've been informed of an urgent DataCenter maintenance in our NYC facility, affecting some of our services there. ETA of service restoration is 1-2 hours.

2. 2025년 5월 31일 오후 12:59 UTCresolved

   The incident is fully resolved.

1. 2024년 12월 20일 오전 7:49 UTCinvestigating

   We've been alerted of a catastrophic RAID failure on our nuestorage07 node. Earlier this morning, the controller started flapping, which jumped the I/O load to over 90. This made every VM on the host hypervisor unresponsive. We've proceeded with replacing the RAID adapter and we're moving towards an attempted recovery. At this point, we're unsure if recovery would be possible.

2. 2024년 12월 20일 오전 9:31 UTCidentified

   We're currently working on bringing the node back online in a stable state. We estimate that it would take us 3-4 additional hours before we start booting the virtual machines up and assessing the damage. Please stand by for further updates.

3. 2024년 12월 20일 오후 1:54 UTCidentified

   We are starting with restoration of individual KVM machines. Further updates to follow.

4. 2024년 12월 20일 오후 9:04 UTCidentified

   We're continuing to work on restoring VMs, if your VM is affected - please wait until it's booted up.

5. 2024년 12월 21일 오후 2:01 UTCmonitoring

   We'll be booting up the remaining virtual servers in the next 1 hour and continue with monitoring the hypervisor.

6. 2024년 12월 21일 오후 3:44 UTCmonitoring

   Unfortunately, as we booted up the majority of the affected VMs, the node started becoming unstable again with flush operations starting to get queued. We're looking into alternative solutions at the moment. Further updates to come.

7. 2024년 12월 21일 오후 11:35 UTCmonitoring

   We've proceeded with replacing additional hardware. After we've performed manual fsck on each virtual machine's virtual drive - we've proceeded with booting up all affected VPS. As of now, all services are restored. We'll be monitoring the situation throughout the next days.

8. 2025년 1월 1일 오후 12:08 UTCresolved

   We've monitored the situation for the past 11 days and as of now, everything is stable and we're closing the issue.

1. 2024년 9월 27일 오후 12:04 UTCidentified

   We've identified an issue with our Nuremberg network. We're working on resolving it.

2. 2024년 9월 27일 오후 12:10 UTCmonitoring

   A fix has been implemented. The issue was related to a reboot of a virtual chassis member, causing multiple BGP sessions to start flapping. We're monitoring the environment and we'll apply further fixes as necesary.

3. 2024년 9월 28일 오후 3:38 UTCresolved

   We've been monitoring the situation and a fix has been implemented for this specific edge case. We're closing this as resolved.

1. 2024년 9월 9일 오후 4:47 UTCinvestigating

   Our monitoring has alerted us that our laxryzenkvm07 node is currently offline. During our investigation, we've found out that we're unable to reach IPMI/BMC as well. We're dispatching on-site technicians to check the status of the server. Further updates to follow!

2. 2024년 9월 9일 오후 5:15 UTCresolved

   Services are back online now.

1. 2024년 5월 18일 오전 10:00 UTCidentified

   Our engineers have identified an upstream-related problem, causing packet loss from certain routes towards our London infrastructure. The issue was identified to be upstream-caused. We're awaiting our London connectivity partners to further update us with an estimation of time for service restoration.

2. 2024년 5월 18일 오전 10:10 UTCmonitoring

   The issue seems to be currently resolved but we're awaiting updates from our upstream. We will keep monitoring throughout the day.

3. 2024년 5월 18일 오후 1:40 UTCmonitoring

   Our London connectivity partners state that the issue has been identified and resolved. We will continue to monitor the network throughout the day.

4. 2024년 5월 18일 오후 5:44 UTCresolved

   As per now - we consider this to be resolved.

1. 2023년 12월 12일 오전 9:12 UTCidentified

   We've identified a hardware issue with our nueovz04 node and we've immediately taken it offline, pending remote hands in DC to swap some hardware components.

2. 2023년 12월 12일 오전 10:06 UTCmonitoring

   The node is back online and we'll be monitoring it for stability and further issues.

3. 2024년 4월 3일 오전 8:57 UTCresolved

   This incident has been resolved.

1. 2023년 11월 10일 오전 6:09 UTCidentified

   Hello, We've identified an issue in our Sofia location, affecting our network. We've isolated it to our QFX Virtual Chassis Core. We've restored back connectivity on a single member of our Virtual Chassis and no redundancy is present at the moment. We're working on bringing the rest of our VC members online to restore redundancy.

2. 2023년 11월 10일 오전 9:04 UTCidentified

   We've identified the main problem, which was related to one of the members of our Juniper QFX Virtual Chassis. At the moment, we believe that one of the virtual chassis members suffered a catastrophic failure of internal storage. Unfortunately, this specific Juniper QFX device was the active master in our VC configuration. As per best practices, we run multiple devices, which can take over the mastership when the current master fails, however in this case - this has not happened, as JunOS was partially running on the failing device. The master killed the internal routing sessions and no packets were being transmitted via the secondary devices. Once we determined the root cause, we've done a manual switchover to another VC member and connectivity was restored. We're working on replacing the failing device and bringing it back in our VC to restore redundancy. Service redundancy should still be considered to be at risk. IPv6 connectivity is not restored on 100% yet, as our priority is bringing v4 redundancy back in place. Further updates to follow.

3. 2023년 11월 10일 오전 9:39 UTCidentified

   As of now, IPv6 connectivity is also restored. We're proceeding with replacing the virtual chassis member.

4. 2023년 11월 10일 오후 12:34 UTCmonitoring

   We've installed a new QFX member, after initial configuration and restored full redundancy. As of now, all systems are back to being fully redundant again. We'll continue monitoring the infrastructure and close this issue later today.

5. 2023년 11월 10일 오후 6:19 UTCresolved

   We're closing this incident as resolved.

1. 2023년 5월 22일 오전 7:58 UTCidentified

   As per our previous email - we're beginning the pre-scheduled migration of nuestorage* nodes.

2. 2023년 5월 22일 오전 8:08 UTCidentified

   We're taking down nuestorage01 node down.

3. 2023년 5월 22일 오전 8:23 UTCidentified

   Nuestorage01 is ready and booting up, nuestorage02 is currently being shutdown.

4. 2023년 5월 22일 오전 8:47 UTCidentified

   We've shutdown nuestorage03. As of the moment - nuestorage02 shows further hardware problems and we'll shut it down again to further debug.

5. 2023년 5월 22일 오전 9:05 UTCidentified

   We've completed the maintenance on nuestorage03 and we've taken back nuestorage02 for further checks. As of now - both nuestorage01 and nuestorage03 can be considered stable.

6. 2023년 5월 22일 오전 9:23 UTCresolved

   nuestorage02 node is back up and running. As of now - all nodes are back online and all instability issues should be permanently resolved! We're closing this as resolved.

1. 2023년 5월 15일 오전 8:38 UTCinvestigating

   Our monitoring has detected network connectivity issues and packetloss in our LAX location. This seems to be related to our upstream and is out of our scope. We're currently awaiting their network engineers to sort out the problem.

2. 2023년 5월 15일 오전 11:22 UTCmonitoring

   A fix has been implemented and we are monitoring the results.

3. 2023년 5월 15일 오후 12:42 UTCresolved

   The incident has been resolved and the main cause was a significant peering disturbance in the LA ANY2 peering platform.

1. 2023년 1월 25일 오후 12:47 UTCinvestigating

   We've started the pre-scheduled network maintenance in Sofia. Minor and short service disruptions might occur.

2. 2023년 1월 25일 오후 3:54 UTCresolved

   We've completed the maintenance without any disruption to client services and are closing the maintenance window.

1. 2023년 1월 2일 오후 3:03 UTCinvestigating

   We're investigating a complete network outage in London, related to our upstream. Further news to follow.

2. 2023년 1월 2일 오후 4:16 UTCidentified

   As of now, we've restored connectivity to the majority of our clients in London. A small portion of clients residing on a specific network segment are still affected. We're dealing with a large-scale network attack and working closely with our upstreams on completely mitigating the attack.

3. 2023년 1월 2일 오후 5:00 UTCresolved

   Our upstream applied some additional mitigation rules on the Corero device and as of now - all clients are back online.