You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The text was updated successfully, but these errors were encountered:
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
The text was updated successfully, but these errors were encountered: