# restore

tett_77

Postgresql에서 DB 복원 가정 PostgreSQL에 DB가 생성되어 있다. DB 백업 파일을 가지고 있다. (dump, sql, ...) 방법 1) pgadmin4 접속 2) DB > Restore 옮기고자 하는 DB에 오른쪽 마우스 버튼 클릭 > restore 클릭 파일 주소 및 원하는 옵션 설정 > restore 버튼 우측 하단에 아래와 같은 알람이 뜨면 성공 ![](https://velog.velcdn.com/images/tett_77/post/98ddd1ff-d938-45bf-

dlzlqlzl

변경 사항을 다시 원래대로 되돌리고 싶거나, 아직 add 하면 안 되는 파일을 add 해버려서 난감했던 경험이 있었기에 이러한 명령어들을 다시 한번 되짚어볼 겸 정리해보려 합니다. git restore 특정 파일을 지정하는 상태로 복구시키는 명령어 파일을 수정하기 이전으로 되돌리기 (Working Directory에 있을 경우) 지정한 파일의 변경사항이 복구됩니다. 파일명 자리에 . 을 적어 모든 파일을 복구할 수 있습니다. 변경사항을 add 이전으로 되돌리기 Staging Area에 저장되어있던 변경사항이 Working Directory로 이동합니다. **파일을

yeonwoo1125

야밤에 일한다고 까불다가 회사 브런치 삭제하고 식겁하며 다시 복구했다는 슬픈 이야기.. 브런치 삭제하는 법 위의 사진처럼 bitbucket - project - branches - 삭제할 브런치 로 이동하면 branch를 삭제할 수 있다. 브런치 복구하는 법 먼저 remote상에 브런치가 있는지 확인하기 위해 아래의 명령어를 입력한다. 입력 후 삭제한 브런치가 아직 남아있다면 되돌릴 수 있다. 그 다음 아래의 명령어를 수행해 삭제한 브런치로 checkout한다. 그럼 브런

alsry922

✔️이전 커밋으로 돌아가기 📌커밋 해시를 사용하여 돌아가기 git checkout으로 이전 커밋으로 돌아갈 수 있습니다. git log 를 실행하여 커밋 이력들을 확인할 수 있고 또한 커밋 해시까지 확인할 수 있습니다. 커밋해시는 앞의 7자리만 복사해서 사용할 수도 있습니다. git log --oneline 으로 짧게 커밋 이력 확인도 가능합니다. 📌HEAD를 기준으로 한 커밋 참조를 통해 돌아가기 이렇게 HEAD와 물결표, 숫자를 이용하여 HEAD의 이전 커밋, 두 번째 이전 커밋, 세 번째 이전 커밋... 등 HEAD를 기준으로 커밋을 참조하여 이동할 수 있습니다. 이렇게 이전 커밋으로 돌아가면 detached HEAD 상태라는 경고 문구?

cocoboeun

Win7에서 시작 > 보조 프로그램 > Windows PowerShell ISE(x86)가서 첫 번째 스크립트 입력창에 $mBox = New-Object-comobject wscript.shell $ret = $mBOx.popup("팝업창 연습", 0, "팝업", 1)해서 popup()함수를 이용해서 ret 변수를 생성한다. PowerShell을 이용해서 VisualBasic과 같은 다양한 작업을 수행시킬 수 있다. LVM/RAID 실습 Linux에서 처럼 LVM(여러 HDD를 묶어서 용량을 조절하는 기법)과 RAID(여러 HDD를 묶어서 디스크에서의 데이터를 복구해주는 기법)를 설정할 수 있다. RAID 설정은 동적 디스크가 되어야 하고, 같은 브랜드 & 같은 용량의 디스크를 사용한다. LVM설정은 다른 용량의 디스크를 묶어서 만들 수 있다. => Linux에서처럼 복잡하지 않고 쉽게 RAID와 L

jep1995

mysql db에 저장된 데이터를 soft 삭제처리한 후(ORM으로는 typeORM 사용), 삭제된 항목을 같이 조회하고 싶거나 복구하고 싶을 때는 withdeleted 와 restore를 이용하면 처리가능하다! 조회하는 방법 : 위 사진처럼 resolver파일에 query문을 작성하고, 아래의 사진처럼 find에서 withDeleted:true 처리해주면 삭제처리 된 후에도 조회가능하다. 복구하는 방법 ![](https://velog.vel

kubernetes

kops는 단순히 k8s 설치 뿐 만 아니라, 몇가지 기능을 사용할 수 있는데, Official page에서 나온 특징은 아래와 같다. > Features Automates the provisioning of Highly Available Kubernetes clusters Built on a state-sync model for dry-runs and automatic idempotency Ability to generate Terraform Supports zero-config managed kubernetes add-ons Command line autocompletion YAML Manifest Based API Configuration Templating and dry-run modes for creating Manifests Choose from most popular CNI Networking providers out-of-the-box

sebinn

📍 GitHub의 Checkout vs Switch / Restore 비교 > 👀 포인트! checkout = switch 기능 or restrore 기능 → 두 기능 모두 포함 switch = switch 기능만 담당 restore = restore 기능만 담당 기존, checkout이 담당하던 2개의 역할을 switch와 resotre이 각각 담당 ✅ Checkout checkout은 브랜치를 변경하는 switch와 수정 내용 복원과 스테이지에 올린 파일을 빼내는 resotre 기능을 모두 담당했다. 기능이 너무 많은 checkout를 대신해 Git 2.23에서 switch와 restore이 도입되었다. 아직까지도 checkout을 사용하는 경우가 많은 것 같은데 chcekout 사용에 단점이 있기 때문에 달라진 변화라고 생각해서 최대한 checkout 사용을 지양하는 것이 좋을 것 같다!

92sursumcorda

서로 다른 개발자들이 모여 하나의 서비스를 만들다보면 깃이 꼬일 때가 분명 발생할 것이기에 깃 커맨드를 제대로 이해해두자(애초에 안꼬이는게 최고이지만...) 깃 영역 이해하기 Working Directory : 내가 작업하고 있는 프로젝트의 디렉토리 Staging Area : 커밋을 하기 위해 $ git add 명령어로 추가한 파일들이 모여있는 공간 Repository : 커밋들이 모여있는 저장소 Working Dir에서 스테이징 영역으로 저장 작업 프로젝트에 변경사항이 생기면 깃은 자동으로 변경 사항이 생긴 것을 감지합니다. MacOS oh-my-zsh 기준 ~$!1 처럼 느낌표와 숫자가 떠있는 경우와 같습니다. 이 때 다음의 명령어를 통해 변경 사항을 스테이징 영역에 저장할 수 있습니다. ~$ git add 예시) git add api/signin/. api/signin 폴더 하위에 있는 모든 파일을 staging에 저장

idle_idle

참고자료: https://learn.microsoft.com/ko-kr/sql/relational-databases/backup-restore/back-up-and-restore-of-sql-server-databases?view=sql-server-ver16 [백업 이유] 백업은 데이터를 보호하는 유일한 방법 서버 간 DB 복사, Always On 가용성 그룹, DB 미러링 설정, 보관 등 데이터베이스를 관리하는 용도로도 유용하게 사용 [백업 용어 설명] - 백업(하다): Back Up, 데이터 레코드를 복사하거나 트랜잭션 로그에서 레코드를 기록하여 백업(본)을 만드는 프로세스 - 백업(본): Backup, 오류가 발생한 후에 데이터를 복원/복구하는데 사용할 수 있는 데이터 복사본으로 데이터베이스 백업을 통해 새 위치에 복원할 수도 있음 - 백업 디바이스: Backup Device, 백업이 기록되는 대상이자 복원하는 원본이 되는 디스크

lhjeong60

네이버 블로그에서 이전, 원글 작성일시 : 2021.11.18.23:55 Let U Win 프로젝트를 진행하면서 NoSQL를 처음 써보고, 당연히 MongoDB도 처음 써보기에 짧고 간단한 내용이라도 잊어버릴만하다 싶으면 블로그에 기록해두려 한다. 겁이 많은 성격이라 늘 개발할 때 백업을 중요시하는 편이다. 각설하고 백업과 복구를 어떻게 하는지 알아보자. Backup MongoDB의 백업은 굉장히 쉽다. 백업을 저장할 경로에서 아래 명령어를 실행해주기만 하면 된다. 실행하게 되면 해당 경로에 mongodb의 모든 db가 파일의 형태로 저장된다. 현재 경로에 dump라는 폴더가 생기고 그안에 각 db마다 db이름의 폴더가 생성된다. db 폴더 안에는 각 collection 마다 collectionname.bson, collectionname.metadata.json 두개의 파일이

noggen86

개떡같은 Redis는 별도의 툴을 사용하지 않으면 클라이언트 사이드에서 dump와 restore가 매우 불편하다. 작업하며 작성한 dump/restore 스크립트를 공유한다. dump.sh restore.sh 사용 예 wsl 환경에서 실행하면 개행 문자와 때문인지 개판난다. 제대로 동작하지 않는다.

younoah

Discard Local change (로컬 변화 취소하기) > 로컬에서 작업하고 있는 staging area나 working directory에서 작업하는 내용을 초기화 하는 방법에 대해서 알아보자. unstaging a staged file 명령어 수행 전 명령어 수행 후 > 초록색은 staging area에 있는 상태 > >

hyeseong-dev

프로젝트를 진행하던 중 초보 개발자 입문생에게 DB를 날리고 새로 만드는 것이 쉽다고 처음 느꼇지만, 결정적으로 가치있는 mock 데이터를 가지고 django view에서 작업하는 것은 매우 중요한 문제라는 것을 느꼇습니다. 그래서~ 데이터베이스 백업과 복원에 대해서 글을 작성하여 정리해봅니다. 1.Backup Specific Database syntax 사용방법 2.Restore Specific Database 백업이랑 다른 점은 화살표 위치가 < 방향으로 바뀐거 밖에 없조?! syntax 사용방법 3.Backup Table syntax 사용방법 4.Restore Table

skysoo

1. 개요 Git은 대표적인 형상 관리 시스템이다. 형상 관리 시스템이란, 소스 코드의 관리 (버전 관리, 변경 사항 추적) 등의 기능을 수행하는 시스템을 말한다. 웹 호스팅 서비스로는 GitHub와 GitLab이 있다. Git에 대해서 설명하려면 끝도 없기 때문에 이번 포스팅에서는 실제 업무를 진행하면서 많이 사용하는 기능들을 알아보려고 한다. 2. 기본 개념 기본 개념은 여기서 하나하나 다 보시는게 최고입니다. > https://git-scm.com/book/ko/v2/ Git의 여러가지 기능들을 정확히 이해하려면 Staging 이란 개념을 확실히 알아야 한다. Staging 영역이란, 쉽게 말해서 Git이 관리하는 파일의 영역으로 'git add ' 명령을 통해 Tracked 상태가 된 파일들의 단계를 의미한다. > Staging Area는 git commit을 실행했을 때 git이 처리할 것들이 있는 곳이다. ![](https://images.

killi8n

AWS를 쓰는 ... (무료로쓰는 혹은 돌려막기 하는...) 저같은 사용자에게 꼭필요한 DB덤프하고 덮어쓰기 ! 이 블로그 또한 10개월 남짓 남은것 같은데 한 9개월 정도 남았을때에 덤프 과정이 필요할거 같아서 서핑 후 글을 남긴다. 덤프하기 일단 몽고디비가 깔려있다면, mongodump라는 명령어로 덤프를 시켜야한다. 아래 명령어를 실행하게 되면 내 현재 위치에 dump라는 폴더가 생기게된다. --out 명령어로 위치를 지정해줄수도 있다. host와 port는 기본값인 127.0.0.1과 27017을 사용했다. 혹은 아이디와 비밀번호로 잠금된 몽고디비라면 으로 가능하고, 또한 모든 데이터베이스를 덤프하려는게 아니면 --db옵션을 사용하여 선택적으로 덤프가 가능하다. 즉, dump 명령어를 정리하자면 다음과 같다. 복구하기 덤프를 했으니, 덤프를 해놓은 데이터들을 바탕으로 복구를 해야한다. 마찬가지로 mongodb가 설치되어 있다면,