GitLab Backup

  • GitLab에 대한 모든 설정은 /etc/gitlab/gitlab.rb에서 관리할 수 있습니다.

  • 보편적인 방법으로 Omnibus package로 설치한 경우 백업은 다음과 같습니다.

    $ sudo gitlab-rake gitlab:backup:createDumping database tables:
    - Dumping table events... [DONE]
    - Dumping table issues... [DONE]
    - Dumping table keys... [DONE]
    - Dumping table merge_requests... [DONE]
    - Dumping table milestones... [DONE]
    - Dumping table namespaces... [DONE]
    - Dumping table notes... [DONE]
    - Dumping table projects... [DONE]
    - Dumping table protected_branches... [DONE]
    - Dumping table schema_migrations... [DONE]
    - Dumping table services... [DONE]
    - Dumping table snippets... [DONE]
    - Dumping table taggings... [DONE]
    - Dumping table tags... [DONE]
    - Dumping table users... [DONE]
    - Dumping table users_projects... [DONE]
    - Dumping table web_hooks... [DONE]
    - Dumping table wikis... [DONE]
    Dumping repositories:
    - Dumping repository abcd... [DONE]
    Creating backup archive: $TIMESTAMP_gitlab_backup.tar [DONE]
    Deleting tmp directories...[DONE]
    Deleting old backups... [SKIPPING]

 

 

GitLab Restore

  • 생성된 백업파일은 기본적으로 /var/opt/gitlab/backups에 저장됩니다.

    • 로컬에 저장된 백업파일은 100% 안전하다고 할 수 없기때문에 반드시 외부 환경에 소산 보관해야 합니다.

    • GitLab서버와 FreeNAS와 같은 외장 스토리지 서버와 네트워크로 연결하는 (CIFS 등) 방법도 고려해야 합니다.

      • 네트워크 환경에서 백업 환경을 구축할 때, 대규모 환경에서는 SAN으로 구성하는 것이 좋은 대안이 될 수 있으나 소규모 환경에서는 비용문제가 많이 발생할 수 있기 때문에 내부 네트워크 환경에서 시행하는 것이 좋습니다.

      • 단, 같은 네트워크 환경에서 백업이 같이 이루어질 경우 네트워크 장비의 용량에 따라 내부 네트워크의 전체 속도가 떨어질 수 있기 때문에 네트워크 사용량이 적은 시간에 진행하거나 네트워크를 분리하는 방법도 고려하는 것이 좋습니다.

GitLab Service 중단 및 백업$ sudo gitlab-ctl stop unicorn
$ sudo gitlab-ctl stop sidekiq
# Verify
$ sudo gitlab-ctl status# 백업 파일이 하나일 경우
$ sudo gitlab-rake gitlab:backup:restore

# 백업 파일이 여러개 있을 경우
$ sudo gitlab-rake gitlab:backup:restore BACKUP=1493107454_2018_04_25_10.6.4-ce

  • 기본적인 백업 디렉토리에 백업 파일이 존재하면 자동으로 기존에 있던 데이터베이스가 삭제되고, 백업데이터로 변경됩니다.

    • 새롭게 설치한 GitLab 서버에도 다음과 같이 진행하면 기존에 사용하던 환경으로 마이그레이션이 완료됩니다.

  • 이때, 백업 당시에 사용했던 GitLab 버전과 사용중인 GitLab 버전이 다를 경우에는 복구가 진행되지 않기 때문에 버전과 동일한 백업 파일을 생성하여 진행할 수 있도록 합니다.

GitLab Service 시작 $ sudo gitlab-ctl restart
$ sudo gitlab-rake gitlab:check SANITIZE=true

콘솔 명령의 용도


콘솔 명령의 용도는 주로 다음과 같습니다.

1. 디버깅 정보를 화면에 UI로 표시
↓ 예 : stat fps / stat unit / stat unitgraph. 얼마나 처리 시간이 걸려 있는지를 표시한다.


↓ 예 : stat particles. 파티클 통계. 지금 얼마나 나와 있고, 얼마나 처리가 걸려 있는지를 표시합니다.



2. 디버깅에 그리기를 변경
↓ 예 : show bounds. 각 Actor의 바운딩 박스를 표시합니다.



3. 디버깅을 위한 움직임 전환
↓ 예 : ToggleDebugCamera. 디버깅 용 카메라를 자유롭게 움직일 수있다. 또한 화면 중앙에있는 Actor와 자료의 정보도 볼 수 있습니다.



4. 게임을하는 동안 작업을 수행 (예 : RestartLevel)

5. 편집기의 동작을 변경 (예 : culture = kr)

 

명령 사용 방법

명령을 입력하는 방법에는 여러 가지가 존재합니다. 주요 방법은 다음 네 가지입니다. 1 번과 2 번은 자주 사용하므로 기억합시다.

1. OutputLog (출력 로그) 창에서 사용
↓ 1 단계 : Output Log (출력 로그) 창을 표시한다.



↓ 2 단계 : 나온 창 하단에 입력한다.



2. 게임 실행 중에 Console Key를 누르면 나타나는 입력란
↓ 1 단계 : 프로젝트 설정 -> 입력 -> Console-> Console Keys 키를 추가합니다.
기본적으로 "`"를 사용합니다.


↓ 2 단계 : 게임 실행 중에 "`"키를 누르면 이렇게 명령 입력 필드가 표시됩니다.


3. Blueprint의 Execute Console Command 노드에서 입력



4. C ++에서 입력
다음의 방법으로 C ++에서도 명령을 보낼 수있다. PC는 PlayerController.

PC-> ConsoleCommand ( <Command>, true );

 

 

자주 사용하는 명령 목록

 

Basic

DumpConsoleCommands 콘솔 명령 목록을 Output Log로 출력한다. 모든 명령이 출력되는 것은 아니기 때문에 주의.


조작

Open <LevelName (MapURL)> 이전 설정을 그대로 유지하면서 지정된 수준을 연다. (Persistent Level의 대체)
Travel <LevelName (MapURL)> 모든 설정을 초기화하고 지정된 레벨을 연다. (Persistent Level의 대체)
RestartLevel 현재의 수준을 다시로드.
slomo <PlayRate> 슬로우 모션 / 빨리 감기하는 ex. slomo 0.5
quit 또는 exit 게임을 종료

 

일반적인 Debug 계 명령

getall <Class name> <Property name> 대상 클래스의 속성을 OutputLog 창에 한 칸에 출력한다.
obj list OutputLog 창에 각 개체의 수와 사용 메모리 양을 출력한다.

주회 플레이 메모리 누수 (개체 수 증가) 검사에 사용할 수있다.

DisableAllScreenMessages 2D 스크린에서 디버그 표시를 비활성화
stat levels 현재 로드된 Level보기. 로드에 걸린 시간도 표시된다.

녹색 : Unload 상태

빨간색 : Load 상태

ViewMode <ViewModeName> 그리기 방법을 전환합

ViewModeName에는 다음의 것이있다.

Lit / Unlit / Wireframe / LightingOnly / ShaderComplexity 등

ToggleDebugCamera 게임 중의 카메라를 떠나 디버깅 다른 카메라로 전환한다.

동시에 주시 지점의 자산 정보를 화면에 표시한다.

log list 로깅 카테고리
log <category> <level> category의 로깅 수준을 변경한다.
<로그 수준>
NoLogging
Fatal
Error
Warning
Display
Log
Verbose
VeryVerbose
All <편리 명령>
log LogStreaming Verbose <- 자산로드 관련 로그를 출력
ce <EventName> 표시되는 모든 레벨의 <EventName> 사용자 정의 이벤트를 호출한다.
KismetEvent <Object 이름 or *> <EventName> Blueprint의 이벤트를 직접 호출. <Object 이름>을 지정하는 장소에는 「*」을 지정하면 전체 BP에 날릴.

 

Memory

stat MemoryPlatform 종합적인 현재의 메모리 사용량과 남은 양 표시
stat MemoryAllocator  
stat Memory  
stat MemoryStaticMesh  
stat ParticleMem  
stat SceneMemory  
mem Detailed 로그에 메모리 사용량을 한꺼번에 출력
memreport (-full) 메모리 상태를 Saved / Profiling / MemReports 폴더 아래에 파일로 출력한다. 확장자는 memreport, 단순한 텍스트.
rhi.DumpMemory RHI 자원 메모리 덤프. 모든 항목이 mem Detailed에 포함되어 있는

rhi : Render Hardware Interface

 

Performance (공통)

stat fps 화면에 FPS를 표시
stat unit 화면에 Game 스레드 Draw 스레드, GPU 스레드 1 프레임 당 소요 시간을 표시
stat unitgraph stat unit의 내용을 그래프로 표시
stat Raw stat unitgraph의 내용을 필터링하지 않고 원시 데이터를 사용
stat hitches 히치를 감지하고 기록
stat dumphitches 히치시 로그를 덤프한다. 기본적으로 75ms 이상이지만 "t.HitchThreshold 0.075"고하여 값을 변경
stat game 전반적인 Tick 시간을 몇 가지 항목으로 분류 해 볼 수 있습니다. Navi Tick Time / Net Tick Time / Post Tick Component Update / World Tick Time etc ...
StartFPSChart / StopFPSChart Saved / Profiling / FPSChartStats 다음에 FPS 정보의 로그를 출력한다. 출력되는 CSV를 사용하여 그래프도있다.

 

Performance (CPU Time)

stat startfile / stat stopfile ※ Session Frontend를 사용할 상황에서는 Session Frontend에서 같은 조작이 가능

start로부터 stop까지의 프로파일 결과를 파일에 ue4stats 형식으로 출력

Output Log 출력 경로가 표시된다.

출력 된 파일은 Session Frontend (Editor에서 Window → Developer Tools → Session Frontend)의 Profiler 탭에서 볼 수있다.

아마 UFUNCTION되어있는 함수가 프로파일 대상이지만, C ++ 코드에 QUICK_SCOPE_CYCLE_COUNTER매크로를 빚는 경우 핀 포인트로 프로필있다.

공식 문서 : CPU Profiling

 

Performance (GPU Time)

ProfileGPU

GPU의 stats 정보를 그래프로 표시.
또한 Output Log 창에 프로파일 결과를 텍스트로 표시된다.
Ctrl + Shift +, (쉼표)로 단축키가 할당되어있다.

stat SceneRendering Draw call etc ...
stat Cnvas  
stat LightRendering  
stat ShadowRendering  
stat Particles  
ViewMode ShaderComplexity Viewport에서 Shader 부하가 걸려있는 곳을 붉게 표시
show <ElementName> ↓ ElementName에는 다음 항목이 사용할 수있다.

AmbientOcclusion
AntiAliasing
Bloom
Decals
DeferredLighting
DirectionalLights
PointLights
SpotLights
DynamicShadows
GlobalIllumination
LightFunctions
Particles
PostProcessing
ReflectionEnvironment
Refraction
Rendering
ScreenSpaceReflections
Landscape
Brushes
StaticMeshes
SkeletalMeshes
ShadowFrustums
(↑ 동적 그림자를 생성하는 후라스타무을 표시 .EditorViewport의 Show-> Advanced-> Shadow Frustums라도 표시 )
Landscape
Translucency
Tessellation

※ 그 밖에도있다. "show"만 입력하면 로그 창에 목록이 표시

※ Pause를 걸쳐 여러 Show 명령에서 표시 / 숨기기를하면 원인은 무엇 무거워지고 있는지 알기 쉽다.

공식 문서 : GPU Profiling

 

Maniac

ParticleSystemAudit Particle 모니터링
culture = [CultureID] 에디터 지역 / 언어 설정을 즉시 변경한다.

CultureID는 북미 / 영어라면 "en"



출처: https://microsoft.tistory.com/982 [::: 책 읽는 프로그래머 :::]

출처 : https://lifeisforu.tistory.com/360 [그냥 그런 블로그]


1. 들어가며


UE4 와 관련한 프로그래밍을 하면서 처음에 가장 헷갈리는 부분이 패키지와 애셋이라는 개념입니다. 그리고 이것은 나중에 C++ 코드를 통해 패키지나 애셋을 로드하다가 보면 머리가 아파집니다. 경로를 집어 넣으라고 하는데 뭐가 뭔지 알수가 없습니다.


사실 언리얼 공식 문서인 [ 애셋과 패키지 ] 에 그 개념들에 대해서 설명을 하고 있기는 하지만 좀 부족합니다. 아니 부족하다기 보다는 우리가 생각하는 애셋과 패키지가 아닙니다. 뭐랄까 아티스트나 디자이너 위주의 추상화된 개념이라 할 수 있습니다. 실제 API 들에서 명명하는 개념과는 다릅니다.


특히나 커맨드렛 같은 도구를 통해 애셋관리를 자동화할 때 이 문제는 심각해집니다. 애셋을 복사하고 싶은데 애셋을 복사하는 방법을 모릅니다. 그래서 어찌어찌 내가 애셋을 복사한다고 하는게 패키지를 복사하는 것이라는 것을 깨닫게 됩니다. 그런데 패키지를 복사한 후에 경로 문제 때문에 애셋을 로드하지 못하는 사태가 발생합니다.


많은 분들이 이런 문제들 때문에 골치가 아팠을 것이라 생각합니다. 그래서 이 문서에서는 그런 개념들에 대해 정리해 볼 계획입니다. 모쪼록 도움이 됐으면 좋겠네요.


2. 패키지와 애셋


여러분은 패키지라고 하면 무엇이 생각나십니까? 여러 개의 애셋을 하나로 묶어 놓은 ( Unity3D 에서와 같은 ) 번들을 생각하시는 분도 있을테고 배포하기 위해서 묶어 놓은 패키지를 생각하실 수 있을 것입니다. UE4 에디터에서 공식적으로 패키지라는 이름이 등장하는 것은 후자의 경우입니다. 쿠킹 패키징할 때의 패키지입니다.



하지만 코딩 문맥에서는 패키지라는 것은 그냥 "*.uasset" 파일입니다. UE3 에서는 어땠는지 모르겠지만 UE4 에서는 패키지와 애셋은 1:1 로 대응됩니다. 그럼 ".uasset" 파일을 칸텐츠 브라우저에서는 애셋이라 부르고 코드에서는 패키지라 부르는 것일까요? 여러분은 어떻게 생각하시나요?


아래의 칸텐츠 브라우저에 있는 "FirstPersonCharacter" 는 코딩문맥에서 보면 패키지인가요 애셋인가요?



답은 애셋입니다. 좀 더 명확하게 하기 위해서 익스플로러에서 이 파일을 복제해 보겠습니다.



보이시나요? 동일한 "*.uasset" 파일을 복사하게 되면 파일의 이름은 다른데 칸텐츠 브라우저에서의 이름은 동일합니다. 그러므로 제가 위에서 "*.uasset" 은 패키지이고 칸텐츠 브라우저에서는 애셋으로 표현된다고 말씀드린 것입니다. 절대 "FirstPersonCharacter2" 라는 이름으로 애셋이름이 변경되지 않습니다.


"에이~ 내가 해봤는데 칸텐츠 브라우저에서 애셋 복사하면 이름 바뀌던데?" 라고 반문하시는 분 있을 겁니다. 맞습니다. 칸텐츠 브라우저에서 애셋을 복사하면 패키지 복사와 함께 이름 변경까지 수행해 줍니다. 그러나 이는 칸텐츠 브라우저의 동작이지 패키지의 동작은 아니라는 겁니다. 그러므로 나중에 패키지를 코드를 통해 복사하게 되면 문제가 발생하는 겁니다.


정리하자면 패키지라는 것은 "*.uasset" 을 이야기하는 것이고 애셋이라는 것은 "*.uasset" 에 포함되어 있는 대표 오브젝트를 의미합니다. 편의상 이를 애셋이라는 이름으로 개념화한거죠. 여러분이 코드를 보실 때 주의하실 점은 "class UAsset" 과 같은 검색어를 날릴 필요는 없다는 것입니다. 존재하지 않습니다. UObject 를 상속한 어떠한 오브젝트라도 패키지의 대표 오브젝트가 될 수 있습니다.


3. Paths


이제 패키지와 애셋이 다르다는 것을 인지했으니 코드 상에서는 이에 어떻게 접근을 하는지 알아 보도록 하겠습니다. 위에서 한 것과 똑같은 동작을 코드에서 수행해 보도록 하겠습니다.


3.1. LongPackageName


일단 패키지를 로드하기 위해서는 어떤 경로를 사용해야 할까요? 여러 분이 칸텐츠 브라우저에서 애셋 위에 마우스를 올리시면 다음과 같은 툴팁을 보실 수 있습니다.



저기에서 "/Game" 이라는 이름으로 "Path" 가 시작되는 것이 보이실 겁니다. UE4 에서 사용하는 모든 칸텐츠의 경로는 저 "/Game" 이라는 접두어로 시작됩니다. 그것은 "/Content" 라는 이름에 대한 키처럼 사용됩니다. 아래 그림을 보시면 붉은색 박스가 게임 디렉토리이고 녹색 박스가 위에서 표현하고 있는 Path 입니다. 단지 "Content" 라는 이름이 "Game" 이라는 이름으로 변경되었을 뿐이죠. 




어쨌든 이 경로와 확장자를 제거한 패지키 이름을 합치면 그것을 LongPackageName 이라 부릅니다. 이 LongPackageName 에서는 "\" 가 아니라 "/" 를 디렉토리 분리자로 사용합니다.


UPackage* LoadPackage(UPackage* InOuter, const TCHAR* InLongPackageName, uint32 LoadFlags);


우리의 경우에는 "/Game/FirstPersonCPP/Blueprints/FirstPersonCharacter" 가 되겠죠. 


UPackage* SrcPackage = LoadPackage(nullptr, TEXT("/Game/FirstPersonCPP/Blueprints/FirstPersonCharacter"), 0);

3.2. Filename


앞에서 로드한 패키지를 "/Game/FirstPersonCPP/Blueprints/FirstPersonCharacter2" 이라는 이름으로 저장해 보도록 하겠습니다. 그런데 패키지를 저장하는 메서드는 Filename 이라는 인자를 요구하는군요.


bool SavePackageHelper(UPackage* Package, FString Filename, EObjectFlags KeepObjectFlags, FOutputDevice* ErrorDevice, FLinkerLoad* LinkerToConformAgainst, ESaveFlags SaveFlags)

Filename 이라는 인자를 요구하는 경우에는 절대 경로를 요구하는 것이라 보시면 됩니다. 확장자까지 확실히 붙어 있어야 합니다. 우리는 LongPackaeName 을 알고 있기 때문에 이를 절대 경로로 바꾸는 과정을 거치게 됩니다. 아래 코드를 살펴 보십시오. 어렵지 않을 것입니다.


FString DestLongPackageName = TEXT("/Game/FirstPersonCPP/Blueprints/FirstPersonCharacter2");
FString DestRelFilename = FPackageName::LongPackageNameToFilename(DestLongPackageName, ".uasset");
FString DestAbsFilename = FPaths::ConvertRelativePathToFull(DestRelFilename);
FPaths::MakePlatformFilename(DestAbsFilename);
 
SavePackageHelper(SrcPackage, DestAbsFilename);


FPaths::ConvertRelativePathToFull() 은 상대경로를 절대경로로 바꿔줍니다. 이 시점에서 DestAbsFilename 은 "C:/Users/lifeisforu/Documents/Unreal Projects/PackageTest/Content/FirstPersonCPP/Blueprints/FirstPersonCharacter2.uasset" 이 나옵니다.


하지만 이것은 Windows 플랫폼에 맞는 이름이 아니죠. 그래서 플랫폼에 맞게 분리자 문자( '/' )를 교정해 줍니다. FPaths::MakePlaformFilename() 이 그 역할을 합니다. 그러면 DestAbsFilename 은 "C:\Users\lifeisforu\Documents\Unreal Projects\PackageTest\Content\FirstPersonCPP\Blueprints\FirstPersonCharacter2.uasset" 이 됩니다.


이제 패키지를 저장하고 나서 보면... 짠!



위에서 나온 것과 같은 상황이 발생합니다. 애셋 이름과 패키지 이름이 다릅니다. 그냥 패키지만 복사하면 이게 정상입니다.


3.3. ObjectPath


이제 애셋의 이름을 정상적으로 고쳐줄 필요가 있겠군요. 그러나 package 관련 메서드들에는 절대 RenameAsset 과 관련한 이름이 존재하지 않습니다. 정말 우울한 일이죠. 애셋을 로드해야만 합니다.


여기에서 ObjectPath 라는 개념이 나옵니다. StaticLoadObject 는 "Name" 이라는 인자를 받습니다. "LongPackageName" 이나 "Filename" 이 아닌 그냥 "Name" 이라는 인자는, 그것이 오브젝트와 관련되어 있다면, 십중팔구 ObjectPath 라 생각하시면 됩니다.


ObjectPath 라는 것은 "{LongPackageName}.{AssetName}" 입니다. 애셋의 이름이 마치 확장자인 것처럼 사용됩니다. 그러나 프로그래머 관점에서는 클래스의 필드 이름 정도로 생각하시는 것이 좋을 것입니다. A 오브젝트의 B 필드에는 A.B 라는 식으로 접근하니 이해하기 편할 것입니다.


패키지 파일은 복사했지만 애셋 이름은 고친적이 없으니 이 애셋을 로드하기 위해서는 그 경로는 "/Game/FirstPersonCPP/Blueprints/FirstPersonCharacter2.FirstPersonCharacter" 입니다. 이를 "/Game/FirstPersonCPP/Blueprints/FirstPersonCharacter2.FirstPersonCharacter2" 로 고쳐야겠죠.


UPackage* DestPackage = LoadPackage(nullptr, *DestLongPackageName, 0);
FString ObjectPath = DestLongPackageName + ".FirstPersonCharacter";
UObject* Asset = StaticLoadObject( UObject::StaticClass(), nullptr, *ObjectPath);
 
FAssetToolsModule& AssetToolsModule = FModuleManager::LoadModuleChecked<FAssetToolsModule>("AssetTools");
TArray<FAssetRenameData> AssetsAndNames;
new(AssetsAndNames) FAssetRenameData(Asset, FPackageName::GetLongPackagePath(Asset->GetOutermost()->GetName()), TEXT("FirstPersonCharacter2"));
AssetToolsModule.Get().RenameAssets(AssetsAndNames);
 
SavePackageHelper(DestPackage, DestAbsFilename);


이제 애셋이름이 패키지 이름과 동일하게 생성되는 것을 확인할 수 있습니다.



4. 결론


정리하자면 다음과 같습니다.


    • 패키지 : uasset 파일.
    • 애셋 : 패키지를 대표하는 오브젝트.
    • LongPackageName : "/Game" 으로 시작하는 확장자를 배제한 패키지 이름.
    • Filename : 시스템에서의 절대 경로. FPackageName 과 FPaths 라는 유틸리티를 사용해서 LongPackageName 으로부터 변환할 수 있음.
    • ObjectPath : 패키지 이름과 애셋이름을 합친 경로. 애셋이름이 확장자처럼 사용됨.
    • 코드에서 패키지를 복사하려면 애셋 이름도 반드시 따로 변경해야 함.



출처 : https://lifeisforu.tistory.com/360 [그냥 그런 블로그]

+ Recent posts