아직 로그인하지 않았습니다. 로그인 또는 회원 등록을 해 주시기 바랍니다.
태터를 쓴지 이제 2년이 좀 넘었는데
백업 한번 받으려면 장난이 아닙니다.
사진을 많이 올려서 백업 받으면 파일 크기가 1Gb가 넘어요.
카테고리별 백업기능이나 분할 백업(?) 이런 기능이 있었으면 좋겠네요.
나중에 블로그를 티스토리 같은 곳으로 분할 이전 한다거나
장기적으로 백업 파일이 점점 커지는 사용자들이 많아질테니까 말이죠@@
아, 그리고 이미지관리 기능과 더불어 비슷하게 음악파일관리도 가능했으면 좋겠어요.
관리자 화면에서 사용할 수 있는 파일마다 붙여지는 '내부 태그(?)'같은 걸 이용하면 어떨런지요.^^;;
태터를 쓴지 이제 2년이 좀 넘었는데
백업 한번 받으려면 장난이 아닙니다.
사진을 많이 올려서 백업 받으면 파일 크기가 1Gb가 넘어요.
카테고리별 백업기능이나 분할 백업(?) 이런 기능이 있었으면 좋겠네요.
나중에 블로그를 티스토리 같은 곳으로 분할 이전 한다거나
장기적으로 백업 파일이 점점 커지는 사용자들이 많아질테니까 말이죠@@
작년에 저도 같은 내용을 건의했었습니다.
1.1버전에서 구현한다고 했다가 연기한 것 같네요. 쉽지 않은 문제가 끼어있어서 그런것 같아요. ^^;
love 작성:태터를 쓴지 이제 2년이 좀 넘었는데
백업 한번 받으려면 장난이 아닙니다.
사진을 많이 올려서 백업 받으면 파일 크기가 1Gb가 넘어요.
카테고리별 백업기능이나 분할 백업(?) 이런 기능이 있었으면 좋겠네요.
나중에 블로그를 티스토리 같은 곳으로 분할 이전 한다거나
장기적으로 백업 파일이 점점 커지는 사용자들이 많아질테니까 말이죠@@작년에 저도 같은 내용을 건의했었습니다.
1.1버전에서 구현한다고 했다가 연기한 것 같네요. 쉽지 않은 문제가 끼어있어서 그런것 같아요. ^^;
죄송합니다. 본의 아니게 양치기가 되었군요.ㅡㅡ 이 참에 이 글타래에 데이터베이스 관리에서 추가/보완 되었으면 하는 기능에 대해 적어보도록 할까요?
PS. 매달면서 글타래 제목을 조금 수정했습니다. love님께 양해 말씀 드립니다.
love 작성:태터를 쓴지 이제 2년이 좀 넘었는데
백업 한번 받으려면 장난이 아닙니다.
사진을 많이 올려서 백업 받으면 파일 크기가 1Gb가 넘어요.
카테고리별 백업기능이나 분할 백업(?) 이런 기능이 있었으면 좋겠네요.
나중에 블로그를 티스토리 같은 곳으로 분할 이전 한다거나
장기적으로 백업 파일이 점점 커지는 사용자들이 많아질테니까 말이죠@@작년에 저도 같은 내용을 건의했었습니다.
1.1버전에서 구현한다고 했다가 연기한 것 같네요. 쉽지 않은 문제가 끼어있어서 그런것 같아요. ^^;
역시 이미 제안한 분이 계셨었군요!!^^
기간 단위로 백업하기, 카테고리 단위로 백업하기, 원하는 글만 골라서 백업하기, 용량 단위로 잘라서 백업하기, 첨부파일'만' 백업하기
그리고 첨부파일 관리탭을 두고 음악파일, 이미지파일 같은 분류부터 재활용까지...
뭐 기능 추가하기로 말하면 제법 많죠 = ㅂ=a; 개인적인 판단으로 기술적인 어려움보다는 "과연 이게 사용자에게 얼마나 유용하게 쓰일 것 인가", "이게 과연 블로깅에 도움이 되는 기능인가" 같이 기능 구현에 들이는 시간과 노력대비 실효성에 대한 확신이 서질 않습니다. 기존 UI 에 변경을 가해야 하는 부분도 생길수 있으니, 괜히 복잡성을 늘리기만 해서는 난감하죠;
어떻게 정리해야 깔끔하게 데이터 관리 기능을 강화할 수 있으려나요 ' ㅂ'
토론해 봅~시다[]
laziel (2007-01-07 15:03:33)에 의해 마지막으로 수정
먼저 태터툴즈가 유수의 서비스 블로그들에 대항해서 데이터 '백업'이라는 것을 제공하는 이유는 TNF의 설립 목적에서도 드러나듯 개인 창작물의 소유권을 존중하고 자유를 보장하기 위함이라는 데에는 굳이 더 말할 필요가 없을 것 같습니다. 따라서 태터툴즈에서 '이것'을 강조하는 만큼 데이터 백업이 구체화 되고 상세화 되는 것은 어찌보면 당연한 일이라는 생각이 드네요. 그만큼 자유도가 증가할테니까 말이죠.
간단히 생각하면 위에서 Laziel님께서 말씀하신 것 처럼
기간 단위로 백업하기, 카테고리 단위로 백업하기, 원하는 글만 골라서 백업하기, 용량 단위로 잘라서 백업하기, 첨부파일'만' 백업하기
그리고 첨부파일 관리탭을 두고 음악파일, 이미지파일 같은 분류부터 재활용까지...
다양한 방법이 있을 수 있고 또 다양한 형태로 제공될 수 있을 것입니다. 이러한 다양성은 사용자들로 하여금 또다른 자유성과 민주성을 가지게 할 것입니다. 다만 Laziel님께서 말씀하신 것 처럼 '과연 이것이 얼마나 효과성이 있을 것인가'하는 문제가 제기될 수 있겠네요. 많은 시간과 노력을 투자해서 개발했는데 막상 사용자들의 활용도가 떨어진다면 그것만큼 비효율적인 것도 없을텐데요.
제 개인적인 생각으로는 위의 모든 기능들을 비롯하여 미처 생각하지 못한 다양한 방법들도 결과적으로 추가 되는 것이 좋다고 생각합니다. 그렇지만 큰 노력을 들여서 구현했는데 활용도가 떨어지면 안되기 때문에 우선적으로 데이터 백업의 큰 프레임을 짜는 것이 좋을 것 같네요. 어떤 방식으로 데이터 백업을 구현할 것인지.(사실 전 기술적인 것은 잘 몰라서^^; ) 여러 기능들을 어떠한 방식으로 통합적으로 제공할 것인지 등에 대해서 말이죠.
그리고는 '가장 우선적으로 필요하다고 생각되는 것' 부터 구현해 나가는 것이 좋을 것 같습니다. 예를 들면 '원하는 글만 백업하기'라든가 '첨부파일의 종류 골라서 백업하기' 등 큰 맥을 이루고 있는 것들 말이죠. 일정 기간 단위라면 그것은 곧 원하는 글만 백업한다는 의미가 포함되어 있고 또 일정 기간 중에서도 첨부파일을 어떻게 할지에 대한 문제도 있기 때문이죠.
아, 그리고 이런 경우는 극히 드물겠지만 만약 원하는 글만 dump하고 import할 수 있다면 이전에 운영 했던 블로그의 글과 지금 완전 별개로 운영하고 있는 블로그 간에도 데이터를 주고 받을 수 있을까요?ㅋ
이상 횡설수설해보았습니다-_ㅡ;
엔하늘 (2007-01-07 19:15:48)에 의해 마지막으로 수정
기간 단위로 백업하기, 카테고리 단위로 백업하기, 원하는 글만 골라서 백업하기, 용량 단위로 잘라서 백업하기, 첨부파일'만' 백업하기
그리고 첨부파일 관리탭을 두고 음악파일, 이미지파일 같은 분류부터 재활용까지...뭐 기능 추가하기로 말하면 제법 많죠 = ㅂ=a; 개인적인 판단으로 기술적인 어려움보다는 "과연 이게 사용자에게 얼마나 유용하게 쓰일 것 인가", "이게 과연 블로깅에 도움이 되는 기능인가" 같이 기능 구현에 들이는 시간과 노력대비 실효성에 대한 확신이 서질 않습니다. 기존 UI 에 변경을 가해야 하는 부분도 생길수 있으니, 괜히 복잡성을 늘리기만 해서는 난감하죠;
어떻게 정리해야 깔끔하게 데이터 관리 기능을 강화할 수 있으려나요 ' ㅂ'
토론해 봅~시다[]
태터툴 사용기간이 늘어나다보면 분명 필요하게 되지 않을까합니다. 특히 '기간 단위로 백업하기, 카테고리 단위로 백업하기'이거 둘은^^
용량단위는 사용자가 기간을 잘 나눠서 요령껏하면^^;;;
용량단위는 사용자가 기간을 잘 나눠서 요령껏하면^^;;;
사실 용량단위로 끊어서 백업파일 만들기 콤포넌트가 이미 만들어져 있거든요 (쿨럭)
기간, 카테고리도 뭐 지금 있는거 쿼리에다 조건 하나만 추가해주면 되는 일이고..
코드상으로는 순식간에 할 수 있는 일이지만 역시 문제는 UI 지요 = _=a; 깔끔하고 쉽게!!
love 작성:용량단위는 사용자가 기간을 잘 나눠서 요령껏하면^^;;;
사실 용량단위로 끊어서 백업파일 만들기 콤포넌트가 이미 만들어져 있거든요 (쿨럭)
기간, 카테고리도 뭐 지금 있는거 쿼리에다 조건 하나만 추가해주면 되는 일이고..
코드상으로는 순식간에 할 수 있는 일이지만 역시 문제는 UI 지요 = _=a; 깔끔하고 쉽게!!
그렇죠...
해 놓은 것은 많은데 문제는 UI =_=
아무래도 여러 가지 조건들이 포함된다면 '마법사'의 형태를 띄어야 하지 않나 생각해 봅니다.
전체적인 흐름은 아래와 같이 될 수 있겠네요.
|- 전체 백업 -------------------------- 첨부파일의 조건 ---- dump
|
|- 부분 백업 -------- 부분의 조건 ↗
더불어 이러한 백업이 지원된다면 곧 복원 할 때도 파일을 읽은 후 원하는 글만 뽑아서 넣을 수도 있어야겠네요 @.@;
전체적으로 카테고리 백업이랑 용량별 백업이랑 글별 백업이 필요할 것 같습니다.
카테고리별 백업 기능도 운영을 몇 년이상 하다보면 결국은 용량부족에 걸리지 않을까 생각합니다. 그래서 일단 카테고리별로 백업할 수 있게 만들고, 그 카테고리별 백업을 하는 도중에 용량을 보고 나누는 방식을 사용하면 좋을 것 같습니다. ^^
그리고 글별로 백업하는 것도 필요할 것 같구요.(모든 글들을 하나하나 나눠서 자동으로 백업하는 기능구현은 힘들까요?)
특히 Tistory의 경우는 업로드 용량에 제한이 걸리니까 그 미만 용량으로 백업을 해주는 기능이 필요할 것 같습니다. (Tistory에서 100MB까지 업로드할 수 있도록 했으면 좋겠네요. 현재는 10MB였던가요? 너무 작아요.....?!
제 Tistory를 백업해보면 700MB가 나오는데..^^; )
작은인장 (2007-01-12 16:32:32)에 의해 마지막으로 수정
티스토리는 용량 무제한이고 동영상이 가능하니 막올리니게 되더군요. 제 티스토리 블로그는 2Gb에 육박하지 않을런지..덜덜...
얼마 전에 다른 글에서 잠깐 언급했었는데요....
백업파일 복구할 때 백업한 사이트와 복구하는 사이트가 다르면 백업한 사이트의 첨부화일들을 복구한 사이트로 자동이전시키는 기능이 필요할 것 같습니다.
현재는 백업할 때 첨부파일까지 몽땅 백업해서 새로운 곳에 복구하는데.... 그 용량이 다들 아시겠지만 장난이 아니거든요. (1~2GB가 넘어가기가 쉽죠.) 하지만 백업파일을 복구하는 것은 Tistory의 경우 1GB까지밖에 되지 않으니까... 많이 불편합니다. 특히 오류라도 뜨면 업로드를 수도없이 반복해야 한다는 것인데, 엄청난 크기의 파일을 업로드 하는 것도 쉽지가 않습니다.
그래서 첨부파일 없이 백업한 뒤에 복구할 때 첨부파일을 그냥 가져오는 식으로 만들면 좀 더 편한 방법이 되지 않을까 생각합니다.
음.............................
그리고 백업방식에 있어서도 첨부파일 따로, 백업파일 따로 pc에 백업받은 뒤에 pc에서 직접 업로드할 수 있는 방식이 있었으면 좋겠구요.
결국 제 생각엔 이렇게 ......
1. 백업 영역 지정
ⓐ 전체 백업 ⓑ 카테고리별 백업 ⓒ 용량별 분활 백업 ⓓ 시간별 백업 ⓔ 글별 백업
2. 첨부파일 백업 지정
ⓐ 첨부파일 미포함하여 백업 ⓑ 첨부파일 포함하여 백업 ⓒ 첨부파일을 pc로 따로 백업
3. 복원방법
ⓐ 백업파일만 복원 ⓑ 첨부파일을 pc에서 불러들여 복원 ⓒ 첨부파일을 기존사이트에서 불러들여 복원
4. 복원 옵션
ⓐ 기존 정보를 삭제하고 복원 ⓑ 기존 정보에 추가하여 복원
뭐 이런 방식으로.....
ohmynews의 블로그를 백업해서 tistory에 올리는 작업을 하다보니 백업방식의 편리성이 중요해지는군요. ㅜㅜ
작은인장 (2007-03-26 14:20:54)에 의해 마지막으로 수정
전 vBulletin라는 포럼을 쓰고 있는데 첨부파일을 DB에 저장하거나 아님 파일로 저장하는 옵션이 있습니다.
디비 백업 할때는 첨부파일을 파일로 저장 옵션으로 사용한다음 첨부파일만 따로 저장하고 데이터는 DB로 받고 있습니다.
TiStory에서는 ftp가 안되니... 파일로된 첨부파일 압축해서 내려 받고... 데이터만 DB로 다운 받을 수 있게 했으면 좋을것 같은데요.
첨부파일만 빼면 대부분 DB는 20M 안쪽일 것 같은데....
TiStory에서는 ftp가 안되니... 파일로된 첨부파일 압축해서 내려 받고... 데이터만 DB로 다운 받을 수 있게 했으면 좋을것 같은데요.
첨부파일만 빼면 대부분 DB는 20M 안쪽일 것 같은데....
첨부파일만 압축해서 내려받을 수 있는 기능이 있으면 정말 좋겠어요. ^^
첨부파일을 뺀 DB도 용량이 20 MB는 넘더라구요. ^^;
저도 카테고리 백업같은거 참 필요하더라구요.. 얼마전에 블로그를 취미용과 일반용;;으로 나눴는데, 일일히 수작업으로 취미 카테고리를 옮겼습니다.... 크악!!ㅠㅠ
예 이제 본격적으로 이 부분을 논의해 볼 때가 되었군요.^^
전부터 생각하고 있었던 'TTXML 관리자' 프로그램을 따로 하나 만들어보는 것도 괜찮을 것 같네요.
일반 어플리케이션 형태로 만들고 싶긴 한데 cross-platform을 하자니 만만치는 않을 듯하고... 일단 윈도 사용자가 많으니 .NET으로 짜볼까요..
아니면 wxPython 같은 걸로 할까....
(하지만 이런 프로그램이 실현되려면 텍스트큐브 자체에도 이 프로그램과의 통신을 위하 인터페이스가 있어야겠습니다..)
전 가장 필요한 것이 스케쥴링 백업 기능이라고 생각합니다.
얼마 전 날아가서 복구하는데 한참 애를 먹었습니다.
아래의 싸이트를 운영하고 있는데, 순수 DB 데이만 해도 60mb가 넘습니다. 파일을 제외하구요. 그래서 새벽에 정기적으로 서버에 백업을 했으면 합니다. http://www.trav.co.kr
1. 백업주기
optional : 매일 | 1주일 | 1개월
2. 시간설정: 24시간 (전 주로 새벽 3시쯤에 했으면 합니다.)
3. 백업데이트 압축: 활성 / 비활성
4. 백업방식: xml, sql
물론 cron을 걸어서 할 수도 있는데, 초보자가 가능이야 하겠습니까?
이런건 어떨까요
외국 무료호스팅을 이용하여 (물론 텍큐가 깔려야 한다는 전제 입니다.)블로그 미러링을 하는겁니다.
클론 API를 미러블로그 메인블로그 두군데에 깔아둡니다.
그리고 설정에 따라 다르겠지만 글만 미러링 할건지 첨부파일도 미러링 할건지 결정합니다.
설정을 마치고 그냥 평소대로 사용(미러링 하는 블로그가 정상인지 수시로 확인-이거도 메인화면에 플러그인으로 만들수 있겠네요...-)하다, 문제가 생겨 자료를 잃게 되면 미러링된 블로그는 살아 남고 추후 복구시 편하게 플러그인을 이용 미러링 복구를 지정하면 OK가 되지 않을까요?(일종의 데스크탑 싱크와 비슷합니다..) 뭐 조건이 까다 롭기도 하겠지만 이 정도면 일일이 DB를 통째로 백업하고 복구하는데 시간을 들일 필요가 없을테니까요...
추가로 플러그인을 활용하자면 과도한 트래픽이 발생하여 얼마 않가서 트래픽 오버가 되겠다 하면 자연스래 미러링 블로그로 링크유도도 괞찮은 방법이 될거같습니다...
한가지 문제라면...
바이너리 스크립트가 아닌 단순 API이기 때문에 메인블로그와 미러블로그 그사의의 블로거컴퓨터 사이의 속도 문제 평소 사용시 문제와 전체백업과 전체복구가 문제 될지도 모르겠군요....
위 문제만 아니라면 평소 쓰는데 수시로 백업하고 하는 수고가 없이 자동으로 미러 블로그가 완성된다는 점에서 좋은 기능이 될거도 같습니다...
skylark (2008-11-17 10:30:10)에 의해 마지막으로 수정
백업파일을 자르는 유틸리티를 만들거나 기간별로 백업하는 기능을 만들거나.....
이게 급하지 않나요???
특히 이번에 textcube.com으로 이전을 유도하는 이벤트를 하고 있는 상황인데, 덩치 큰 블로그를 갖고 있는 블로거들은 이전 자체가 불가능합니다. 그렇다고 이전 블로그 버리고 이사하는 건 무리가 심하고.... -_- (구글 쪽으로 건의해야 하려나?)
이런 내용이 처음 올라오기 시작한 것이 2006~2007년 사이인데, 당시에는 급하지 않은 문제였다고 생각할 수도 있지만, 이제는 블로그 운영이 3~4년 넘는 분들이 부지기수로 증가하고 있으므로 이 일이 촉박한 일이 되는 것 같습니다.
안 그런가요?
kkom (2009-05-10 07:22:20)에 의해 마지막으로 수정
니들웍스