Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

necessity of restoring the server log #183

Open
huangfumingyue opened this issue Jun 21, 2021 · 0 comments
Open

necessity of restoring the server log #183

huangfumingyue opened this issue Jun 21, 2021 · 0 comments
Assignees

Comments

@huangfumingyue
Copy link
Contributor

huangfumingyue commented Jun 21, 2021

In issue #174 , ikeda san propose to restore the server log.
so we argued about necessity of restoring the server log.
and we also argue if we don't restore the server log, how to check the taken server log's backup safely.
there are three choices.

a. Restore the server log and add a new option
It's up to the user to restore the server
But there are some problems.

  • If the same file exists in the log when restoring, it will be overwritten.
    the server log go back to the backup point, is that okay?

  • when PITR is performed(Using archived logs), data and log may be inconsistent.
    In that case, the data may be up to date, but the logs may be out of date.

  • Which server log should be restored
    In addition to the full backup, take a differential backup or only the latest backup.
    If it's up to date, is it a good idea to look at the server logs in a full backup?
    Also.If there are many server logs, the data at the restore destination may become bloated

  • IF there is the same server log name, depending on the update check logic.
    It may not be possible to obtain it with an incremental backup.

b.Check the backup catalog without restoring the server log
The problem is that it is dangerous that the user operate directly in the backup catalog.

c.Change the backup destination of the server log
As a caveat

  • It is necessary to add a time stamp etc. so that it will not be overwritten

  • A mechanism to delete the backup destination of the server log is also required.
    -- The delete option must be applied to this method.

  • At the new backup destination, the user may accidentally delete the backup file.
    -- The solution is to restore only the server log to another directory as an option of the restore command.
    -- No need to modify the delete option. Users no longer accidentally delete server logs

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants