Differenze tra le versioni di "Server/horror/Technical documentation"
(add more info) |
|||
Riga 50: | Riga 50: | ||
Note that all sub-directories can be accessed only if you are its dedicated user. | Note that all sub-directories can be accessed only if you are its dedicated user. | ||
− | For example | + | For example the user <code>foo</code> may be the only one allowed to write here: |
− | /var/backups/wmi/ | + | /var/backups/wmi/''fooproject'' |
− | /var/backups/wmi.1/ | + | |
− | /var/backups/wmi.2/ | + | For example the user <code>project</code> may be the only one allowed to read here: |
− | /var/backups/wmi.3/ | + | |
+ | /var/backups/wmi.1/''fooproject'' | ||
+ | /var/backups/wmi.2/''fooproject'' | ||
+ | /var/backups/wmi.3/''fooproject'' | ||
So to get the most recent backup of your project just do something like this: | So to get the most recent backup of your project just do something like this: | ||
− | rsync '' | + | rsync ''foo''@horror.wikimedia.it:/var/backups/wmi/''fooproject'' ./my-destination/ |
Or to download the 3-days-old backup do something like this: | Or to download the 3-days-old backup do something like this: | ||
− | rsync '' | + | rsync ''foo''@horror.wikimedia.it:/var/backups/wmi.3/''fooproject'' ./my-destination/ |
Etc. | Etc. | ||
− | == Filesystem | + | == Filesystem policy == |
The filesystem rule is the standard one in Unix-like systems: give as <u>few</u> privileges as possible. | The filesystem rule is the standard one in Unix-like systems: give as <u>few</u> privileges as possible. | ||
Riga 110: | Riga 113: | ||
<pre> | <pre> | ||
USERNAME=foo | USERNAME=foo | ||
− | PROJECT= | + | PROJECT=fooproject |
sudo adduser --disabled-password $USERNAME | sudo adduser --disabled-password $USERNAME | ||
Riga 120: | Riga 123: | ||
The final purpose is to execute this command daily <u>from you server ''foo''</u> to <u>push</u> your backups on server horror: | The final purpose is to execute this command daily <u>from you server ''foo''</u> to <u>push</u> your backups on server horror: | ||
− | rsync /my/ | + | rsync /my/source/path foo@horror.wikimedia.it:/var/backups/wmi/fooproject |
+ | |||
+ | You can also execute this command daily <u>from server ''horror''</u> to <u>pull</u> data from server ''foo'': | ||
− | + | rsync mysource@myserver:/my/source/path /var/backups/wmi/fooproject | |
− | + | ; Schedule time policy | |
− | + | Your backup logic can write in the backup location in this period: | |
− | + | * 12:00-23:59 Europe/Rome | |
+ | * 00:00-04:59 Europe/Rome | ||
− | + | You <u>must not</u> write there in this period instead, otherwise you may have collisions with the rotation logic: | |
+ | |||
+ | * 05:00-12:00 | ||
+ | |||
+ | ; Available backup tools | ||
* rsync | * rsync | ||
Riga 137: | Riga 147: | ||
* https://gitpull.it/source/micro-backup-script/ (just a stupid script that encapsulates those above) | * https://gitpull.it/source/micro-backup-script/ (just a stupid script that encapsulates those above) | ||
* ... | * ... | ||
+ | |||
+ | ; Success checklist | ||
+ | |||
+ | # your data is saved (by you, or by your new crontab rule) at midnight in <code>/var/backups/wmi/''fooproject''</code> | ||
+ | # your data is automatically rotated in <code>/var/backups/wmi.1/''fooproject''</code> in the next day | ||
== Disaster recovery == | == Disaster recovery == |
Versione delle 11:44, 15 mar 2022
This page is the public technical documentation for the server ⚙️ horror
, dedicated to off-site backups, useful for a #Disaster recovery.
Authorization
Server administrators must be authorized before being able to do a #Server login in the ⚙️ horror
backup server. To be authorized:
- You need
- a good reason
- for example #Add a project under the backup umbrella
- for example #Disaster recovery)
- Unix-like sysadmin experience
- Instructions
Request access policy:
Server login
Access to the backup server is exclusively via SSH login. There are no other forms of access, since SSH is the most secure method possible. To do it:
- You need
- #Authorization
- SSH experience
- Instructions
Just login via SSH using the username we assigned to you in your #Authorization process:
ssh name-surname@horror.wikimedia.it
If it doesn't work, stop immediately and repeat #Authorization.
Do not try random attempts or you can be blocked, notified, fired or even sued.
Filesystem overview
You can explore the filesystem only after #Server login. All recent backups are here:
/var/backups/wmi
Older copies can be obtained adding a numeric suffix. For example the 2-days-old backups are here:
/var/backups/wmi.2
Note that all sub-directories can be accessed only if you are its dedicated user.
For example the user foo
may be the only one allowed to write here:
/var/backups/wmi/fooproject
For example the user project
may be the only one allowed to read here:
/var/backups/wmi.1/fooproject /var/backups/wmi.2/fooproject /var/backups/wmi.3/fooproject
So to get the most recent backup of your project just do something like this:
rsync foo@horror.wikimedia.it:/var/backups/wmi/fooproject ./my-destination/
Or to download the 3-days-old backup do something like this:
rsync foo@horror.wikimedia.it:/var/backups/wmi.3/fooproject ./my-destination/
Etc.
Filesystem policy
The filesystem rule is the standard one in Unix-like systems: give as few privileges as possible.
Here is a summary of the main filesystem pathnames:
Path | owner:group | Permissions | Description |
---|---|---|---|
/var/backups/wmi*/ | root:root | 755 | Everyone should be allowed to list its sub-directories to list the available latest backups.
Note: You may be allowed to list sub-directories but you must be not allowed to access them as default. |
/var/backups/wmi*/project | project:project | 750 | The user project must be the only one allowed to access in its sub-directory. |
Note: the location /var/backups/wmi
is automatically rotated in /var/backups/wmi.1
etc. and the oldest is automatically deleted. Permissions are just kept.
Add a project under the backup umbrella
- You need
- a good understanding about what data need to be saved
- a good understanding about how to transfer that data (e.g. rsync + SSH)
- #Server login
- Instructions
In short you just need to create a directory on server ⚙️ horror
and a dedicated user able to read/write in that directory. Then, you can push backups on that directory.
Some pseudo-instructions to be executed from server ⚙️ horror
to create a new project foo to be added under its backup umbrella:
USERNAME=foo PROJECT=fooproject sudo adduser --disabled-password $USERNAME sudo mkdir --parents /var/backups/wmi/"$PROJECT" sudo chown $USERNAME:$USERNAME /var/backups/wmi/"$PROJECT"
The final purpose is to execute this command daily from you server foo to push your backups on server horror:
rsync /my/source/path foo@horror.wikimedia.it:/var/backups/wmi/fooproject
You can also execute this command daily from server horror to pull data from server foo:
rsync mysource@myserver:/my/source/path /var/backups/wmi/fooproject
- Schedule time policy
Your backup logic can write in the backup location in this period:
- 12:00-23:59 Europe/Rome
- 00:00-04:59 Europe/Rome
You must not write there in this period instead, otherwise you may have collisions with the rotation logic:
- 05:00-12:00
- Available backup tools
- rsync
- rclone
- mysqldump
- https://gitpull.it/source/micro-backup-script/ (just a stupid script that encapsulates those above)
- ...
- Success checklist
- your data is saved (by you, or by your new crontab rule) at midnight in
/var/backups/wmi/fooproject
- your data is automatically rotated in
/var/backups/wmi.1/fooproject
in the next day
Disaster recovery
- You need
- a good understanding of what data is to be recovered and from what date
- check if the provider has native backup/snapshots (if yes, try to use them - they may be more simple to be recovered)
- check if there are on-site backups (if yes, try to use them - they may be more up to date)
- #Server login
- Instructions
- please create a public Task in phabricator:tag/wmit-infrastructure/ to describe the incident shortly, and notify Infrastruttura
- using #Server login, verify the interested backup location and the required privileges
- Example:
ls -l /var/backups/wmi
- Example:
- set a strong password to that user
- Example:
passwd interested-user
- from your already-existing device, download the needed data
- Example:
rsync interested-user@horror.wikimedia.it:/var/backups/wmi/interested-project ./my-destination/
- when you have concluded, disable the password to that user
- Example:
passwd --delete interested-user