소스코드야 로컬, 클라우드, 프라이빗 저장소에 저장해놓으니별 문제는 없을텐데, 데이터베이스가 문제네요.
나야나같은 경우는 이중 백업까지 모두 감염 되었다고 하니 걱정이 좀 되네요.
DB같은 경우는 로컬에 1차 백업, 2차는 xtrabackup으로 ssh를 통해 외부에 백업을 하고 있습니다.
가만 생각해보면 저같은 경우도 하나의 서버만 털리면 연결된 모든 서버(외부백업 서버)가 털릴수 있을 것같네요. 결국 온라인에 있는건 위험성이 존재하는것 같네요.
주기적으로 백업 데이터를 로컬로 내려 받든지 해야할텐데, 이것도 일이네요.
많이들 깜빡하는 부분이 한 가지 있는데요...
웹/DB서버에서 백업서버로 데이터를 전송하기 위해 백업서버 로그인 정보(FTP 아이디/비번, SSH 개인키 등)를 실서버에 저장해 놓는 분들이 많습니다. 그래야 사람이 개입하지 않아도 정해진 시간에 자동으로 백업이 실행될 테니까요. 그러나 이렇게 해놓으면 실서버가 해킹당했을 때 백업서버 로그인 정보까지 털리는 수가 있습니다.
원격 백업은 반드시 백업서버 쪽에서 실서버에 접속하여 데이터를 다운받는 방식으로 설계해야 합니다. 실서버에서 백업서버에 업로드해서는 안됩니다. NFS, SMB 등으로 항상 연결되어 있으면 더더욱 안됩니다. 안 그러면 나야나처럼 실서버가 털렸을 때 백업서버까지 모두 털려버리는 대형참사가 발생합니다 ㅜㅜ
이런 문제 때문에 아마존 S3, 드롭박스 등 저장 공간만 제공하고 서버 쪽에서 백업 실행이 불가능한 서비스는 1차 백업 용도로 적합하지 않다고 생각합니다. 백업서버 접속 정보를 실서버에 저장할 수밖에 없게 되니까요. 만약 이런 서비스를 사용하신다면 일단 백업서버로 데이터를 가져온 후 다시 압축해서 업로드하는 2차 백업 용도로만 쓰세요.
제대로 된 백업서버가 있다면 로컬에 다운받는 것은 그다지 중요하지 않습니다. 윈도우를 사용하고 수시로 이런저런 사이트에 접속하여 이런저런 파일을 다운받는 로컬 PC보다는, 리눅스를 사용하고 최소한의 백업 유틸리티만 돌아가는 백업 전용 서버가 훨씬 안전합니다.
모든 데이터베이스는 백업 유틸리티를 제공하니 제대로 사용하시기만 하면 문제는 없습니다. 복원시 호환성이 가장 높은 mysqldump 명령도 InnoDB 환경에서는 --opt --single-transaction 옵션으로 쓰시면 락 걸리지도 않고 딱 좋습니다. 현재 사용하고 있는 데이터 파일을 직접 복사하는 만행을 저지르시지만 않으면 됩니다 ㅋㅋㅋ
수동으로 스크립트 짜서 시스템화 한다면 rsync 같은것으로 백업할 내용을 모아놓고 폴더를 압축하여 쉘스크립트 같은것으로 외부 서버에 ftp 업로드를 합니다.
업로드 하는 서버는 raid 1 이상으로 구축하여 안정성을 더하면 결국 3중 백업 같은 효과가 나옵니다.
이 작업을 매일 새벽에 하도록 cron 을 돌립니다.