docs: upd eng backups #73
Loading…
Reference in New Issue
There is no content yet.
Delete Branch "upd_eng_backups"
Deleting a branch is permanent. Although the deleted branch may exist for a short time before cleaning up, in most cases it CANNOT be undone. Continue?
@ -18,3 +18,2 @@
As an extra benefit, backing up makes it easy to transfer a service from one machine to another with minimal hassle.
This is useful for datacenters on fire, if your server provider gets bought out by another corporation or if shareholders decide that it is finally time to make more profit.
As an extra benefit, backup makes it easy to transfer a service from one machine to another with minimal hassle.
Ты изменил глагол на существительное, и не подправил грамматику предложения под это обстоятельство
done
@ -21,2 +20,3 @@
This is useful for datacenters on fire, if your server provider gets bought out by another corporation, or when shareholders decide that it is finally time to make more profit.
This document covers the basic terms and usage of SelfPrivacy backup subsystem.
We cover the basic terms and usage of the SelfPrivacy backup subsystem.
Смысл слишком улетел куда-то не туда, лучше верни как было
done
@ -54,2 +54,2 @@
* For the sake of performance, the list is cached. If some snapshots are missing which you think should be there, invalidate the cache so it reloads.
* If you remove some snapshots, they will disappear from the list, but for some limited time they are still restorable with the help of the cloud.
* For the sake of performance, the list is cached. If some snapshots are missing which you think should be there, invalidate the cache so it reloads;
* If you delete some snapshots, they will removed from the list, but for some limited time they are still restorable with the help of the cloud.
done
@ -58,3 +58,2 @@
When you restore a snapshot, the service is stopped, and all of its files are restored to the state when the snapshot was taken.
There are 2 ways to do it.
There are two ways to restore a snapshot, which stops the service and restores all files to the state when the snapshot was taken.
смысловые связи в предложении утеряны
готово
@ -70,3 +69,3 @@
## Forgetting a snapshot
Forgetting makes the snapshot inaccessible from the server, but deletion itself is reversible from cloud UI for some time (30 days for Backblaze by default).
If the snapshot is forgotten, it becomes inaccessible from the server, but deletion itself is reversible from cloud UI for some time (30 days for Backblaze by default).
Лучше вернуть как было, мы подчеркиваем действие, а не состояние
готтово
@ -78,3 +77,3 @@
Note that backups are independent per service. If you have services A and B backed up automatically every day in the morning, and then you back up service B manually at noon, then service A's next backup will be in the morning as usual, but B's backups will occur at noons.
If set to zero, autobackups will be disabled.
If it disable, automatic backups will not be performed.
грамматические ошибки
done
@ -88,2 +83,2 @@
* List the snapshots
* Restore from snapshots as usual
* Go to your Backblaze/other cloud interface directly;
* Rewind the bucket to its previous state before the deletion event occurred;
occurred можно убрать
done
@ -14,2 +14,2 @@
* Spend some time reading logs and debugging what went wrong. Meanwhile the service is unusable and maybe some data is irreversibly lost.
* Rewind the service to the working state and then debug at a more relaxed pace. Hopefully it was just solar flare or a glitch in the Matrix.
* Spend some time reading logs and debugging what went wrong. Meanwhile the service is unusable and maybe some data is irreversibly lost;
* Restore the service to a working state and then debug at a more relaxed pace. Hopefully it was just solar flare or a glitch in the Matrix.
a solar flare
done
@ -19,2 +19,2 @@
As an extra benefit, backing up makes it easy to transfer a service from one machine to another with minimal hassle.
This is useful for datacenters on fire, if your server provider gets bought out by another corporation or if shareholders decide that it is finally time to make more profit.
Having a backup simplifies the process of transferring a service between machines, ensuring minimal inconvenience.
This is useful for datacenters on fire, if your server provider gets bought out by another corporation, or when shareholders decide that it is finally time to make more profit.
This is useful if your datacenter is on fire
done
@ -41,2 +41,2 @@
The service's files are stored at the cloud of user's choosing.
At the moment we support Backblaze but more are to be added.
The service's files are stored at the cloud of the user's choice.
We currently support Backblaze, but more will be added.
We currently support Backblaze, with more to come.
done
@ -44,2 +44,2 @@
All of the service data is encrypted with a local secret which the cloud never receives.
Under the hood, we use Restic for transfers of encrypted data.
All of the service data is encrypted with a local secret that the cloud never receives.
Under the hood, we use Restic to transfer of encrypted data.
... we use Restic to transfer encrypted data.
done
@ -46,2 +45,3 @@
Under the hood, we use Restic to transfer of encrypted data.
Clouds like Backblaze have an option to disallow immediate removal of data.
Cloud storage providers like Backblaze have an option to disallow immediate deletion of data.
Cloud storage providers, such as Backblaze, have an option to prevent immediate deletion of data.
done
@ -74,3 +73,3 @@
## Automatic Backup
If you set up an automatic backup period, all of the services will be backed up regularly according to the period.
If you set up an automatic backup period, all of the services will be backed up based on the set period.
... backed up according to the set period.
done
@ -90,0 +84,4 @@
* Rewind the bucket to its previous state before the deletion event;
* Open SelfPrivacy app;
* Update the snapshot list;
* List the snapshots;
@inex what does this imperative mean?
Probably just opening the screen with the list of snapshots
Then we can remove it,
because "Make sure the list is updated" is somewhat implied from the previous step
done
@ -93,3 +92,1 @@
* If you suspect that the snapshot list is inaccurate, try discarding the cache
* If an inplace restore failed, make sure that your cloud is accessible and your contract is active, then try to either restore a snapshot you tried to restore, or a pre-restore snapshot generated automatically
* If you do not have enough space on the disk for a safe restore, try restoring inplace
* If you suspect that the list of snapshots is incorrect, try to update snapshot list;
... try updating the snapshot list;
done
@ -94,2 +92,2 @@
* If an inplace restore failed, make sure that your cloud is accessible and your contract is active, then try to either restore a snapshot you tried to restore, or a pre-restore snapshot generated automatically
* If you do not have enough space on the disk for a safe restore, try restoring inplace
* If you suspect that the list of snapshots is incorrect, try to update snapshot list;
* If an inplace restore has failed, make sure that your cloud is accessible and your contract is active. Then try to either restore a snapshot you tried to restore, or a pre-restore snapshot that was automatically generated;
Then try to restore either a snapshot that you tried to restore or a pre-restore snapshot that was automatically generated;
done
Thank you @NaiJi !
a767db8b4b
to36cef6e7a9