| Version | Date | Notes | By |
|---|---|---|---|
| 0.5 | 2025-02-11 | Adicionado nota o restauro de sites | jfm |
| 0.4 | 2021-07-20 | Adicionado nota sober o Borg | jfm |
| 0.3 | 2019-07-16 | Adicionado SQL para criar utilizador | jfm |
| 0.2 | 2018-09-28 | Adicionado comandos de extração de ficheiros | jfm |
| 0.1 | 2017-09-25 | Initial release | jfm |
Para instruções relacionadas com o restauro de backup usando o Borg, ver o documento Borg backup verification
Em alguns casos poderá ser útil/recomendável parar qualquer tipo de serviço associado aos ficheiros em causa (Ex: Apache, Supervisor, etc...)
Restauro total de pastas
Restauro de ficheiros especificos
Ficheiros .tar.gz - tar -zxvf ficheiro.tar.gz
Ficheiros .tar - tar -xvf ficheiro.tar
Ficheiros .gzip - gunzip ficheiro.gz
Ficheiros .zip - unzip ficheiro.zip
Para restaurar um site deveremos seguir o mesmo processo de restauro de ficheiros, e colocar os sites nos devidos lugares. Geralmente em /var/www/
Não esquecer de atribuir as permissões necessárias. Consultar a documentação de instalação do IMS https://sgiv10.wedocs.wemake.pt/production/installation-guide/installation-on-linux
Exemplo:
mysqldump -u <user> -p --add-drop-tables --single-transaction -B <database_name> > backup_filename.sql
mysql -u <user> -p
DROP DATABASE <database_name>;
CREATE DATABASE <database_name>;
mysql -u <user> -p <database_name> < <file_with_backup.sql>
A forma de restauro de dados parciais vai depender sempre do que é pretendido. O restauro especifico de dados requer analise mais detalhada e varia consoante o caso. Aqui apenas será definido como restaurar tabelas inteiras.
Seguir os passos 1 a 3 do Restauro total da base de dados
mysqldump -u <user> -p --add-drop-tables --single-transaction <database_name> <table1_name> <table2_name> > backup_filename.sql
mysql -u <user> -p <database_name> < <backup_filename.sql>
Criar um utilizador e dar acesso a uma bd
CREATE USER 'username'@'localhost' IDENTIFIED BY '<password>';
GRANT ALL PRIVILEGES ON database.* TO 'username'@'localhost';
FLUSH PRIVILEGES;
TODO
/etc/gitlab/gitlab.rb configuração gitlab_rails['backup_path']sudo gitlab-ctl stop unicorn
sudo gitlab-ctl stop sidekiq
# Verificar o estado
sudo gitlab-ctl status
sudo gitlab-rake gitlab:backup:restore BACKUP=<prefixo_nome_backup>
Os ficheiros de backup do gitlab tem o seguinte formato: 1519264848_2018_02_22_10.3.3_gitlab_backup.tar.
Considera-se o prefixo do nome do ficheiro a parte que vai até antes do _gitlab_backup.tar, neste caso 1519264848_2018_02_22_10.3.3
/etc/gitlab/gitlab-secrets.jsonsudo gitlab-ctl restart
sudo gitlab-rake gitlab:check SANITIZE=true
svnadmin hotcopy /usr/local/svn/repos/<repositorio>/ /tmp/<repositorio>
svnadmin load <repo_folder> < <incremental_backup_file>Exemplo
svnadmin load /usr/local/svn/repos/admastor < /var/wemakebackups/subversion/data/admastor/v59-61.bak
svnadmin load /usr/local/svn/repos/admastor < /var/wemakebackups/subversion/data/admastor/v62-62.bak
Found errors? Think you can improve this documentation? Simply click the Edit link at the top of the page, and then the icon on Github to make your changes.
Powered by Grav + with by Trilby Media.